Thanks for being a voice of reason, Matt. ESPs don't always get things right, but the ESPs who are participating in M3AAWG or joining forums like this one are trying to do the right thing. Bounce handling is difficult because bounce messages are like an episode of Whose Line Is It Anyway? - the status codes are made up and the text doesn't matter. Sure, there's RFCs, but once you've spent a few days going through your logs to try to improve your bounce handling and see some mail operators using 4XX bounces for what should really be a 5.1.1 invalid recipient, you lose hope in the system.
If I knew what every ISP wanted me to do after a given bounce, I'd do my best to respect that, within the boundaries of the service that I am also obligated to provide my clients. This is what we're working with, though: 451 Invalid Recipient - https://community.mimecast.com/docs/DOC-1369#451 [Lzabfop9Nva0NP5E_GxwYg.uk119] 553 sorry, no mailbox here by that name. ulc: 65216002578, rcp: 0001. (#5.7.1) 554 5.7.1 <redac...@lycos.com>: Recipient address rejected: user redac...@lycos.com does not exist 550 5.4.1 Recipient address rejected: Access denied. AS(201806281) [ SN1NAM01FT027.eop-nam01.prod.protection.outlook.com] 554 delivery error: dd Not a valid recipient - atlas215.aol.mail.bf1.yahoo.com We can all agree that a bad address should be a 550 5.1.1 error, yes? Surely we can agree on that much, since it's in the RFCs? https://www.greenend.org.uk/rjk/tech/smtpreplies.html https://tools.ietf.org/html/rfc3463#section-3.2 Mimecast, Microsoft and Verizon Media Group are not small companies. The only reason I even know the Microsoft bounce should be codified as a hard bounce is thanks to the kind folks at SparkPost for posting publicly about it: https://www.sparkpost.com/blog/bounce-classification-code-change/ I mean, if I was trying to figure out what to do with that bounce on my own, what would I do? Well, let's start with the RFC... X.4.1 No answer from host The outbound connection attempt was not answered, because either the remote system was busy, or was unable to take a call. This is useful only as a persistent transient error. Only useful as a persistent transient error? That's odd, because it was a 5xx error, not a 4xx error. Access denied? Access denied *to whom*? My IP address? My MAIL FROM domain? The sender in the friendly from? If I can't definitively tell my customer that the address is undeliverable and will never receive messages, then I have a duty to attempt subsequent deliveries until we hit our own internal threshold for converting soft bounces to hard bounces. The business logic for that determination is going to differ from ESP to ESP. I'm not saying this as an attempt to call anyone out, or start a fight, but my point is that those of us who are active in these industry mailing lists and conferences are the ones who care. We want to do better. We're up against forces internal and external. If we got it wrong, help us make it right. Maybe a C-level told us we had to do something a certain way and having an email from the ISP themselves saying "That's bad and wrong, don't do that" would tip the scales. Maybe things have changed since that legacy code was written 5 years ago and we need a nudge to refactor it. Maybe someone recently introduced a bug with the last deploy that our testing didn't catch. We're all up against the same challenges here, these are things that occur at ISPs as well. How many threads have we seen for "Is anyone else's GPT data missing/wrong" or "What the heck happened with valid emails bouncing at Yahoo yesterday"? These things happen, they happen despite our best intentions, and the sooner we learn to work together to fix them and move on instead of worrying about where to assign blame, the better the ecosystem will be for everyone. Best regards, David Carriger On Fri, Jun 5, 2020 at 8:52 AM Matt V via mailop <mailop@mailop.org> wrote: > On 2020-06-05 10:09 a.m., Atro Tossavainen via mailop wrote: > > Furthermore, I explicitly indicated that it was the consensus that the > GDPR makes it effectively impossible for them to do what you believe I > said, which I did not. It has been discussed in so many M3AAWG meetings > and between meetings, and Simon McGarr's talk "So you want to be a data > controller" was more or less on this subject. > > I don't know how you have managed to read exactly the opposite of my > intentions into my words, I can only conclude that it must have to do > with my awkward non-native use of the language because all other > explanations seem so futile. Here is what I said, for a recap. > > Most ESPs want to remain as data processors under GDPR and do not want to > be put in a position of being a data controller. Utilizing data across > multiple accounts has some very interesting impacts in regards to the > responsibility of the controller/processor or controller/controller > relationships of data. > > As for ESPs and the emails that they process on behalf of their clients, > bounces are processed and removed but each ESPs has different thresholds > for how this should be done - business logic and all. > > - ESP1 - might remove from an individual list, but nothing stops a > client from uploading a new list every time they mail. Thus giving the > appearance of neglecting bounces. > - ESP2 - might remove only after a third consecutive 5.x.x where it is > clear the user is unknown - This addresses Luke's comments on bounces for > things like account disablement/re-activation for billing issues > - ESP3 - Might bounce an address at the client level, but allow a > brand to over write that flag with a new upload > - ESP 4 - might not allow people to re-enable bounces ever... > - ESP5 - might suppress multiple bounces from multiple clients across > the board for all accounts <<< This has significant GDPR implications that > the individual client suppression doens't. > - ESP x - might do some or all of the above... > > I've seen all of these scenarios over the years, each has a different > benefit/risk - but what I can say is that every ESP I've ever worked > for/with had a different way of doing this. But they all processed bounces > as best they could and updated their rules on regular timelines. Why? > Because the standards for bounces get applied in wonky ways at each ISP - > so really the standard is non-standard. > > This is as much a client education piece as it is an industry > implementation piece. If every ESP knew that 5.5.1 meant the exact same > thing then they could treat them all the same, but having seen '4.5.1 > Unknown user', and '5.5.0 - Try again later' errors over the years ESPs > work with the data they are given to the best of their abilities and within > the laws that are applicable to them and their clients. > > I recommend you try working with them vs calling them out as being bad > actors - These teams (especially the Mailchimp team) works very hard, > harder than most hosting companies i would imagine, to stop abusive > behaviour from their networks sending billions of emails around the world. > From stopping fraudulent sign-ups to, stopping the use of purchased lists, > to shutting down accounts that get complaints - mind you much faster than > many other companies that might be part of the same abusive message on the > content hosting or domain hosting side of the house. > > -- > ~ > MATT > > _______________________________________________ > mailop mailing list > mailop@mailop.org > > https://urldefense.com/v3/__https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop__;!!JIZ-LZtDGnv5HBqN_A!ZJS85RqWxnkL_kw_Ve6vyNmAsjwiPQ69zZjfTCIO5gV1uj8S9u_b4yPZv8oLoJ9zBb8Akg$ >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
