docker-mailserver/target/postfix/main.cf

116 lines
4.7 KiB
CFEngine3
Raw Normal View History

2016-04-15 19:02:41 +00:00
# See /usr/share/postfix/main.cf.dist for a commented, more complete version
smtpd_banner = $myhostname ESMTP
2016-04-15 19:02:41 +00:00
biff = no
append_dot_mydomain = no
readme_directory = no
# Basic configuration
# myhostname =
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
mydestination = $myhostname, localhost.$mydomain, localhost
relayhost =
mynetworks = 127.0.0.0/8 [::1]/128 [fe80::]/64
2016-04-15 19:02:41 +00:00
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
# TLS parameters
Dual certificate support (eg ECDSA with RSA fallback) (#1801) * feat: Change Postfix smtpd_tls key and cert files to chain_files Since Postfix 3.4, `smtpd_tls_cert_file` and `smtpd_tls_key_file` have been deprecated in favor of `smtpd_tls_chain_files` which supports a list of values where a single or sequence of file paths provide a private key followed by it's certificate chain. * feat: Dual certificate support `smtpd_tls_chain_files` allows for multiple key+cert bundles so that you can provide different key types, such as ECDSA and RSA. To maintain compatibility with the current CERT/KEY ENV vars only a 2nd certificate is supported. Since Dovecot 2.2.31 a related feature is also available, but it is limited to only providing one alternative certificate via separate cert and key settings. --- This feature enables support for multiple certificates, eg for serving modern ECDSA certs with RSA as fallback. * chore: Refactor variable names to meet style guide Improved some comments too. * chore: Have function definitions respect style guide * chore: Minor edits to comments * chore: Expand on comments for maintenance, alert of insecure config When `SSL_TYPE` isn't properly setup, we're still offering SSL connections but not warning in logs about the insecurity of such, or why a misconfiguration may have occurred. This commit more clearly communicates to the user that they should look into the issue before considering deploying to production. The `TODO` comments communicate to any future maintainer to consider treating these improper configs as disabling TLS instead. * fix: Use `snakeoil` cert I mistakenly thought this was placeholder text, which broke some tests. This adds the two files in the correct order (private key followed by cert/chain), to fix that issue. * fix: Disable alt cert for Dovecot if necessary Certain scenarios may persist state of previously configured alt cert via ENV vars that are removed from a future run. If the config is not reset to original immutable state, this will correctly disable the config from using alt cert unintentionally. * fix: Satisfy ShellCheck lint By switching from string var to array / list expansion, this better stores the extracted result and applies it in a manner that ShellCheck linting approves, removing the need to disable the rule. * feat: Support dual cert test Few tweaks to the test script allows re-purposing it for covering dual cert support as well. * chore: Rearranged cert and key lines A little reorganization, mostly placing private key ahead of related cert lines. * chore: Refactor `_set_certificate` This should make the parameters a little less confusing. Previously was 3 parameters, but the Postfix parameter (1st) may look like two variables if you don't pay attention to the surrounding quotes; while the Dovecot parameters (2nd + 3rd) would have an opposing order. There was also a variant where the `FULLKEYCHAIN` var was passed in three times. Now it's two params, with the 2nd param as an optional one. If the 2nd param is provided, then the two params are in the order of private key then certificate, otherwise if only a single parameter it's a single PEM file with the full cert chain and private key bundled. This avoids implying that Postfix and Dovecot might use different files. * chore: Document current state of `SSL_TYPE` logic better Inlined for the benefit of anyone else maintaining this section if I'm unable to address the concerns within my own time. * docs: ENV vars `TLS_LEVEL=old` isn't in the codebase anymore, not likely to be relevant to retain. No point in documenting what is considered invalid / unsupported config value in the first place for `SSL_TYPE`. `SSL_TYPE=manual` was missing documentation for both related file path ENV vars, they've been added along with their alt fallback variants. * chore: Update Dovecot LMTP SSL test config Not sure how relevant this is, the file isn't complete sync with the main dovecot `10-ssl.conf` config, adding the support just in case. * chore: Rename `FULLKEYCHAIN` to avoid confusion There doesn't appear to be a standardized name for this type of file bundle, and `keychain` may be misleading (fullkeychain often provides macOS keychain results on search engines). Opting for a more explicit `KEY_WITH_FULLCHAIN` name instead. * fix: Invalid var name `_set_certificate` refactor commit accidentally changed a var name and committed that breaking the dual cert support (thanks tests!). * test: Refactor `mail_ssl_manual.bats` Proper test return values instead of `wc -l` based checking. Tests with dual cert support active, tests that feature (to better detect failure case. Third test case was unable to verify new self-signed certificate, added new certs signed with self-signed root CA. Adjusted openssl `CApath` parameter to use `CAfile` instead as `letsencrypt` cert was replaced thus CA cert is missing from the system trust store. * test: Properly check for files in `mail_ssl_manual.bats` Fixes lint error. Also realized I was accidentally asserting a file exists in the test environment, not within the container. Resolved that and also added an additional test case to ensure the ENV var files are valid when passed in, in the event a change misconfigures them and that the issue is identified earlier. * chore: Apply PR review feedback Better format some strings that had mixed quotes when they weren't necessary. Additionally DRYed up the config path for Postfix and Dovecot within the `_setup_ssl` method. Co-authored-by: Georg Lauterbach <infrastructure@itbsd.com>
2021-02-21 22:43:41 +00:00
# These [snakeoil files actually exist](https://askubuntu.com/questions/396120/what-is-the-purpose-of-the-ssl-cert-snakeoil-key), but shouldn't ever be used in production!
# If no `SSL_TYPE` env is set, "plaintext" is configured, but still accepts SSL with these:
smtpd_tls_chain_files = /etc/ssl/private/ssl-cert-snakeoil.key /etc/ssl/certs/ssl-cert-snakeoil.pem
#smtpd_tls_CAfile =
#smtp_tls_CAfile =
2016-04-15 19:02:41 +00:00
smtpd_tls_security_level = may
debian stretch slim (#784) * 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
2017-12-31 11:33:48 +00:00
smtpd_tls_loglevel = 1
2016-04-15 19:02:41 +00:00
smtp_tls_security_level = may
smtp_tls_loglevel = 1
# Reduces CPU overhead with `NO_COMPRESSION`, SMTP not at risk of CRIME attack (see git blame for details)
# Reduce opportunities for a potential CPU exhaustion attack with `NO_RENEGOTIATION`
tls_ssl_options = NO_COMPRESSION, NO_RENEGOTIATION
tls_high_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
debian stretch slim (#784) * 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
2017-12-31 11:33:48 +00:00
tls_preempt_cipherlist = yes
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
2016-04-15 19:02:41 +00:00
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_exclude_ciphers = aNULL, SEED, CAMELLIA, RSA+AES, SHA1
smtpd_tls_dh1024_param_file = /etc/postfix/dhparams.pem
smtpd_tls_CApath = /etc/ssl/certs
smtp_tls_CApath = /etc/ssl/certs
2016-04-15 19:02:41 +00:00
# Settings to prevent SPAM early
smtpd_helo_required = yes
smtpd_delay_reject = yes
smtpd_helo_restrictions = permit_mynetworks, reject_invalid_helo_hostname, permit
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unauth_destination, check_policy_service unix:private/policyd-spf, reject_unauth_pipelining, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_recipient_domain, reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]
smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_unauth_pipelining
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_unknown_sender_domain, reject_unknown_client_hostname
disable_vrfy_command = yes
Introducing Postscreen (#799) * 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
2018-02-04 20:31:08 +00:00
# Postscreen settings to drop zombies/open relays/spam early
postscreen_dnsbl_action = enforce
postscreen_dnsbl_sites =
zen.spamhaus.org=127.0.0.[2..11]*3
bl.mailspike.net=127.0.0.[2;14;13;12;11;10]
b.barracudacentral.org*2
bl.spameatingmonkey.net=127.0.0.2
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
postscreen_dnsbl_threshold = 3
postscreen_dnsbl_whitelist_threshold = -1
Introducing Postscreen (#799) * 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
2018-02-04 20:31:08 +00:00
postscreen_greet_action = enforce
postscreen_bare_newline_action = enforce
2016-04-15 19:02:41 +00:00
# SASL
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = /var/spool/postfix/private/auth
smtpd_sasl_type = dovecot
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $mydomain
2016-04-15 19:02:41 +00:00
broken_sasl_auth_clients = yes
# Mail directory
virtual_transport = lmtp:unix:/var/run/dovecot/lmtp
2016-04-15 19:02:41 +00:00
virtual_mailbox_domains = /etc/postfix/vhost
virtual_mailbox_maps = texthash:/etc/postfix/vmailbox
virtual_alias_maps = texthash:/etc/postfix/virtual
2016-04-15 19:02:41 +00:00
# Additional option for filtering
content_filter = smtp-amavis:[127.0.0.1]:10024
# Milters used by DKIM
milter_protocol = 6
2016-04-15 19:02:41 +00:00
milter_default_action = accept
dkim_milter = inet:localhost:8891
dmarc_milter = inet:localhost:8893
feature: provide better rspamd suppport (#3016) * added options to toggle OpenDKIM & OpenDMARC rspamd can provide DKIM signing and DMARC checking itself, so users should be able to disable OpenDKIM & OpenDMARC. The default is left at 1, so users have to to opt-in when the want to disable the features. * misc small enhancements * adjusted start of rspamd The order of starting redis + rspamd was reversed (now correct) and rspamd now starts with the correct user. * adjusted rspamd core configuration The main configuration was revised. This includes AV configuration as well as worker/proxy/controller configuration used to control the main rspamd processes. The configuration is not tested extensively, but well enough that I am confident to go forward with it until we declare rspamd support as stable. * update & improve the documentation * add tests These are some initial tests which test the most basic functionality. * tests(refactor): Improve consistency and documentation for test helpers (#3012) * added `ALWAYS_RUN` target `Makefile` recipies (#3013) This ensures the recipies are always run. Co-authored-by: georglauterbach <44545919+georglauterbach@users.noreply.github.com> * adjusted rspamd test to refactored test helper functions * improve documentation * apply suggestions from code review (no. 1 by @polarthene) Co-authored-by: Brennan Kinney <5098581+polarathene@users.noreply.github.com> * streamline heredoc (EOM -> EOF) * adjust rspamd test (remove unnecessary run arguments) Co-authored-by: Brennan Kinney <5098581+polarathene@users.noreply.github.com>
2023-01-25 09:28:59 +00:00
smtpd_milters =
non_smtpd_milters =
# SPF policy settings
policyd-spf_time_limit = 3600
# Header checks for content inspection on receiving
header_checks = pcre:/etc/postfix/maps/header_checks.pcre
# Remove unwanted headers that reveal our privacy
smtp_header_checks = pcre:/etc/postfix/maps/sender_header_filter.pcre
# The default compatibility_level is 0 - which retains legacy settings defaults:
# http://www.postfix.org/COMPATIBILITY_README.html
# If backwards-compaitibilty log messages appear, fix them by explicitly adding
# the legacy or new default value (alternatively raise the compatibility_level)
#
# TODO: The next compatibility_level is 3.6, when Postfix 3.6 is available consider
# bumping this value after taking the compaitibilty changes into account.
compatibility_level = 2