Postfix 3.4 always rejects incoming mails with reject_unauth_destination - ignoring virtual maps
I am migrating our servers from Debian 8 to Debian 10. Right now, I am trying to setup our mailserver (postfix-dovecot-mysql). While I was able to setup mysql (MariaDB 10.3) as such and Dovecot without any signifcant problems, I keep running into the same issue with postfix (3.4.14):
All mail coming in from external mailservers through SMTP are rejected: 554 Relay access denied
master.cf (for smtp service):
# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (no) (never) (100)
# ==========================================================================
smtp inet n - y - - smtpd -v
-o smtpd_sasl_auth_enable=no
My permit/reject rules in main.cf are:
#1 client
smtpd_client_restrictions = permit_mynetworks
permit_sasl_authenticated
reject_unknown_client_hostname
#2 helo
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
#3 sender
smtpd_sender_restrictions = permit_mynetworks
permit_sasl_authenticated
reject_non_fqdn_sender
reject_sender_login_mismatch
#4 relay
smtpd_relay_restrictions = reject_non_fqdn_recipient
permit_mynetworks
permit_sasl_authenticated
permit_auth_destination
reject_unauth_destination
#5 recipient
smtpd_recipient_restrictions = check_recipient_access proxy:mysql:/etc/postfix/mysql/recipient_access.cf
#6 data
smtpd_data_restrictions = reject_unauth_pipelining
Also, I set mydestination to empty to ensure virtual transport
mydestination =
I have confirmed that the reject_unauth_destination triggers the reject by setting different status codes:
relay_domains_reject_code = 564
access_map_reject_code = 574
maps_rbl_reject_code = 584
The status code is now always 564 and according to the postfix manual the relay_domains_reject_code is fired if the reject_unauth_destination rule kicked in.
The part I don't understand (even after many hours of trial-and-error as well as internet research) is that postfix seems to ignore my mysql based virtual maps, since mysql logging shows that no queries are executed. The only query I can see is the one from smtpd_recipient_restrictions which returns OK.
The mail.log shows the following: (I have just made the email addresses anonymous and masked the IP addresses):
postfix/smtpd[6963]: >>> START Recipient address RESTRICTIONS <<<
postfix/smtpd[6963]: generic_checks: name=reject_non_fqdn_recipient
postfix/smtpd[6963]: reject_non_fqdn_address: [email protected]
postfix/smtpd[6963]: generic_checks: name=reject_non_fqdn_recipient status=0
postfix/smtpd[6963]: generic_checks: name=permit_mynetworks
postfix/smtpd[6963]: generic_checks: name=permit_mynetworks status=0
postfix/smtpd[6963]: generic_checks: name=permit_sasl_authenticated
postfix/smtpd[6963]: generic_checks: name=permit_sasl_authenticated status=0
postfix/smtpd[6963]: generic_checks: name=permit_auth_destination
postfix/smtpd[6963]: permit_auth_destination: [email protected]
postfix/smtpd[6963]: ctable_locate: leave existing entry key [email protected][email protected]
postfix/smtpd[6963]: generic_checks: name=permit_auth_destination status=0
postfix/smtpd[6963]: generic_checks: name=reject_unauth_destination
postfix/smtpd[6963]: reject_unauth_destination: [email protected]
postfix/smtpd[6963]: permit_auth_destination: [email protected]
postfix/smtpd[6963]: ctable_locate: leave existing entry key [email protected][email protected]
postfix/smtpd[6963]: NOQUEUE: reject: RCPT from x.x.x.x[y.y.y.y]: 564 5.7.1 <[email protected]>: Relay access denied; from=<[email protected]> to=<[email protected]> proto=SMTP helo=<z.z.z.z>
postfix/smtpd[6963]: generic_checks: name=reject_unauth_destination status=2
postfix/smtpd[6963]: >>> END Recipient address RESTRICTIONS <<<
The permit_auth_destination check does not kick in - even though it should, as (according to the postfix manual) it kicks in if th recipient address is listed in either virtual_alias_domains or virtual_mailbox_domains. I have confirmed that both is true in my case by running:
[19:00:39][me@server:~]# postmap -q [email protected] proxy:mysql:/etc/postfix/mysql/virtual_alias_domains.cf
recipient.com
[19:00:39][me@server:~]# postmap -q [email protected] proxy:mysql:/etc/postfix/mysql/virtual_mailbox_domains.cf
recipient.com
Right after the permit_auth_destination not kicking in, the reject_unauth_destination does kick in - even though it should not, for the same reason.
As mentioned earlier, I can see from the mysql logs, that no queries are executed by postfix at this time. I have no idea how postfix makes the desicion to not trigger permit_auth_destination but to trigger reject_unauth_destination.
What could be causing this behaviour?
This is the full main.cf:
###########
# Network #
###########
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
#mydomain =
myhostname = mail.server.com
mydestination =
inet_interfaces = all
inet_protocols = ipv4, ipv6
smtp_address_preference = ipv4
smtpd_banner = $myhostname ESMTP $mail_name
#########
# Local #
#########
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
###########
# Virtual #
###########
proxy_read_maps = proxy:mysql:/etc/postfix/mysql/virtual_alias_maps.cf
proxy:mysql:/etc/postfix/mysql/virtual_alias_domains.cf
proxy:mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf
proxy:mysql:/etc/postfix/mysql/virtual_mailbox_domains.cf
proxy:mysql:/etc/postfix/mysql/recipient_access.cf
virtual_mailbox_base = /home/vmail/mailboxes
virtual_alias_maps = proxy:mysql:/etc/postfix/mysql/virtual_alias_maps.cf
virtual_alias_domains = proxy:mysql:/etc/postfix/mysql/virtual_alias_domains.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/mysql/virtual_mailbox_maps.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/mysql/virtual_mailbox_domains.cf
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_minimum_uid = 5000
local_recipient_maps = $virtual_mailbox_maps
################
# TLS settings #
################
tls_ssl_options = NO_COMPRESSION
################
# TLS outbound #
################
smtp_dns_support_level = dnssec
smtp_tls_security_level = may
proxy:mysql:/etc/postfix/msql/smtp_tls_policy_maps.cf
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_protocols = !SSLv3, TLSv1.3
smtp_tls_ciphers = high
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
###############
# TLS inbound #
###############
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtpd_tls_protocols = !SSLv3, TLSv1.3
smtpd_tls_ciphers = high
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_cert_file = /etc/letsencrypt/getssl-certs/mail.server.com/chain.pem
smtpd_tls_key_file = /etc/letsencrypt/getssl-certs/mail.server.com/key.pem
###################################
# Local mail delivery via Dovecot #
###################################
virtual_transport = lmtp:unix:private/dovecot-lmtp
#############
# SASL auth #
#############
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
#########
# Relay #
#########
#1 client
smtpd_client_restrictions = permit_mynetworks
permit_sasl_authenticated
reject_unknown_client_hostname
#2 helo
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
#3 sender
smtpd_sender_restrictions = permit_mynetworks
permit_sasl_authenticated
reject_non_fqdn_sender
reject_sender_login_mismatch
#4 relay
smtpd_relay_restrictions = reject_non_fqdn_recipient
permit_mynetworks
permit_sasl_authenticated
permit_auth_destination
reject_unauth_destination
#5 recipient
smtpd_recipient_restrictions = check_recipient_access proxy:mysql:/etc/postfix/mysql/recipient_access.cf
#6 data
smtpd_data_restrictions = reject_unauth_pipelining
#7 end-of-data
relay_domains_reject_code = 564
access_map_reject_code = 574
maps_rbl_reject_code = 584
#################
# Miscellaneous #
#################
mail_owner = postfix
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
biff = no
append_dot_mydomain = no
readme_directory = no
compatibility_level = 2
UPDATE
If I change my virtual_mailbox_domains setting from the proxy:mysql lookup to a static value (the domain of the recipient) everything works as expected:
virtual_mailbox_domains = static:recipient.com
It looks like the specific lookup via mysql is the problem. This is particularly strange, as the problem seems to exist for the smtpd_relay_restrictions only (no mysql query executed). It works fine (mysql query is executed) for the smtpd_recipient_restrictions
Solution 1:
I was finally able to sort this out by looking at the verbose logs of proxymap.
The key that is handed over to the mysql query is actually just the domain of the recipient, not the entire email address:
postfix/proxymap[23555]: master_notify: status 0
postfix/proxymap[23555]: proxymap socket: wanted attribute: request
postfix/proxymap[23555]: input attribute name: request
postfix/proxymap[23555]: input attribute value: lookup
postfix/proxymap[23555]: proxymap socket: wanted attribute: table
postfix/proxymap[23555]: input attribute name: table
postfix/proxymap[23555]: input attribute value: mysql:/etc/postfix/mysql/virtual_mailbox_domains.cf
postfix/proxymap[23555]: proxymap socket: wanted attribute: flags
postfix/proxymap[23555]: input attribute name: flags
postfix/proxymap[23555]: input attribute value: 524352
postfix/proxymap[23555]: proxymap socket: wanted attribute: key
postfix/proxymap[23555]: input attribute name: key
postfix/proxymap[23555]: input attribute value: recipient.com
postfix/proxymap[23555]: proxymap socket: wanted attribute: (list terminator)
postfix/proxymap[23555]: input attribute name: (end)
postfix/proxymap[23555]: proxy_map_find: mysql:/etc/postfix/mysql/virtual_mailbox_domains.cf:
postfix/proxymap[23555]: send attr status = 1
postfix/proxymap[23555]: send attr value =
postfix/proxymap[23555]: master_notify: status 1
In this case it seems like the %d parameter (which should actually carry the domain name) cannot be used for the mysql query. Using %s (which carries the original input key) finally worked.
I actually realized that %d is empty by running postmap with the domain only and getting no result:
[me@server:~]# postmap -q [email protected] proxy:mysql:/etc/postfix/mysql/virtual_alias_domains.cf
recipient.com
[me@server:~]# postmap -q recipient.com proxy:mysql:/etc/postfix/mysql/virtual_mailbox_domains.cf
[me@server:~]#