On 24 Jul 2022, at 4:38, Laura Atkins via mailop wrote: > 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.
This poses a (perverse?) choice on the sender side. In the current state of affairs, ESPs presume they know more than the receivers, so they keep trying to send. Since the ESPs essentially disregard the 5xx codes using the line of reasoning that you described, there is less incentive for ISPs to implement enhanced codes. Clearly the ESPs chose the interpretation that maximized short term gains to them, no surprises here. Had the ESPs chose to actually stop sending on 5xx codes, ISPs would have been forced to implement the enhanced codes—or engineer their rules/filter engines differently—so that recipients wanting to stop only a specific stream would have a means to do that. Taken this a bit further, we could even have enhanced status codes to signal conditions transcending the single in-flight message. Even list unsubscribes would be simpler if we had an enhanced code to signal this condition! Nowadays the ecosystem responds by counting errors and applying more stringent blocks (drop packets, terminate sessions at HELO, etc.); or with explicit list unsubscribe mechanisms, with both eating up more resources from all parties involved. I don't think this is an optimal state. By thinking in isolation we will continue to paint ourselves in the corner. >> 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%) My data looks even worse than yours in terms of enhanced SMTP code support. To me this is a sorry state of affairs. Best regards -lem _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
