----- Original Message ----- > From: "Stephen J. Turnbull" <[email protected]> > To: "Franck Martin" <[email protected]> > Cc: [email protected] > Sent: Thursday, March 26, 2015 10:28:18 PM > Subject: Re: [dmarc-ietf] Next steps for RFC 7489 (DMARC) > > Franck Martin writes: > > > 2) Mailing lists should be able to differentiate between an Hard > > bounce and a Soft bounce (by now). > > > http://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml > > is 7 years old now. > > They can, but the problem that caused collateral damage to subscribers > is hard bounces, and "p=reject" is a hard bounce. Perhaps you mean > discriminating between "technical hard bounces" and "policy hard > bounces", but even there (a) I don't understand why you think there's > a difference in the way the ML should treat them, and (b) many > receiving sites deliberately conceal policy bounces, and especially > the reason for them.
There is: Temporary Failure: SMTP Status code 4xx (mainly): try again in a few minutes or on a different MX/IP Permanent Failure: SMTP Status code 5xx (mainly): don't try again, get the user to fix it and: Hard Bounce: "no such mailbox/user/email address here" (SMTP enhanced status code, like 5.1.1), usually a permanent failure Soft Bounce: "there may be a valid mailbox/user/email address here, but we are not accepting this email" (SMTP enhanced status code like 5.7.1), a permanent or temporary failure Before the SMTP enhanced error codes existed, you had to parse the text portion of the error message and tried to figure out what it meant. You still kind of do it today. http://help.campaignmonitor.com/topic.aspx?t=26#soft-vs-hard https://sendgrid.com/blog/email-bounce-management/ http://www.boogietools.com/Products/Linux/BounceStudioAPI/Email-Bounce-Boogie-Bounce-API-Categories.asp I admit, it is a bit of rocket science here, and if you can't deliver email reliably after several repeated soft bounces, then you should mark the email address as bounced and get the user to re-confirm it. Your mileage may vary. Also there is the notion of bouncing vs rejecting which I prefer to call asynchronous bounce vs synchronous bounce, because even when you reject, an email (bounce) is usually created to be placed in the mailbox of the sender to inform him/her the email was not sent. as for DMARC: http://tools.ietf.org/html/rfc7489#section-10.3 and AFAIK, the text portion of the current implementations I know of gives a hint, it is because of DMARC. I know mailman 3.0 has a better bounce management system, and I think it will be a separate library, which would be awesome, because it can be included in other open source projects. So when the mailing list recognize the bounce is due to DMARC, then it could either ignore the bounce, or mark that against the original sender rather than the receiver. No more collateral damage. _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
