> On 23 Jul 2022, at 20:34, John Levine via mailop <mailop@mailop.org> wrote: > > It appears that Bill Cole via mailop <mailop-20160...@billmail.scconsult.com> > said: >> If only we had a framework for error codes in SMTP that carry useful >> semantics... > > We do. That's what the enhanced error codes are for. See RFCs 1893 and > 5248. A lot of them are quite informative, e.g. 5.2.2 mailbox full, > 5.7.13 user account disabled, 5.5.3 too many recipients, or > 5.7.28 mail flood detected.
You both missed my point. The RFCs in question both discuss about disposition of the message currently being attempted. None of the semantics involve what to do with future mail to that address. Part of the problem here is we’re trying to apply semantics that not only do not exist they were never intended to exist in the current framework. As I once explained it as part of a deposition (and this is a very short excerpt) to lawyers and judges the following way: Bounce handling is like calling a receptionist that is only allowed to say three things when you ask to speak to someone at their company. 2xy “Yes, I will put you right through.” 4xy “I cannot put you through now, try to call back about this issue later” 5xy “I cannot put you through now and won’t unless you do something different” That’s it. It says nothing about whether or not the employee is still there. It says nothing about whether or not the employee is the right one to talk to. It says nothing about whether or not the employee even works there any longer. It’s simply a Yes, No, Maybe regarding the call (email) currently being attempted. We’re trying to pull ‘what to do with a completely different message that might be sent in the future, possibly by a completely different sender' out of a signalling system that was never designed to convey that signal. And, yes, even the eSMTP codes RFCs are about this message in this SMTP transaction. They don’t convey what to do with future mail, either. > Recipient systems don't have a whole lot of incentive to provide those codes > because they correctly believe that most senders will ignore them, and some > senders will use them to try to game their filters. And many recipient systems don’t have enhanced SMTP codes at all. Yahoo doesn’t, for instance. Mimecast handles a lot of SMB mail and they don’t provide them, either. A bunch of the German mailbox providers don’t provide them. In fact, I’d say that eSMTP codes are the exception, not the rule. At the risk of derailing the conversation by providing actual facts and numbers: Client 1 B2B list: short excerpt of bounce logs. 882 entries, 734 do not have eSMTP codes (84%) . Client 2 B2C list: short excerpt of bounce logs. 141,142 entries. 116,243 do not have eSMTP codes (82%) These are two random bits of bounce logs I picked (mostly because they were a B2B client and a B2C client and their logs are loaded in my OpenRefine instance). Honestly, it’s even lower than I thought. I was going to say only 40 - 60% of bounces had eSMTP codes. But apparently I was overestimating. laura -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
