ownCloud (witch is based on SabreDAV) supports sync
enable site-wide bayesian filtering

Create directory in $STORAGE_ROOT for bayes database.

Added --username arg to sa-learn as the user mail does not have permission to edit files in $STORAGE_ROOT. There is probably a better solution to this...
typo in roundcube download URL

see https://github.com/mail-in-a-box/mailinabox/commit/8e0967dd8e2ecce6a1092deaca7241a6d927ae1e#commitcomment-7940724
add 2048 bits of DH params for nginx, postfix, dovecot

nginx/postfix use a new pre-generated dh2048.pem file. dovecot generates the bits on its own.

ssllabs.com reports that TLS_DHE ciphers went from 1024 to 2048 bits as expected. The ECDHE ciphers remain at 256 bits --- no idea what that really means. (This tests nginx only. I haven't tested postfix/dovecot.)

see https://discourse.mailinabox.email/t/fips-ready-for-ssl-dhec-key-exchange/76/3
revert dovecot part of 39bca053edbcfa149a283e3be0cb770460d327e0 because dovecot started behaving weird and I don't have time to debug it
catch-all addresses should not have precedence over mail users

Aliases have precedence over mail users. A catch-all address would grab mail intended for a mail user and send it elsewhere. This adds some SQL hackery to create dummy aliases for all mail users.

fixes #200
closes #214 another way
add catch-alls to the admin again with nicer instructions
make mail instructions clearer and describe greylisting, DMARC policy
preliminary work on a mail.log scanner to report things in the control panel
tweak the site-wide bayesian spam filtering config
move sa-learn-pipe.sh from /usr to /usr/local
Merge branch 'jmar71n-master' - site-wide bayesean spam filtering
Merge commit '93a722f'
dont log robots.txt and favicon.ico. we should REALLY consider creating seperate include files for *all* of our "apps", this is getting messy..
status checks: put DNSSEC tests in a better order w.r.t. other tests

* If the PRIMARY_HOSTNAME is in a zone with a DS record set at the registrar, show any DNSSEC failure (but only a failure) immediately since it is probably the cause of other DNS errors displayed later.
* For zones, if a DS record is set at the register, do the DNSSEC test first because even the NS test will fail if DNSSEC is improperly configure.
* But if a DS record is not set, the this is just a suggestion to configure DNSSEC so offer the suggestion last --- after mail and web checks.

see https://discourse.mailinabox.email/t/dns-nameserver-gandi-glue-records-issues/105/3
generate the locales before change to it.

For my german box changing the locale failed:
´´´´/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
/bin/sh: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
setup/functions.sh: line 6: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)´´´´

see #206 and 4e6d572de9c917d5a96b3413923c115ab8fbf7bc
closes #220
commit modified by joshdata
Add support for TLS authenticated "sibling host" relayers

The use case for this is e.g. a www server that is a separate machine to
the mailinabox, but which needs to send emails to the internet - for example it
may be running Wordpress or some other web app and need to notify arbitrary
users of comments etc.

In such cases, as the www administrator is using mailinabox, they're almost
certainly better off letting mailinabox do as much as possible as far as email
is concerned (as opposed to having the www sibling host do full delivery
itself) - among other things this simplifies reasoning about DNS records.