[Postfix docs](http://www.postfix.org/postconf.5.html#tls_ssl_options):
> Disable SSL compression even if supported by the OpenSSL library. Compression is CPU-intensive, and compression before encryption does not always improve security.
[Postfix mailing list discussion](http://postfix.1071664.n5.nabble.com/patch-mitigate-CRIME-attack-td57978.html):
> The CRIME attack does not apply to SMTP, because unlike SMTP, there is no javascript in SMTP clients that makes them send thousands of email messages with chosen plaintext compressed together in the same packet with SASL credentials or other sensitive data.
> The auditor completely failed to take the context into account.
[Mailing list discussion of potential compression CRIME-like attack](https://lists.cert.at/pipermail/ach/2014-December/001660.html)
> keeping compression disabled is a good idea.
If you need a good test score, PCI compliance will likely flag compression despite not having any known risk with non-HTTP TLS.
* remove two ciphers according to https://www.htbridge.com/ssl/ (NIST, HIPAA)
* added a switch via an environment variable to choose between modern and intermediate ciphers
* new setup.sh function, new tests, new script and some minor updates to main.cf
* fix for missing files
* removed obsolete test-files
* restart postfix if neccessary.
* see pr #845
* fixed typo
* fixed branchmixup
* changed postfix reload command & changed to operate on container instead of image
* reload postfix only on adding new restriction
* main.cf is only changed when user is added.
- Postfix reload changed
- working on container instead of image now in setup.sh
- added cleanup after tests
* moved cleanup to makefile
* Introduced Postscreen
cheaper, earlier and simpler blocking of zombies/spambots.
From http://postfix.cs.utah.edu/POSTSCREEN_README.html :
As a first layer, postscreen(8) blocks connections from zombies and other spambots that are responsible for about 90% of all spam. It is implemented as a single process to make this defense as cheap as possible.
Things we need to consider:
- Do we need a whitelist/backlist file? (http://postfix.cs.utah.edu/postconf.5.html#postscreen_access_list)
- Via introducing an optional config/postfix-access.cidr
- The only permanent whitelisting I could imagine are monitoring services(which might (still?) behave weird/hastely) or blacklisting backup servers(since no traffic should be coming from them anyway)
- Do we need deep inspections? They are desireable, but these tests are expensive: a good client must disconnect after it passes the test, before it can talk to a real Postfix SMTP server. Considered tests are:
- postscreen_bare_newline_enable (http://postfix.cs.utah.edu/postconf.5.html#postscreen_bare_newline_action)
- postscreen_non_smtp_command_enable (http://postfix.cs.utah.edu/postconf.5.html#postscreen_non_smtp_command_action)
- postscreen_pipelining_enable (http://postfix.cs.utah.edu/postconf.5.html#postscreen_pipelining_action)
- Do we need to make the blacklisting via dnsblocking configurable? It's currently set and weighted as follows, where a score of 3 results in blocking, a score of -1 results in whitelisting:
(*: adds the specified weight to the SMTP client's DNSBL score. Specify a negative number for whitelisting.)
(http://postfix.cs.utah.edu/postconf.5.html#postscreen_dnsbl_sites)
- zen.spamhaus.org*3
- bl.mailspike.net
- b.barracudacentral.org*2
- bl.spameatingmonkey.net
- bl.spamcop.net
- dnsbl.sorbs.net
- psbl.surriel.com
- list.dnswl.org=127.0.[0..255].0*-2
- list.dnswl.org=127.0.[0..255].1*-3
- list.dnswl.org=127.0.[0..255].[2..3]*-4
- What to do when blacklisting? I currently set it to drop. We could
- ignore: Ignore the failure of this test. Allow other tests to complete. Repeat this test the next time the client connects. This option is useful for testing and collecting statistics without blocking mail.
- enforce: Allow other tests to complete. Reject attempts to deliver mail with a 550 SMTP reply, and log the helo/sender/recipient information. Repeat this test the next time the client connects.
- drop: Drop the connection immediately with a 521 SMTP reply. Repeat this test the next time the client connects.
In the end I think we could drop postgrey support. Postscreen replaces postgrey in its entirety, while being more selective and not delaying mail. Especially if we consider using the deep inspection options of postscreen.
Hope that wasn't too much to read! ;)
* main.cf got misformatted..
Don't know how, should be ok now.
* fixed malformatted main.cf & repaired master.cf
* reenabled rbl stuff.. It's cached, therefore doesn't hurt
* fixed tests
* added tests, repaired tests, added info, introduced new Variable POSTSCREEN_ACTION, fixes
* Allow setup of LDAP STARTTLS for Dovecot and Postfix
* Added tests for TLS config override
* Add missing Postfix TLS options
* Added missing new line at the end of the file
* Added STARTTLS tests for Postfix config
* Switch to stretch-slim as base image.
- first step correct the testdata, as newer packages are more strict
about the mail-structure.
* Switch to stretch-slim: correcting the test-environment and the build
- add missing build-step to make
- clean the userdb aswell
- use timeout of netcat, as postgrey would not close the connection
- there is 2 extra mail-logs -> assert_output 5
- cosmetic: use "" instead of ''
* Switch to stretch-slim:
new image:
- smaller size
- 0 CVEs compared to 11 CVEs in ubuntu 16.04 Image
better backport situation
- postfix 3.1.6 vs 3.1.0
- fail2ban 0.9.6 vs 0.9.3
...
changes needed because of stretch-slim:
- add missing gnupg and iproute2 package
- remove non-free rar, unrar-free should do
- rsyslog does not add syslog user and has different conf-structure
- pyzor command discover was deprecated and is missing in the new
stretch package
- dovecot does not know SSLv2 anymore. removed because of warnings in
log
- iptables does not know imap3, IMAP working group chose imap2 in favor
of imap3
* Switch to debian stretch slim:
SSLv2 seems to be a not known protocol anymore - good!
* switch to debian stretch slim:
make this test more stable. there might be more than only one mail.log
(mail.info, mail.warn, ...)
* switch to debian stretc slim:
new openssl 1.1.0 needs stronger ciphers, removed some weekers ones.
Please, look through the new list of cipher! this needs to be done in
another commit for all other SSL/TLS-Endpoints aswell.
* Switch to debian stretch slim:
let our server pre-empt the cipher list.
Did a read through, wwwDOTpostfixDOTorg/FORWARD_SECRECY_READMEDOThtml
and
wwwDOTpostfixDOTorg/TLS_READMEDOThtml
* Switch to debian stretch slim: lets give this openssl-based test a new and independent but identical container. many other test on the main 'mail' container might interfere here.
* Switch to debian stretch slim: remove unused lines
* Move ldap files to target dir
* Move ldap files to target dir
* Update start-mailser.sh to use copied files
* Add the domainname from container to vhost
* Fix unary operator error
* List dovecot users only when LDAP disabled
* Minor
* Adding the PERMIT_DOCKER option
See README.md for more informations
* Adding some test for PERMIT_DOCKER option
* Fix test cases
* Opendkim and Openmarc configuration
Fix docker network range
Adding opendkim and openmarc configuration
* Adding some options for tests
* Update log message
* Update tests
The dovecot-sieve plugin is installed and configured to apply sieve
as soon as a .dovecot.sieve file is encountered in the virtual user's
home directory (that is /var/mail/${domain}/${username}/.dovecot.sieve).
Transport has been changed in the postfix configuration to use
Dovecot LDA (see http://wiki.dovecot.org/LDA/Postfix) to actually
enable sieve filtering.
Tests have been added.
mail servers using an enhanced client, sender and helo
restriction configuration.
The configuration has been adapted using this blog post:
https://www.webstershome.co.uk/2014/04/07/postfix-blocking-spam-enters-server/
Basically mail servers having invalid configuration (as e.g. sending
from and dynamic IP or a misconfigured hostname) will have their
mails rejected.
Additionnally three RBL servers are used to detect spam sending
IPs: dnsbl.sorbs.net, zen.spamhaus.org and bl.spamcop.net.
The results of a 12h test drive using a 100+ daily spam
mail account (SpamAssasin was always enabled, just counting
delivered mails to inbox not counting what SA detected):
- Before: 34 incoming mails
- Afer change: 6 incoming mails (82% reduction)
Fixes#161.
