Thursday, 22 August 2013

Tracking down the cause of a Postfix "Recipient address rejected: Access denied" error

Tracking down the cause of a Postfix "Recipient address rejected: Access
denied" error

We're having a situation where inbound emails from a specific company to
legitimate recipients are bouncing with "Recipient address rejected:
Access denied":
Aug 23 09:15:27 extranet postfix/smtpd[20228]: NOQUEUE: reject: RCPT from
sender.com[8.9.10.11]: 554 5.7.1 <user@example.com>: Recipient address
rejected: Access denied; from=<user@sender.com> to=<user@example.com>
proto=ESMTP helo=<mg01d1.sender.com>
postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
allow_percent_hack = no
allow_untrusted_routing = yes
append_dot_mydomain = no
biff = no
bounce_queue_lifetime = 24h
broken_sasl_auth_clients = yes
config_directory = /etc/postfix
content_filter = smtp-amavis:[127.0.0.1]:10024
delay_warning_time = 4h
disable_vrfy_command = yes
html_directory = /usr/share/doc/postfix/html
inet_interfaces = all
mailbox_size_limit = 0
maximal_queue_lifetime = 24h
mydestination = mail.example.com, extranet.example.com, localhost
myhostname = mail.example.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = /usr/share/doc/postfix
recipient_delimiter = +
relay_domains = $mydestination
relayhost =
smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
smtpd_data_restrictions = reject_unauth_pipelining, permit
smtpd_helo_required = yes
smtpd_recipient_restrictions = reject_non_fqdn_recipient,
permit_mynetworks, reject_unauth_destination, check_recipient_access
hash:/etc/postfix/access, reject_non_fqdn_sender, check_sender_access
hash:/etc/postfix/sender_access, reject_non_fqdn_hostname,
reject_invalid_hostname, check_helo_access hash:/etc/postfix/helo_access,
reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net,
permit
smtpd_sasl_auth_enable = no
smtpd_sasl_path = private/auth
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/mail.example.com.2013.chain.pem
smtpd_tls_key_file = /etc/ssl/private/example.2013.key
smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache
smtpd_use_tls = no
virtual_alias_domains = example.co.uk, example.co
virtual_alias_maps = hash:/etc/postfix/virtual,
ldap:/etc/postfix/ldap_virtual_alias_maps.cf,
ldap:/etc/postfix/ldap_virtual_groups.cf
virtual_mailbox_domains = ldap:/etc/postfix/ldap_virtual_domains.cf
virtual_mailbox_maps = ldap:/etc/postfix/ldap_virtual_mailbox_maps.cf
virtual_transport = dovecot
Now, we only use smtpd_recipient_restrictions because we're pretty
particular about the order of client, helo, recipient restrictions being
applied. But, by my (obviously limited) understanding, the only directive
in there that should be generating that error is the
check_recipient_access hash:/etc/postfix/access directive, but that file
is only used to block some commonly spammed addresses at one of our
virtual alias domains:
postmaster@example.com.au REJECT Recipient address rejected. This domain
name is only an alias. Please email postmaster @ the primary domain or the
mail server hostname.
abuse@example.com.au REJECT Recipient address rejected. This domain
name is only an alias. Please email abuse @ the primary domain or the mail
server hostname.
support@example.com.au REJECT Recipient address rejected. This domain
name is only an alias. Please email support @ the primary domain or the
mail server hostname.
All of the other directives seem to be correctly fulfilled, or I would at
least be expecting a different error, like Helo command rejected, User
unknown in virtual mailbox table, Service unavailable; Client host
[2.3.4.5] blocked using zen.spamhaus.org, etc.
Where should I be looking next to see why I'm getting "Recipient address
rejected: Access denied"? Would any of those other directives in
smtpd_recipient_restrictions issue that error in the case of failure?

No comments:

Post a Comment