That’s why, in ESP parlance, there are two sorts of bounces, to keep it simple:
- Hardbounces: The recipient address does not work. Contact through other means. - Softbounces: This email did not arrive. Try again later or contact through other means. If this keeps happening the address effectively does not work. What else is there to do? The sender might be curious to what the reason is (if the bounce is even telling you that) but it does not change the outcome or the call to action. The only things that are actionable for a sender, in a message, is when the content gets unacceptable (spam, too big). We have about 30 categories to explain what type of error occurred (available on request). Met vriendelijke groet, David Hofstee Deliverability Management MailPlus B.V. Netherlands (ESP) Van: mailop [mailto:mailop-boun...@mailop.org] Namens Brandon Long Verzonden: donderdag 10 december 2015 22:23 Aan: Dave Warren CC: mailop Onderwerp: Re: [mailop] Delivery to gmail via IPv6 I was just discussing this issue with our support folks, and we're looking at improving ours for this reason. We also see a remarkable number of our NDRs marked as spam, especially by those whose primary language isn't English. We'll definitely still include the technical information, but it'll be further down. And we'll do our best with handling the remote server's error messages, but ugh. It's too bad that the extended status codes are still so generic... though, as our tech writer and ux folks pointed out, really, all the user cares about is "did I do something wrong? Is there something else I can do?" Brandon On Thu, Dec 10, 2015 at 12:18 PM, Dave Warren <da...@hireahit.com<mailto:da...@hireahit.com>> wrote: And unfortunately the friendlier they are, the less useful they usually are. The ugly ones are the only ones that are useful, but for whatever reason, it's beyond MTA developers to start with friendly messages with a "Troubleshooting information below" that contains a useful transcript. As a techie, I appreciate the info, but the reality is that unless you expect the sender to take some action, transient error messages aren't usually useful. We've scaled back the transient failures that we send, at most you get a single transient and single permanent error, and even still, I question the value of the transient error since the user can't actually do anything (and nor does forwarding it to support@ help). Of course, we also allow users to view the SMTP queue for all messages involving their account for those who care, so that might skew my viewpoint. I'm not a fan of the current trend of using permanent error codes in SMTP for what might well be transient errors (DNS problems, for example), but at the same time, as a sender, I don't see any value in retrying more than 24 hours. It's tough to balance user expectations though. -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren On 2015-12-10 10:43, Franck Martin wrote: It also has to do with people not understanding DSN. Seriously they are ugly and hard to find the relevant information in them... _______________________________________________ mailop mailing list mailop@mailop.org<mailto:mailop@mailop.org> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
