when you give at least a 4xx error to an RCPT TO, it makes the sending mailer think that there is a problem with that RCPT TO address, not with the MAIL FROM address. The sending mailer may then sensibly defer all email to that recipient, because after all you told it that there was a problem with that address.

I see nothing in the specs that justify such an assumption. (In fact, RFC 2821 itself even provides at least one counterexample: it recommends a server response code of 452 if the server's site-policy limitation on the number of RCPT commands in a single SMTP transaction is exceeded.)

Theoretically this also allows you to accept mail for postmaster whether or not the sender address actually exists.

...or whether or not the sender address or connecting host is blacklisted. There is considerable merit in allowing blacklisted sites to contact you to let you know that you've blacklisted them in error.

Of course, if you're rejecting the message due to blacklisting, including the sender address definitively not existing, you're better off doing it with a 5xx response code; 4xx should only (if ever) be returned if there actually was a temporary failure trying to determine whether the address was acceptable and a retry might actually succeed.

(It's probably reasonable to assume that blacklisted addresses will stay blacklisted in the short term; it's too inefficient to classify a failure as temporary on the off-chance that the sender address might get whitelisted by the next delivery attempt.)

This begs the question, for such mailers that defer all messages in response to a 4xx response to RCPT TO: if it got a 5xx response code instead, would it bounce all messages for that address?

--Dan

My feelings on blacklist appeals are verbose enough to make an entry, BlacklistAppeals.

All our definite rejects are 5xx errors (including blacklisting). The specific case where this issue came up was a 'temporarily' unresolvable MAIL FROM domain, which has to get a 4xx error.

I believe that the RFCs are silent on MTA retry policies (except to say that 5xx errors should not be retried and 4xx errors should be), which is sensible; retry policies are really beyond their scope.

I don't know if this particular mailer would auto-bounce further email to an address on a 5xx failure without trying a SMTP session; it's a hard thing to test from the outside. (And it might depend on whether the email the email was queued at the time or came in later.)