> On 23 Jul 2022, at 05:18, Bill Cole via mailop <mailop@mailop.org> wrote: > > On 2022-07-22 at 12:45:18 UTC-0400 (Fri, 22 Jul 2022 12:45:18 -0400) > Luis E. Muñoz via mailop <mailop@lem.click> > is rumored to have said: > >> On 22 Jul 2022, at 11:49, Laura Atkins via mailop wrote: >> >>>> This would allow the ESP to quickly "fail" the API request to send to that >>>> email address. There are other metrics that could be tied into those >>>> addresses and used to provide a more expedite response to the caller, >>>> which incidentally would also help deter abuse. >>> >>> In many, many cases the issue is that other customers are mailing to the >>> same address - and just because an address bounces for X sender doesn’t >>> mean that it shouldn’t be mailed for Y sender. One clear example is when >>> senders push individual user blocks out to the SMTP transaction. >> >> I question your assertion that "bounces for X sender doesn’t mean that it >> shouldn’t be mailed for Y sender". If recipient R has a history of blocking >> many senders, continuing to send from other senders is not worth it in the >> long run for the ESP. Just as receivers reject with errors such as "this >> account is receiving email at a rate that...", the ESP could respond to its >> client with "this receiver has a history of bounces / rejections / >> complaints that is incompatible with our policies...". > > If only we had a framework for error codes in SMTP that carry useful > semantics...
I agree, it would have been nice if the authors of 821 and 822 had considered this use case and provided us with semantics. Unfortunately, the semantics described in those RFCs (and their successors) only talk about what to do with the message that is rejected. There are no semantics or recommendations about what to do with future messages to the addresses that failed to accept the mail. And on the receiving side it’s not much better. All too many receiving mailservers don’t use the codes specified in the RFCs and decide to use their own implementation. A very large ISP, for instance, uses “451 this message will never deliver” as part of their repertoire of bounces. Another widely used filter rejects everything with 571 5.7.1 and in order to determine what the problem is, the sender needs to visit a webpage to search for a specific code in the text string of the bounce. Again, anyone saying this is simple doesn’t understand the complexities involved at scale and hasn’t thought about the implications of what they’re asking senders to do. Consider the case where Microsoft spits out a incorrect and false 550 user unknown (which happens every couple years). What you’re suggesting is that when this happens the next time, Gmail block every gmail user from ever sending to those hotmail users at any point in the future. That’s what you’re asking for. Unfortunately, it doesn’t take into account the actual realities of sending at scale. This is actually a problem, one I’m working with various folks in the industry to address in a way that preserves the functionality of email. I’m probably going to step away from this discussion now, though. There’s nothing being suggested here that hasn’t been tried and failed in the past. -- 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
