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

[Laura Atkins <[e-mail]>]

> On 19 Mar 2021, at 22:47, Ned Freed <[e-mail]> wrote:
> 
> 
> 
>>> 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 ;-)

Language is definitely an issue. SMTP-speak, deliverability-speak and email-marketing-speak all use the same words in different ways and setting the language parameters for any discussion is important. 

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

You get a 452 for this transaction and you stop the transaction and then modify future transactions. The MTA developers can confirm that’s what they’re doing, but my understanding is this is what’s happening under the covers. 

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

That’s my mental model of how it works, but I don’t know for sure. I’m hoping the folks writing the MTAs will comment here. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[e-mail]
[phone]		

Email Delivery Blog: https://wordtothewise.com/blog