1

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: test@recipient.com
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: test@recipient.com
postfix/smtpd[6963]: ctable_locate: leave existing entry key test@sender.com?test@recipient.com
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: test@recipient.com
postfix/smtpd[6963]: permit_auth_destination: test@recipient.com
postfix/smtpd[6963]: ctable_locate: leave existing entry key test@sender.com?test@recipient.com
postfix/smtpd[6963]: NOQUEUE: reject: RCPT from x.x.x.x[y.y.y.y]: 564 5.7.1 <test@recipient.com>: Relay access denied; from=<test@sender.at> to=<test@recipient.com> 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 test@recipient.com proxy:mysql:/etc/postfix/mysql/virtual_alias_domains.cf
recipient.com
[19:00:39][me@server:~]# postmap -q test@recipient.com 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

1
  • Sorry - I added the complete main.cf
    – Michael
    Jan 1 '21 at 21:19
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 test@recipient.com 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:~]# 
1
  • I still don't understand why the mysql log didn't show any queries at all before.
    – Michael
    Jan 2 '21 at 17:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.