Hi Ian, So ESP parlance, 'a particular manner of speaking', is not RFC parlance. That part is true. We have to explain our customers, who are not techies, what is going on with their mails. We either say that the mail is delivered or bounced (=did not arrive in ESP parlance). And if it bounced, it is either a softbounce or a hardbounce. There is nothing 'soft' about softbounces. It only means that the email address is not 'removed' of his list. That only happens after a series of successive softbounces or 1 hardbounce. Simple, but different.
So anything that has to do with queueing (defer-rals, sometimes generating a delay notification) is basically ignored. My customers do not care about queuing mechanisms. I do care but I monitor that in a different way (and will take action when necessary). Anything that has to do with an email not arriving (a reject or time-out) will create a non-delivery notification/bounce. Those bounces are classified/translated into a hardbounce or a softbounce. E.g. a hardbounce could be 'account does not exist' and a softbounce could be 'account over quota' (and 28 other various reasons). >If the ESP is good, the the sender will have access to a support team, so all >faults should be actionable. Some mails will never arrive and there is nothing we (or our customer) can do about it. It is therefore not actionable. That would be 0.35% of our mails on average. There are larger issues, that are actionable by us, but these are flagged by other means. We either solve that for our customers or inform them of the issue and what they can do. That does not happen very often. This is what they pay for. Hope this clarifies it a little. Yours sincerely, David -----Oorspronkelijk bericht----- Van: Ian Eiloart [mailto:i...@sussex.ac.uk] Verzonden: vrijdag 11 december 2015 15:07 Aan: David Hofstee CC: mailop@mailop.org Onderwerp: Re: [mailop] Delivery to gmail via IPv6 I wonder why they don’t use the terminology from the RFCs: "reject", "defer", "non-delivery notification", "delay notification"? As it is, when you say "Hardbounce", I don’t know whether you’re referring to an SMTP 5yz reply (a rejection) by the receiving MTA or an rfc 3461 "failed" DSN sent to the sender to alert them to the problem. Similarly, I don’t know whether "softbounces" means an rfc5321 temporary failure reply , or an rfc 3461 "delayed" DSN. Neither of which mean quite what you said, since the intention is that the sending MTA will retry for a period. The sending MTA can’t use other means. If the original sender tries again, then the recipient will get duplicate messages when the fault is resolved. If the ESP is good, the the sender will have access to a support team, so all faults should be actionable. > On 11 Dec 2015, at 11:59, David Hofstee <da...@mailplus.nl> wrote: > > 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> 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 > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 _______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
