DevHeads.net

Trying to understand smtpd_recipient_restrictions order

Hi,

I was under the impression, that smtpd_recipient_restrictions and other
restriction configuration items were being processed top to bottom.

I am running postfix 3.2.2 and as far as I can see my postfix is showing a
different behavior.

I have the following items in my config:

smtpd_recipient_restrictions = check_recipient_access proxy:mysql:/etc/postfix/bounce_spam_alias.cf
check_recipient_access proxy:mysql:/etc/postfix/bounce_routes.cf
reject_unknown_recipient_domain
reject_unverified_recipient
reject_unlisted_recipient

bounce_spam_alias.cf and bounce_routes.cf are two files querying a local
mysql server for addresses that should bounce.
This seems to be successful:

[root@mailin01 postfix]# postmap -q <a href="mailto:test- ... at example dot org">test- ... at example dot org</a> mysql:/etc/postfix/bounce_routes.cf
554 test-bounce successful Mail bounced
[root@mailin01 postfix]# postmap -q <a href="mailto:test- ... at example dot org">test- ... at example dot org</a> mysql:/etc/postfix/bounce_spam_alias.cf
554 Address marked as spamtrap, mail not accepted
[root@mailin01 postfix]#

If I now use swaks to actually send mail to the test address, I would
expect one such message, instead it seems these two files are not queried
and instead the reject_unverified_recipient rule triggers immediately:

[root@mailin01 postfix]# swaks --from '<>' --to <a href="mailto:test- ... at example dot org">test- ... at example dot org</a> --server=localhost
=== Trying localhost:25...
=== Connected to localhost.
<- 220 mailin01.lan ESMTP Postfix
-> EHLO mailin01.lan
<- 250-mailin01.lan
[...]
-> MAIL FROM:<>
<- 250 2.1.0 Ok
-> RCPT TO:<test- ... at example dot org>
<** 550 5.1.1 <test- ... at example dot org>: Recipient address rejected:
undeliverable address: host mailin01.lan[private/dovecot-lmtp] said: 550
5.1.1 <test- ... at example dot org> User doesn't exist:
<a href="mailto:test- ... at example dot org">test- ... at example dot org</a> (in reply to RCPT TO command)
-> QUIT
<- 221 2.0.0 Bye

So I am unclear why this is happening. I have a smtpd_sender_restrictions
entry that seems to work top-to-bottom.

smtpd_sender_restrictions = check_client_access inline:{10.1.1.1=OK}
reject_unknown_sender_domain

The host coming in from 10.1.1.1 is able to deliver mail even if the MAIL
FROM entry is not resovable.

If I look at the logs, it seems the two entries for check_recipient_access
are not consulted:

