Also bounce.io , but these are very bad services. They bounce to the reply to, not bounce address: former is likely monitored, latter is likely automated removal. On Dec 11, 2015 10:40 AM, "Franck Martin" <fmar...@linkedin.com> wrote:
> There a whole business, https://betterbounces.net, based on rewriting the > NDR into something any user can read, with a meaningful call to action. > > I love the technical info too, but as Brandon said, it could be later in > the email. > > On Thu, Dec 10, 2015 at 1:23 PM, Brandon Long <bl...@google.com> wrote: > >> 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 >> >> > > _______________________________________________ > 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
