On Fri, Dec 23, 2022 at 06:58:17PM +0400, Samer Afach <samer.af...@msn.com>
wrote:
Dear postfix experts:
I think I'm getting to the end of this problem. I was able to use haproxy to
relay connections to my docker container with correct source information
(and I'm seeing the correct IP addresses in the logs of postfix/dovecot). I
would appreciate it if you could take a look at my settings before going
public and changing the MX records back to this server.
How I tested: I was actively blocking/unblocking firewalls,
starting/stopping containers (start, test, stop), and in every step, I ran
swaks, with one of these configurations (in fact, I'm planning to automate
these tests and run them periodically, what a nice tool this turned out to
be):
swaks --to a...@example.com --from=b...@example.com --server
mail.example.com:587
--tls
swaks --to a...@example.com --from=b...@example.com --server
mail.example.com:465
--tlsc
swaks --to a...@example.com --from=b...@example.com --server mail.example.com:25
--tls
swaks --to a...@example.com --from=b...@example.com --server mail.example.com:25
I was consistently getting the result "Access denied" in swaks, which I hope
means that no relaying is possible anymore. Meanwhile, I succeeded in
sending messages with Thunderbird with proper authentication.
Email relaying was only possible when sending emails with swaks through
localhost (even though it's going through the proxy in localhost), i.e.:
swaks --to a...@example.com --from=b...@example.com --server 127.0.0.1:587 --tls
swaks --to a...@example.com --from=b...@example.com --server 127.0.0.1:465
--tlsc
swaks --to a...@example.com --from=b...@example.com --server 127.0.0.1:25 --tls
swaks --to a...@example.com --from=b...@example.com --server 127.0.0.1:25
Does this constitute proof that relaying isn't possible anymore?
It looks good. You can also employ and external
testing site such as mxtoolbox.com which includes an
open relay test (enter the hostname, click "MX Lookup",
then click "SMTP Test"). This would require that the
HAproxy address and a hostname is publically available
(even if it isn't yet pointed to by any MX record).
There are three components to the configuration I added for this, each for
one port:
I have a few unimportant but informative suggestions below.
1. Port 25
in master.cf:
```
10024 inet n - n - 1 postscreen
smtpd pass - - n - - smtpd
```
and in main.cf:
```
postscreen_upstream_proxy_protocol = haproxy
```
2. Port 587 for strict STARTTLS:
```
10587 inet n - n - - smtpd
-o syslog_name=postfix/haproxy_submission
-o smtpd_tls_security_level=encrypt
-o smtpd_tls_wrappermode=no
smtpd_tls_wrappermode=no is the default and so isn't needed.
It only needs to be set (to yes) for port 465.
-o smtpd_enforce_tls=yes
smtpd_enforce_tls=yes is redundant with smtpd_tls_security_level=encrypt.
It's the obsolete equivalent, and so it's ignored when
smtpd_tls_security_level is present.
-o smtpd_sasl_auth_enable=yes
-o
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
You probably don't want permit_mynetworks in the above.
"permit_sasl_authenticated,reject" is enough.
-o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
Again, permit_mynetworks isn't needed above.
-o smtpd_upstream_proxy_protocol=haproxy
```
3. Port 465 for strict wrapper mode:
```
10465 inet n - n - - smtpd
-o syslog_name=postfix/haproxy_smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o
smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
-o
smtpd_client_restrictions=permit_mynetworks,permit_sasl_authenticated,reject
You probably don't need smtpd_client_restrictions since
smtpd_recipient_restrictions
has identical restrictions, and permit_mynetworks isn't needed (SASL is
necessary
and sufficient).
-o smtpd_upstream_proxy_protocol=haproxy
```
The other standard ports (25, 465 and 587) without proxying are unreachable
from the outside.
And finally, `postconf -n` (I fixed the issues indicated in the email chain
after having read their documentation):
```
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
broken_sasl_auth_clients = yes
debug_peer_level = 6
debug_peer_list = 0.0.0.0/0
disable_vrfy_command = yes
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
maillog_file = /dev/stdout
message_size_limit = 0
milter_default_action = accept
milter_protocol = 2
mydestination = localhost
myhostname = example.com
mynetworks_style = subnet
myorigin = localmail.example.com
non_smtpd_milters = inet:docker-email-opendkim:12301
postscreen_upstream_proxy_protocol = haproxy
proxy_read_maps = $local_recipient_maps $mydestination $virtual_alias_maps
$virtual_alias_domains $virtual_mailbox_maps $virtual_mailbox_domains
$relay_recipient_maps $relay_domains $canonical_maps $sender_canonical_maps
$recipient_canonical_maps $relocated_maps $transport_maps $mynetworks
$smtpd_sender_login_maps
readme_directory = no
recipient_delimiter = +
relay_domains =
relayhost =
smtp_tls_cert_file = /shared-keys/mail.example.com/fullchain.pem
smtp_tls_key_file = /shared-keys/mail.example.com/privkey.pem
The above two parameters should probably be renoved.
Specifying a particular key for outgoing TLS connections
is only important when connecting to specific remote
servers that require your server to use a specific
known key. That doesn't look to be the case here.
Usually, you only need to specify the cert/key files
for the smtpd_ versions of these parameters. See below
for comments on those.
smtp_tls_loglevel = 1
smtp_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtp_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
The above parameter isn't needed (and maybe the one
above it too). TLSv1 and TLSv1.1 are better than no
encryption at all. And these settings are for outgoing
connections. So even if your mail server is scanned as
part of a naive cookie-cutter security assessment, the
scanner won't know that you are willing to use those
deprecated protocols for sending mail, and so won't
complain. If you don't exclude TLSv1 and TLSv1.1 in the
similar smtpd_tls_protocols parameter, such a scanner
would complain, even though it's still better than no
encryption. Security scanners usually assume that
policies that should apply to a web server (using
mandatory encryption) should also apply to a mail
server (using opportunistic encryption).
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_client_restrictions = permit_mynetworks, reject
smtpd_helo_restrictions = reject_invalid_helo_hostname,
smtpd_milters = inet:docker-email-opendkim:12301
smtpd_recipient_restrictions = check_sender_access
hash:/etc/postfix/sender_access, permit_sasl_authenticated,
permit_mynetworks, reject_unauth_destination, reject_invalid_hostname,
reject_unknown_recipient_domain, reject_unauth_destination,
reject_rbl_client sbl.spamhaus.org, reject_rbl_client
b.barracudacentral.org, reject_rbl_client zen.spamhaus.org,
reject_rbl_client truncate.gbudb.net, reject_rbl_client bl.spamcop.net,
reject_rbl_client cbl.abuseat.org, permit
In smtpd_recipient_restrictions, permit_mynetworks usually appears
before permit_sasl_authenticated, but that might not matter.
It has reject_unauth_destination twice.
I could be wrong but I think zen.spamhaus.org subsumes sbl.spamhaus.org
so sbl.spamhaus.org can be removed (but I'm not 100% sure of that).
smtpd_relay_restrictions = permit_sasl_authenticated permit_mynetworks
reject_unauth_destination
smtpd_relay_restrictions = permit_sasl_authenticated permit_mynetworks
reject_unauth_destination
You have smtpd_relay_restrictions appearing twice.
I'm surprised that that happened with postconf -n.
And permit_mynetworks usually appears before permit_sasl_authenticated.
But note that SASL authentication won't happen over port 25 anyway.
Maybe these references to permit_sasl_authenticated shouldn't appear
in main.cf at all (i.e. only in master.cf when permit_sasl_authenticated
is set to yes).
smtpd_sasl_auth_enable = yes
The above should be removed. Enabling SASL on port 25
just encourages brute force authentication attempts.
Such attempts will happen on ports 587 and 465 anyway,
but there's no need to encourage them on port 25 as
well.
smtpd_sasl_authenticated_header = yes
smtpd_sasl_path = /shared-socks/auth_dovecot
smtpd_sasl_type = dovecot
smtpd_sender_login_maps =
proxy:mysql:/etc/postfix/mysql_sender_login_maps.cf
smtpd_tls_auth_only = yes
smtpd_tls_ciphers = high
smtpd_tls_cert_file = /shared-keys/mail.example.com/fullchain.pem
smtpd_tls_key_file = /shared-keys/mail.example.com/privkey.pem
It's not super important but it would be better to
replace the above two parameters with
smtpd_tls_chain_files referring to a single file that
contains the contents of privkey.pem followed by the
contents of fullchain.pem. If the contents of these
files change on a regular schedule (such as via
LetsEncrypt), then you'd need to automate the creation
of such a file whenever the two source files change.
The benefit of doing this is that it eliminates the
slight chance of a race condition while the files are
being updated and Postfix might read the old version of
one file and the new version of the other file.
smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
smtpd_tls_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
See the note above about the smtp_ versions of the above two.
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
The above parameter isn't needed anymore (since Postfix 2.11).
It should be removed.
smtpd_use_tls = yes
The above is obsolete/redundant when smtpd_tls_security_level is set.
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql_virtual_alias_maps.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/vmail/
virtual_mailbox_domains =
proxy:mysql:/etc/postfix/mysql_virtual_domains_maps.cf
virtual_mailbox_limit = 0
virtual_mailbox_maps =
proxy:mysql:/etc/postfix/mysql_virtual_mailbox_maps.cf
virtual_minimum_uid = 104
virtual_transport = lmtp:inet:docker-email-dovecot:10024
virtual_uid_maps = static:5000
```
I would really appreciate your input on this. Have a great day.
Cheers,
Sam
cheers,
raf
