Re: [ietf-smtp] [ dispatch] Forced SMTP redirects

[Ned Freed <[e-mail]>]

> > On Mar 18, 2021, at 10:55 AM, Laura Atkins <[e-mail]> wrote:
> > MTAs that send high volumes of email do pay attention to the other
> > digits and the extended codes. In fact, many of them do full text parsing to try
> > and determine how they should handle future mail to that address.
> > https://smtpfieldmanual.com is one example.

> Is this "paying attention" really happening *during* delivery, to
> guide further progress of the SMTP transaction, or, as seems more
> likely, rather an after-the-fact forensic analysis to keep lists
> in good hygiene.

Exactly. The problem with paying attention during delivery and modifying your
behavior acordingly more or less precludes pipelining. And since the vast
majority of deliveries are successful, the cost of doing this far
outweighs the benefits.

> Detailed SMTP server replies are certainly useful forensically,
> what's under discussion in this thread, is to what extent the SMTP
> protocol engine in the sending client really needs to be concerned
> with such details.

Well... not just forensically. A particular response may divulge the
fact that a rate limit has been hit, an IP address has suffered
a reputation or may not have an established reputation, and so on.

But regardless of how the information is used, your point is valid: This all
happens later, where later may be the very next transaction, the next session,
or even after some committee has met and reviewed the logs.

> Occasionally, an MTA with an uncertain reputation may choose to
> conditionally soften a 5XX reply to a 4XX reply, if it has another
> means to reach the destination (from a different IP address, ...).

Quite right. And there are also a few cases where it makes sense to treat a
temporary error as permanent.

But this is all based on observation of server behavior. It's at a completely
different level than that of how an SMTP client is supposed to behave
during an SMtP session. 

> Perhaps that's the every-day reality for some sending systems, and
> in that case I can see these closely scrutinising the server reply.
> In most other cases, there's little reason to look beyond the first
> digit.

And even when there is reason, let's not forget that the focus of RFC 5321bis is
and needs to be on basic client behavior. The supposedly "simple" mail transfer
protocol is sufficiently complicated in practice that just doing that is more
than enough for the document to cover.

				Ned