Home / server / Questions / 1040990
Accepted
Eaten by a Grue
Asked: 2020-11-03 07:40:19 +0800 CST

Is postfix respecting greylist response?

  • 772

I"m a bit confused about the activity in my mail server logs (addresses and destination redacted for privacy):

Nov  1 21:00:03 mail postfix/smtp[745742]: Trusted TLS connection established to mx.example.com[192.0.2.1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov  1 21:00:10 mail postfix/smtp[745742]: 0C1551DC073: to=<[email protected]>, relay=mx.example.com[192.0.2.1]:25, delay=7.3, delays=0.01/0.01/0.42/6.9, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 7E42A921A9A25)
Nov  1 21:00:11 mail postfix/smtp[745829]: Trusted TLS connection established to mx.example.com[192.0.2.1]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov  1 21:00:18 mail postfix/smtp[745829]: 903371DC08B: host mx.example.com[192.0.2.1] said: 451 4.7.1 Greylisting in action, please come back later (in reply to end of DATA command)
Nov  1 21:00:18 mail postfix/smtp[745829]: Trusted TLS connection established to mx.example.net[192.0.2.2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Nov  1 21:00:25 mail postfix/smtp[745829]: 903371DC08B: to=<[email protected]>, relay=mx.example.net[192.0.2.2]:25, delay=16, delays=0.01/1.4/7.7/7.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as BB99F922EC625)

It appears postfix got a greylist response on the second mail to the domain in question but then immediately re-attempted delivery to a different MX record ip (@21:00:18)? Am I misunderstanding what's going on here?

All settings are more or less default with these exceptions:

minimal_backoff_time = 180s
maximal_backoff_time = 3h

I want to make sure we are respecting the recipient provider's response but it doesn't appear that postfix waited 180 seconds before reattempting delivery as I would have expected.

postfix greylisting

1 Answers

  1. Best Answer

    Yes, postfix respects the greylist response.. but not to the letter because it does not read the English status text.

    Recommendation: Probably no need to change anything - the other MX did accept your message merely seconds later. This game of "please wait for 10 minutes" is not played by everyone doing or calling it greylisting. You really just need one extra connection to prove you operate a mail queue (or do not care to play by the rules anyway), so there is not always a point in letting other mail servers wait for longer than some reputation database lookups take.

    Explanation of the behaviour:

    Postfix does not care what the specific reason was, only that it saw a temporary error in reply to end of DATA command. The same Status code (451) and Enhanced Status Code (4.7.1) could have been used for many other reasons, and none of them clearly conveys: "Do not talk to me or my other MX".

    Until the message is deferred and subject to the _backoff_time rules, postfix does keep trying if any other MX is ready to accept the message. A mail currently in active delivery is automatically moved to the deferred queue based on one of the following two condition:

    1. all currently known mail exchangers have been tried, and none of them conclusively accepted (e.g. code 250) or permanently rejected (e.g. code 550) the message for the outstanding recipients

    2. a threshold (cohort limit) of failures have been encountered and further delivery for the destination is deferred

    If you want postfix to space out and eventually defer outstanding deliveries after seeing too many deliveries fail, use _destination_rate_delay and _destination_concurrency_failed_cohort_limit instead.

    • 1