ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] SMTP Greylisting Retry Hints + PRDR

2019-02-08 10:24:28
> Another alternative is to split the envelope: if you know at RCPT TO time
> that the addresses have different filtering policies which might lead to
> unwanted bounces later on, 450 any subsequent addresses that have
> stricter policies than the first one. The downside is that this can lead
> to undesirable delays especially if the envelope is large.

How reliably does that work?  If I were writing an MTA I'd think a mix of
2xx and 5xx is likely but 2xx and 4xx is unexpected.

We've always referred to this as the good (2YZ), the bad (5YZ), and the ugly
(4YZ). It's a pain to handle because you have to reenqueue with a subset of
recipients, and the bookkeeping sounds like it should be straightforward, but
really isn't.

Nevertheless, the standards have effectively required that MTAs fully support it
since at least RFC 821, if not before. As I have noted many times, SMTP
just isn't that simple.

As for depending on other MTAs getting it right, while there are various ways
to get our MTA to provide a 2/4 or 2/4/5 mix of recipient responses, we don't
do so out of the box unless, say, an LDAP server failure occurs in the middle
of an SMTP session. (Extremely rare.) The few customers who have configured
things to return result mixtures involving temporary failures have generally
reported success, although there have been a few cases where it caused
problems.

All that said, when an SMTP client does get this wrong, it's not something that
easily observed from the vantage of the SMTP server returning the mixture of
results. You're basically depending on senders reporting the issue, which
almost certainly means problems are likely underreported.

                                Ned

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp