DevHeads.net

making unverified_recipient_reject_code safe for temp errors

Dear Users,

we have the following in place:

smtpd_recipient_restrictions = reject_unknown_recipient_domain,
reject_unverified_recipient
unverified_recipient_reject_code = 550
unknown_address_reject_code = 550

today, we had an issue with our groupware so the following was happening:

NOQUEUE: reject: RCPT from unknown[ip]: 450 4.1.1 < ... at domain dot tld>:
Recipient address rejected: unverified address: Address verification in
progress; from=< ... at intmon01 dot int.domain.tld> to=< ... at domain dot tld>
proto=ESMTP helo=<intmai01.int.domain.tld>
Oct 11 17:19:13 kop01 postfix/lmtp[5711]: E759E301412: to=< ... at domain dot tld>,
relay=127.0.0.1[127.0.0.1]:2003, delay=13, delays=0/0.01/13/0, dsn=4.0.0,
status=undeliverable (host 127.0.0.1[127.0.0.1] refused to talk to me: 421
internal error: OpenResolveAddrFolder failed)
NOQUEUE: reject: RCPT from jir01.int.domain.tld[ip2]: 450 4.1.1
<demo. ... at domain dot tld>: Recipient address rejected: unverified address:
host 127.0.0.1[127.0.0.1] refused to talk to me: 421 internal error:
GetSession failed; from=< ... at domain dot tld> to=<demo. ... at domain dot tld>
proto=ESMTP helo=<jir01.int.domain.tld>

How do we reject unknown destinations / recipients still with a perm.
error, but be more robust against temp errors like the ones above?

Comments

Re: making unverified_recipient_reject_code safe for temp errors

By Wietse Venema at 10/12/2018 - 07:27

That's the probe's 421 result:

And that's the Postfix 450 SMTP server response.

Is that clear now?

Wietse

Re: making unverified_recipient_reject_code safe for temp errors

By Stefan Bauer at 10/12/2018 - 07:47

Yes, that's it. Thank you!

Am Fr., 12. Okt. 2018 um 14:27 Uhr schrieb Wietse Venema <
... at porcupine dot org>:

Re: making unverified_recipient_reject_code safe for temp errors

By Wietse Venema at 10/11/2018 - 12:13

Stefan Bauer:
As a matter of principle, I would consider it a bug if Postfix did
a 5XX reject after Postfix received a 4XX error. It's basic error
propagation hygiene.

Wietse

Wietse

Re: making unverified_recipient_reject_code safe for temp errors

By Matus UHLAR - f... at 10/11/2018 - 12:45

On 11.10.18 13:13, Wietse Venema wrote:
otoh, I've been thinking for some time about hard rejecting senders or
recipients that could periodically be verified for some time, e.g. 1 week.

This would help much with mail for addresses that are undeliverable in the
long run - mostly spams.

Re: making unverified_recipient_reject_code safe for temp errors

By Stefan Bauer at 10/11/2018 - 12:19

We just noticed, that senders got several "550 5.1.0 Address rejected"
bounces even though postfix logs no permanent errors.

Oct 11 17:19:13 kop01 postfix/lmtp[5711]: E759E301412: to=< ... at domain dot tld>,
relay=127.0.0.1[127.0.0.1]:2003, delay=13, delays=0/0.01/13/0, dsn=4.0.0,
status=undeliverable (host 127.0.0.1[127.0.0.1] refused to talk to me: 421
internal error: OpenResolveAddrFolder failed)

Isn't status=undeliverable a 5xx reject?

Am Do., 11. Okt. 2018 um 19:14 Uhr schrieb Wietse Venema <
... at porcupine dot org>:

Re: making unverified_recipient_reject_code safe for temp errors

By Wietse Venema at 10/11/2018 - 15:12

Stefan Bauer:
The '421' is what really matters here.

Wietse

Re: making unverified_recipient_reject_code safe for temp errors

By Stefan Bauer at 10/12/2018 - 00:18

But what was postfix reporting to the Appliance that tried to deliver to
postfix?
The 421 is what postfix got from the groupware. Not what it was reporting
to the deliverer.

Our setup is appliance -> Postfix -> Groupware.

The appliance bounced several mails with a 550 5.1.0 Address rejected.

Am Do., 11. Okt. 2018 um 22:12 Uhr schrieb Wietse Venema <
... at porcupine dot org>:

Re: making unverified_recipient_reject_code safe for temp errors

By Matus UHLAR - f... at 10/12/2018 - 07:10

On 12.10.18 07:18, Stefan Bauer wrote:
search for "smtpd" lines in logs.
According to your "unverified_recipient_reject_code = 550", it could be 550.

this is postfix client, not server refusal.