On 23 Jul 2022, at 4:17, Laura Atkins via mailop wrote: > 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.
True. But 821 has been revised multiple times just as 822. Perhaps this is something to bear in mind in their next revision. > 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. And I bet there are colleagues at those ISPs that are not happy with that implementation. Giving them incentives to drive the change would help. > 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. Perhaps if ESPs responded to that issue by effectively marking Microsoft addresses as undeliverable, would provide the incentive for MS to actively avoid that issue. One of the lessons I've learned over the years is that protecting organizations from the consequences of their own errors does not necessarily produce the intended effect. Again, incentives. > 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. I for one, am happy to have people of your stature working on that issue. I just hope that you take away the idea that while incentives are not placed where they need to be, there will be no improvement, just more half-solutions. Best regards -lem _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
