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

[Ned Freed <[e-mail]>]

> > On 19 Mar 2021, at 07:39, Viktor Dukhovni <[e-mail]> wrote:
> >
> >> 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.

> I believe both. For instance, there it at least one, and I believe multiple,
> MTA(s) that actively monitor the codes during delivery and change the speed /
> connections based on the current set of response codes.

Commonly called "backoff". (A term I dislike because it's the term we chose
years earlier for specifying retry intervals, and now our documentation has
become confusing as hell ;-)

> For instance, the VMG servers will start temp failing mail with a 452 [TSS04]
> and that is a signal that there is a reputation related limit on that particular
> mail stream. The MTA then adjusts, or even stops, sending for a programatically
> determined period of time. These are real time controls and they are already
> implemented, but in a non-standard way.

But it seems that you are now effectively agreeing with Viktor - altering your
behavior for subsequent transaction is a very very different thing than altering
it during a transaction. We absolutely implement the former but not the latter -
I can't think of a case where this sort of analysis causes a change in client
behavior.

> > 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.

> There are MTA vendors that advertise things like “	Automatic backoff rules
> in case of delivery problems”. In many cases delivery problems are indicated
by>  non-standard SMTP responses by the receiver indicating there is an issue with
th> at set of deliveries.

> > 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, ...).
> > 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.


> This is not my experience dealing with the bulk end of the industry at all.
> They are heavily scrutinising and monitoring sends on a real time basis and that
> includes looking at all the full text of the SMTP response, not just the first
> digit.

Again, I think you are basically in agreement here. Unless I'm misinderstanding
something, Viktor is saying that such scrutiny does take place and is fine, but
when it happens it doesn't alter client behavior during the transaction. Nothing
you're said indicates this is happening, and given how badly it interacts with
pipelining I'm skeptical that high-end delivery systems would implement it.

				Ned