[Top] [All Lists]

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

2021-03-19 18:06:38

On 19 Mar 2021, at 07:39, Viktor Dukhovni 
<ietf-dane(_at_)dukhovni(_dot_)org> wrote:

On Mar 18, 2021, at 10:55 AM, Laura Atkins 
<laura(_at_)wordtothewise(_dot_)com> 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. 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 
mail stream. The MTA then adjusts, or even stops, sending for a 
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

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

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 
includes looking at all the full text of the SMTP response, not just the first

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.


ietf-smtp mailing list