On 6/24/23 14:03, Andy Smith via mailop wrote: If this sort of thing is common amongst large senders, does that mean that we should all be combing our 4xx responses for "triggering" words like "blacklist" and "blocklist"? And how are we to keep up to date with the heuristics of multiple senders?
*In a very non-confrontational way* I want to express my opinion and to note that's pretty much how senders operate right now: too often the smtp code and enhanced code the recipient system returns have nothing to do with what the response text says - and every mailbox provider uses their own flavor to boot. It's a bit of a nightmare, really. Not exactly for the reasons this thread was started, but still I find it sometimes too complex when classifying data in the aggregated reports. To illustrate how some responses may be providing extra info without it being very useful: Example 1: *(Alex's hypothetical)* 450 4.3.2 Local problem - couldn't query foobar blacklist I do think this very hypothetical example is a bit of an outlier. It's providing non-actionable information to the sending system: it should read this and ... erm... reach out to you and tell you you may have your blacklist API malfunctioning? As as sender I would be very satisfied with *"450 4.3.2 Local problem - retry later"* - this way you'd tell me the deferral is not exactly my fault, it's you and I'm not expected to figure out the issue on my own. And yes, if it persists - I'd be reaching out to ask about it, so if there is anything I can do - I would want it in the response. Example 2: *(if this is indeed how the message went):* 450 4.3.2 Please retry immediately. If your message was rejected by a blacklist, see XXXX for more information. Now this just adds needless ambiguity: was it rejected because of the blacklist or not? Am I on a blacklist? Which one? Should I actually retry? And if I retry and see the same thing - does THAT mean I'm blacklisted? Wishful thinking, sure, but would be great to know if a retry is expected immediately, in a minute, in 20 minutes, in 4 hours or tomorrow - in both examples the code and enhanced code are saying something is temporary but the response doesn't actually provide any insight at all as to HOW temporary a thing is. That's where the sender hubs/postmaster pages would come in help - like Yahoo does with their TSS/IPTS errors, but those are also not very popular and not everyone does them well either. *(kudos to Michael, that page is actually very good)* *On a more confrontational tone *(sorry, still not trying to restart a fight, expressing a possibly controversial opinion)*:* *"The main practical reason for blacklisting is lack of resources."* (quote from Michael's page). Frankly I feel what Luke is doing (and maybe other ESPs?) is basically the same. Both sides here are deciding taking back this planet will cost too much resources so I declare exterminatus onto an entire imperial world .. deciding that something would take too much resources and is not worth it. Sure, one may argue it's not up to ESP to decide that an email is not worth it - but the mailbox provider is not in a better moral position because it's not the end user who makes the decision - MBP made the decision for them. The ESP decided not to retry which was not in user's best interests, the receiving MTA decided not to accept on first try - which was also not in user's best interests. I don't see either a winner here, nor anyone being right really - except the user who is being royally screwed by everyone. --
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