May 9 18:47:30 mailin01 postfix/smtpd[24094]: >>> START Recipient address
RESTRICTIONS <<<
May 9 18:47:30 mailin01 postfix/smtpd[24094]: generic_checks:
name=reject_unauth_destination
May 9 18:47:30 mailin01 postfix/smtpd[24094]: reject_unauth_destination:
<a href="mailto:test- ... at example dot org">test- ... at example dot org</a>
May 9 18:47:30 mailin01 postfix/smtpd[24094]: permit_auth_destination:
<a href="mailto:test- ... at example dot org">test- ... at example dot org</a>
May 9 18:47:30 mailin01 postfix/smtpd[24094]: ctable_locate: leave
existing entry key ?test- ... at example dot org
May 9 18:47:30 mailin01 postfix/smtpd[24094]: generic_checks:
name=reject_unauth_destination status=0
May 9 18:47:30 mailin01 postfix/smtpd[24094]: generic_checks:
name=reject_unverified_recipient
May 9 18:47:30 mailin01 postfix/smtpd[24094]: reject_unverified_address:
<a href="mailto:test- ... at example dot org">test- ... at example dot org</a>
May 9 18:47:30 mailin01 postfix/smtpd[24094]: connect to subsystem
private/verify
May 9 18:47:30 mailin01 postfix/smtpd[24094]: send attr request = query
May 9 18:47:30 mailin01 postfix/smtpd[24094]: send attr address =
<a href="mailto:test- ... at example dot org">test- ... at example dot org</a>
May 9 18:47:30 mailin01 postfix/smtpd[24094]: private/verify socket:
wanted attribute: status
May 9 18:47:30 mailin01 postfix/smtpd[24094]: input attribute name:
status
May 9 18:47:30 mailin01 postfix/smtpd[24094]: input attribute value: 0
May 9 18:47:30 mailin01 postfix/smtpd[24094]: private/verify socket:
wanted attribute: recipient_status
May 9 18:47:30 mailin01 postfix/smtpd[24094]: input attribute name:
recipient_status
May 9 18:47:30 mailin01 postfix/smtpd[24094]: input attribute value: 3
May 9 18:47:30 mailin01 postfix/smtpd[24094]: private/verify socket:
wanted attribute: reason
May 9 18:47:30 mailin01 postfix/smtpd[24094]: input attribute name:
reason
May 9 18:47:30 mailin01 postfix/smtpd[24094]: input attribute value:
Address verification in progress
May 9 18:47:30 mailin01 postfix/smtpd[24094]: private/verify socket:
wanted attribute: (list terminator)
May 9 18:47:30 mailin01 postfix/smtpd[24094]: input attribute name: (end)
May 9 18:47:33 mailin01 postfix/smtpd[24094]: send attr request = query
May 9 18:47:33 mailin01 postfix/smtpd[24094]: send attr address =
<a href="mailto:test- ... at example dot org">test- ... at example dot org</a>
May 9 18:47:33 mailin01 postfix/smtpd[24094]: private/verify socket:
wanted attribute: status
May 9 18:47:33 mailin01 postfix/smtpd[24094]: input attribute name:
status
May 9 18:47:33 mailin01 postfix/smtpd[24094]: input attribute value: 0
May 9 18:47:33 mailin01 postfix/smtpd[24094]: private/verify socket:
wanted attribute: recipient_status
May 9 18:47:33 mailin01 postfix/smtpd[24094]: input attribute name:
recipient_status
May 9 18:47:33 mailin01 postfix/smtpd[24094]: input attribute value: 2
May 9 18:47:33 mailin01 postfix/smtpd[24094]: private/verify socket:
wanted attribute: reason
May 9 18:47:33 mailin01 postfix/smtpd[24094]: input attribute name:
reason
May 9 18:47:33 mailin01 postfix/smtpd[24094]: input attribute value: host
mailin01.lan[private/dovecot-lmtp] said: 550 5.1.1
<test- ... at example dot org> User doesn't exist: <a href="mailto:test- ... at example dot org">test- ... at example dot org</a> (in
reply to RCPT TO command)
May 9 18:47:33 mailin01 postfix/smtpd[24094]: private/verify socket:
wanted attribute: (list terminator)
May 9 18:47:33 mailin01 postfix/smtpd[24094]: input attribute name: (end)
May 9 18:47:33 mailin01 postfix/smtpd[24094]: NOQUEUE: reject: RCPT from
localhost[127.0.0.1]: 550 5.1.1 <test- ... at example dot org>: Recipient
address rejected: undeliverable address: host
mailin01.lan[private/dovecot-lmtp] said: 550 5.1.1
<test- ... at example dot org> User doesn't exist: <a href="mailto:test- ... at example dot org">test- ... at example dot org</a> (in
reply to RCPT TO command); from=<> to=<test- ... at example dot org>
proto=ESMTP helo=<mailin01.lan>
May 9 18:47:33 mailin01 postfix/smtpd[24094]: generic_checks:
name=reject_unverified_recipient status=2
May 9 18:47:33 mailin01 postfix/smtpd[24094]: >>> END Recipient address
RESTRICTIONS <<<

Does anyone have any pointers what I might be missing?

cheers,
Andreas

Comments

Re: Trying to understand smtpd_recipient_restrictions order

By Viktor Dukhovni at 05/09/2019 - 13:45

<a href="http://www.postfix.org/DEBUG_README.html#mail" title="http://www.postfix.org/DEBUG_README.html#mail">http://www.postfix.org/DEBUG_README.html#mail</a>

Re: Trying to understand smtpd_recipient_restrictions order

By Bastian Blank at 05/09/2019 - 13:44

Hi Andreas

On Thu, May 09, 2019 at 07:13:22PM +0200, Andreas Thienemann wrote:
What I forgot: don't bounce mails. But it's okay, as
check_recipient_access can't be used to bounce mails, just to reject
them.

Also don't list maps that should not be able to unconditionally accept
mails before something like reject_unauth_destination.

Bastian

Re: Trying to understand smtpd_recipient_restrictions order

By Bastian Blank at 05/09/2019 - 13:37

On Thu, May 09, 2019 at 07:13:22PM +0200, Andreas Thienemann wrote:
Show logs. Show complete config.

See <a href="http://www.postfix.org/DEBUG_README.html#mail" title="http://www.postfix.org/DEBUG_README.html#mail">http://www.postfix.org/DEBUG_README.html#mail</a>. As this is not your
first question on this list, I assume you have been told about that
already.

Don't split restrictions into multiple lists.

_Don't_ enable verbose logging unless instructed to.

I don't see reject_unauth_destination in anything you showed. I'm
currently not sure if it can be use implicit, but I don't think so.

You don't want to use recipient verification, make sure you can live
without.

Drop mysql until you know how it works.

Bastian

Re: Trying to understand smtpd_recipient_restrictions order

By Viktor Dukhovni at 05/09/2019 - 13:48

I disagree. Indeed as of Postfix 2.10 we have separate relay restrictions
by default. The OP's problem will be evident once the "postconf -n" output
is posted.