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.
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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp