Re: [mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6
Unfortunately this is not maintained (at least the technical references on the website are not). And there is no time indication to see how old the product really is (it looks like it is from 2010). And there are quite a few things missing that indicate that the bounce engine is too simple. David Van: mailop [mailto:mailop-boun...@mailop.org] Namens Franck Martin Verzonden: vrijdag 18 december 2015 23:58 Aan: Karen Balle CC: Brandon Long; mailop; Ian Eiloart Onderwerp: Re: [mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6 http://www.boogietools.com/ The above does some good job in classifying emails See how they convert bounces into classes: http://www.boogietools.com/Products/Windows/BoogieBounceAPI/Email-Bounce-Boogie-Bounce-API-Categories.asp?sReturnURL=/Products/Windows/BoogieBounceAPI/Default.asp On Fri, Dec 18, 2015 at 2:02 PM, Karen Balle mailto:kba...@rcn.com>> wrote: As Brandon points out, it's not that simple. Some nice examples from one customer's bounce logs today - "552 Transaction @http://domain.net>> failed, remote said "550 No such user" (#5.1.1)" Obviously, we don't want to resend to this address again, but... is it a 552 (mailbox exceeded allocation), a 550 (mailbox unavailable doesn't necessary mean no such user) or a 5.1.1 (bad destination address). A 552 shouldn't match with a x.1.1. They're two different bounce reasons that are mutually exclusive, but we see stuff like this all the time. If it's a 552, then we could retry this address again later because the mailbox is full. Most likely it's a 5.1.1 and the address is completely invalid so we suppress it. Then there are the "554 Invalid mailbox: @.com" and the "554 rejecting banned content" bounces. 554 is a valid response for an invalid mailbox although 550 and 553 are more common there. Going strictly by 554, you would think retrying would be fine because it's transaction-specific, but not suppressing the first will get you blocked whereas the second should be retried once you've resolved the root cause. "550 mailbox unavailable" sometimes means the address is invalid and other times means you aren't allowed to access the mailbox due to technical or reputation issues. The mailbox is either completely unavailable or the mailbox is only unavailable to you or the mailbox can't be internally accessed. Or the "550 5.7.1 mailto:u...@domain3.com>>... Relaying denied" which may mean that the mail is being forwarded and the forward is failing or that you are not allowed to access this mailbox at this time except for when it means that the address is invalid. Is "550 5.1.1 unknown or illegal alias" an invalid address or is it a directory failure? (This ISP passes a 4.4.3 for directory failures, but many others don't or can't because of system architecture limitations.) On Fri, Dec 18, 2015 at 11:40 AM, Brandon Long mailto:bl...@google.com>> wrote: 4xx vs 5xx is only part of the story. We're talking about whether the next message will succeed. Sure, a 4xx response probably mostly means go ahead and try the next message, but a 5xx doesn't mean that no messages will be accepted for this account, just this one wasn't accepted. And agreed, some of the extended status codes can be interpreted in this way fairly easily, but others... Brandon On Dec 18, 2015 7:35 AM, "Ian Eiloart" mailto:i...@sussex.ac.uk>> wrote: > On 18 Dec 2015, at 01:55, Karen Balle mailto:kba...@rcn.com>> > wrote: > > Brandon, > > I really like this idea, even as a mental exercise. There would be a lot of > usefulness in being able to clearly dictate from the enhanced codes when our > MTAs should stop, back off, or go into an extended timeout. Well, that should be pretty clear from the 4xx vs 5xx status. If it’s 4xx, you should queue the message for later delivery, otherwise generate a bounce. I guess if the recipient wants to indicate that you should reduce your sending rate, that’s something that needs a new status, but you could use "4.3.1 Mail system full", or "X.4.5 Mail system congestion" because the sensible response would be to back off. > Perhaps something like having the enhanced code be tied to the primary > reason for an organization not accepting email would be useful? I can't see > where we could (or should) come up with a system where every reason an email > isn't being accepted is communicated in a single NDR. Filters are getting > horribly complicated and there are often multiple reasons why a sender's mail > isn't being accepted. > From an ESP perspective, being able to tell a customer that Gmail clearly > said in a bounce 1) It's you, not them. There are plenty of c
Re: [mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6
http://www.boogietools.com/ The above does some good job in classifying emails See how they convert bounces into classes: http://www.boogietools.com/Products/Windows/BoogieBounceAPI/Email-Bounce-Boogie-Bounce-API-Categories.asp?sReturnURL=/Products/Windows/BoogieBounceAPI/Default.asp On Fri, Dec 18, 2015 at 2:02 PM, Karen Balle wrote: > As Brandon points out, it's not that simple. > Some nice examples from one customer's bounce logs today - > "552 Transaction @ failed, remote said "550 No such > user" (#5.1.1)" Obviously, we don't want to resend to this address again, > but... is it a 552 (mailbox exceeded allocation), a 550 (mailbox > unavailable doesn't necessary mean no such user) or a 5.1.1 (bad > destination address). A 552 shouldn't match with a x.1.1. They're two > different bounce reasons that are mutually exclusive, but we see stuff like > this all the time. If it's a 552, then we could retry this address again > later because the mailbox is full. Most likely it's a 5.1.1 and the > address is completely invalid so we suppress it. > > Then there are the "554 Invalid mailbox: @.com" and the "554 > rejecting banned content" bounces. 554 is a valid response for an invalid > mailbox although 550 and 553 are more common there. Going strictly by 554, > you would think retrying would be fine because it's transaction-specific, > but not suppressing the first will get you blocked whereas the second > should be retried once you've resolved the root cause. "550 mailbox > unavailable" sometimes means the address is invalid and other times means > you aren't allowed to access the mailbox due to technical or reputation > issues. The mailbox is either completely unavailable or the mailbox is > only unavailable to you or the mailbox can't be internally accessed. Or the > "550 5.7.1 ... Relaying denied" which may mean that the > mail is being forwarded and the forward is failing or that you are not > allowed to access this mailbox at this time except for when it means that > the address is invalid. Is "550 5.1.1 unknown or illegal alias" an invalid > address or is it a directory failure? (This ISP passes a 4.4.3 for > directory failures, but many others don't or can't because of system > architecture limitations.) > > > On Fri, Dec 18, 2015 at 11:40 AM, Brandon Long wrote: > >> 4xx vs 5xx is only part of the story. We're talking about whether the >> next message will succeed. >> >> Sure, a 4xx response probably mostly means go ahead and try the next >> message, but a 5xx doesn't mean that no messages will be accepted for this >> account, just this one wasn't accepted. >> >> And agreed, some of the extended status codes can be interpreted in this >> way fairly easily, but others... >> >> Brandon >> On Dec 18, 2015 7:35 AM, "Ian Eiloart" wrote: >> >>> >>> > On 18 Dec 2015, at 01:55, Karen Balle wrote: >>> > >>> > Brandon, >>> > >>> > I really like this idea, even as a mental exercise. There would be a >>> lot of usefulness in being able to clearly dictate from the enhanced codes >>> when our MTAs should stop, back off, or go into an extended timeout. >>> >>> Well, that should be pretty clear from the 4xx vs 5xx status. If it’s >>> 4xx, you should queue the message for later delivery, otherwise generate a >>> bounce. I guess if the recipient wants to indicate that you should reduce >>> your sending rate, that’s something that needs a new status, but you could >>> use "4.3.1 Mail system full", or "X.4.5 Mail system congestion" because >>> the sensible response would be to back off. >>> >>> >>> >>> > Perhaps something like having the enhanced code be tied to the >>> primary reason for an organization not accepting email would be useful? I >>> can't see where we could (or should) come up with a system where every >>> reason an email isn't being accepted is communicated in a single NDR. >>> Filters are getting horribly complicated and there are often multiple >>> reasons why a sender's mail isn't being accepted. >>> >>> >>> > From an ESP perspective, being able to tell a customer that Gmail >>> clearly said in a bounce 1) It's you, not them. >>> >>> There are plenty of codes that say this. All of these are errors that >>> could be fixed by the sender (not their MTA) >>> >>> X.1.1 Bad destination mailbox address >>> X.1.2 Bad destination system address >>> X.1.3 Bad destination mailbox address syntax >>> X.1.6 Destination mailbox has moved, No forwarding address >>> X.1.7 Bad sender's mailbox address syntax >>> X.1.8 Bad sender's system address >>> X.2.3 Message length exceeds administrative limit [per mailbox] >>> X.3.4 Message too big for system >>> X.5.3 Too many recipients >>> >>> > 2) Your content/domain rep/IP rep is horrible. >>> >>> X.7.1 Delivery not authorized, message refused >>> The sender is not authorized to send to the destination. >>> >>> But, there’s plenty of scope for extension here: with three digits >>> available for . Perhaps it’s time to loo
Re: [mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6
On Fri, Dec 18, 2015 at 10:35 AM, Ian Eiloart wrote: > > Well, that should be pretty clear from the 4xx vs 5xx status. If it’s 4xx, > you should queue the message for later delivery, otherwise generate a > bounce. I guess if the recipient wants to indicate that you should reduce > your sending rate, that’s something that needs a new status, but you could > use "4.3.1 Mail system full", or "X.4.5 Mail system congestion" because > the sensible response would be to back off. There’s a registry, and a review might be a good idea. > > https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml#smtp-enhanced-status-codes-2 > > ___ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
Re: [mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6
As Brandon points out, it's not that simple. Some nice examples from one customer's bounce logs today - "552 Transaction @ failed, remote said "550 No such user" (#5.1.1)" Obviously, we don't want to resend to this address again, but... is it a 552 (mailbox exceeded allocation), a 550 (mailbox unavailable doesn't necessary mean no such user) or a 5.1.1 (bad destination address). A 552 shouldn't match with a x.1.1. They're two different bounce reasons that are mutually exclusive, but we see stuff like this all the time. If it's a 552, then we could retry this address again later because the mailbox is full. Most likely it's a 5.1.1 and the address is completely invalid so we suppress it. Then there are the "554 Invalid mailbox: @.com" and the "554 rejecting banned content" bounces. 554 is a valid response for an invalid mailbox although 550 and 553 are more common there. Going strictly by 554, you would think retrying would be fine because it's transaction-specific, but not suppressing the first will get you blocked whereas the second should be retried once you've resolved the root cause. "550 mailbox unavailable" sometimes means the address is invalid and other times means you aren't allowed to access the mailbox due to technical or reputation issues. The mailbox is either completely unavailable or the mailbox is only unavailable to you or the mailbox can't be internally accessed. Or the "550 5.7.1 ... Relaying denied" which may mean that the mail is being forwarded and the forward is failing or that you are not allowed to access this mailbox at this time except for when it means that the address is invalid. Is "550 5.1.1 unknown or illegal alias" an invalid address or is it a directory failure? (This ISP passes a 4.4.3 for directory failures, but many others don't or can't because of system architecture limitations.) On Fri, Dec 18, 2015 at 11:40 AM, Brandon Long wrote: > 4xx vs 5xx is only part of the story. We're talking about whether the > next message will succeed. > > Sure, a 4xx response probably mostly means go ahead and try the next > message, but a 5xx doesn't mean that no messages will be accepted for this > account, just this one wasn't accepted. > > And agreed, some of the extended status codes can be interpreted in this > way fairly easily, but others... > > Brandon > On Dec 18, 2015 7:35 AM, "Ian Eiloart" wrote: > >> >> > On 18 Dec 2015, at 01:55, Karen Balle wrote: >> > >> > Brandon, >> > >> > I really like this idea, even as a mental exercise. There would be a >> lot of usefulness in being able to clearly dictate from the enhanced codes >> when our MTAs should stop, back off, or go into an extended timeout. >> >> Well, that should be pretty clear from the 4xx vs 5xx status. If it’s >> 4xx, you should queue the message for later delivery, otherwise generate a >> bounce. I guess if the recipient wants to indicate that you should reduce >> your sending rate, that’s something that needs a new status, but you could >> use "4.3.1 Mail system full", or "X.4.5 Mail system congestion" because >> the sensible response would be to back off. >> >> >> >> > Perhaps something like having the enhanced code be tied to the primary >> reason for an organization not accepting email would be useful? I can't >> see where we could (or should) come up with a system where every reason an >> email isn't being accepted is communicated in a single NDR. Filters are >> getting horribly complicated and there are often multiple reasons why a >> sender's mail isn't being accepted. >> >> >> > From an ESP perspective, being able to tell a customer that Gmail >> clearly said in a bounce 1) It's you, not them. >> >> There are plenty of codes that say this. All of these are errors that >> could be fixed by the sender (not their MTA) >> >> X.1.1 Bad destination mailbox address >> X.1.2 Bad destination system address >> X.1.3 Bad destination mailbox address syntax >> X.1.6 Destination mailbox has moved, No forwarding address >> X.1.7 Bad sender's mailbox address syntax >> X.1.8 Bad sender's system address >> X.2.3 Message length exceeds administrative limit [per mailbox] >> X.3.4 Message too big for system >> X.5.3 Too many recipients >> >> > 2) Your content/domain rep/IP rep is horrible. >> >> X.7.1 Delivery not authorized, message refused >> The sender is not authorized to send to the destination. >> >> But, there’s plenty of scope for extension here: with three digits >> available for . Perhaps it’s time to look at extending the set of enhanced >> error codes available. A 20th anniversary celebration! >> RFC 1893 Mail System Status Codes January 1996 >> RFC 3463 Enhanced Mail System Status Codes January 2003 >> >> > 3) and you should feel bad >> >> X.7.10 Go directly to Jail, do not pass GO! ;^) >> >> >> There’s a registry, and a review might be a good idea. >> >> https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml#smtp-en
Re: [mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6
> On 18 Dec 2015, at 01:55, Karen Balle wrote: > > Brandon, > > I really like this idea, even as a mental exercise. There would be a lot of > usefulness in being able to clearly dictate from the enhanced codes when our > MTAs should stop, back off, or go into an extended timeout. Well, that should be pretty clear from the 4xx vs 5xx status. If it’s 4xx, you should queue the message for later delivery, otherwise generate a bounce. I guess if the recipient wants to indicate that you should reduce your sending rate, that’s something that needs a new status, but you could use "4.3.1 Mail system full", or "X.4.5 Mail system congestion" because the sensible response would be to back off. > Perhaps something like having the enhanced code be tied to the primary > reason for an organization not accepting email would be useful? I can't see > where we could (or should) come up with a system where every reason an email > isn't being accepted is communicated in a single NDR. Filters are getting > horribly complicated and there are often multiple reasons why a sender's mail > isn't being accepted. > From an ESP perspective, being able to tell a customer that Gmail clearly > said in a bounce 1) It's you, not them. There are plenty of codes that say this. All of these are errors that could be fixed by the sender (not their MTA) X.1.1 Bad destination mailbox address X.1.2 Bad destination system address X.1.3 Bad destination mailbox address syntax X.1.6 Destination mailbox has moved, No forwarding address X.1.7 Bad sender's mailbox address syntax X.1.8 Bad sender's system address X.2.3 Message length exceeds administrative limit [per mailbox] X.3.4 Message too big for system X.5.3 Too many recipients > 2) Your content/domain rep/IP rep is horrible. X.7.1 Delivery not authorized, message refused The sender is not authorized to send to the destination. But, there’s plenty of scope for extension here: with three digits available for . Perhaps it’s time to look at extending the set of enhanced error codes available. A 20th anniversary celebration! RFC 1893 Mail System Status Codes January 1996 RFC 3463 Enhanced Mail System Status Codes January 2003 > 3) and you should feel bad X.7.10 Go directly to Jail, do not pass GO! ;^) There’s a registry, and a review might be a good idea. https://www.iana.org/assignments/smtp-enhanced-status-codes/smtp-enhanced-status-codes.xhtml#smtp-enhanced-status-codes-2 > would cut through a lot of the pushback we get now. > I could see a lot of use for anyone with a shared IP infrastructure, as well. > If most of the DSNs from shared IP space came back with an enhanced code > pointing to IP reputation but a handful of customers have more specific > content or sender-related codes, it gives us amazing insight into the > troublemakers trying to hide on the shared IPs. How much benefit do you > think most mailbox providers would get if ESPs were able to more reliably > adapt around having that extra certainty in our decision-making process? > > Couple of ideas for it > Mailbox specific - invalid account, recently closed account, mailbox full, > recipient-configured rejection rules > ISP specific - server/network saturation (which we should treat with a full > stop on traffic from all our senders rather than an extended retry for a > single sender with traffic shaping relating to reputation), LDAP failure, > server farm under attack by backhoe or glowing molerats > IP specific - traffic shaping for excessive volume for current reputation > (very handy for the holidays and ramp ups), blocked for complaints, blocked > for excessive invalid users/spamtraps, blocked for phishing/malware, traffic > spread across too many IPs, snowshoe, your provider sucks, get off my lawn > Sender specific - could be broken down for domain, subdomain, or localpart > combinations if we're feeling really ambitious but that could be providing > too much feedback that could be abused. Marketing vs transactional is often > split this way, though. Helpful for customers using their mailbox provider's > domain. Would allow ESPs to set rules to stop mailing for specific senders > immediately and definitely ties in with compliance standards. > Authentication and configuration failures - DMARC, no rDNS, missing A or MX > records (I had a fight with a customer this week about setting those up) > Content specific - Again, could be easily abused but there are some ways it > could be helpful. Redirector who doesn't handle their spam, linking to > commonly phished sites, bad landing page rep (possibly malicious), Normally > good sender who included third party content on a send. > > Karen > > On Wed, Dec 16, 2015 at 11:35 PM, Brandon Long wrote: > We have automated systems, especially for Google groups, which are basically > doing the same thing, and it's a pain. > > I agree that the SMTP status code is mostly useless
Re: [mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6
Brandon, I really like this idea, even as a mental exercise. There would be a lot of usefulness in being able to clearly dictate from the enhanced codes when our MTAs should stop, back off, or go into an extended timeout. Perhaps something like having the enhanced code be tied to the primary reason for an organization not accepting email would be useful? I can't see where we could (or should) come up with a system where every reason an email isn't being accepted is communicated in a single NDR. Filters are getting horribly complicated and there are often multiple reasons why a sender's mail isn't being accepted. >From an ESP perspective, being able to tell a customer that Gmail clearly said in a bounce 1) It's you, not them. 2) Your content/domain rep/IP rep is horrible. 3) and you should feel bad would cut through a lot of the pushback we get now. I could see a lot of use for anyone with a shared IP infrastructure, as well. If most of the DSNs from shared IP space came back with an enhanced code pointing to IP reputation but a handful of customers have more specific content or sender-related codes, it gives us amazing insight into the troublemakers trying to hide on the shared IPs. How much benefit do you think most mailbox providers would get if ESPs were able to more reliably adapt around having that extra certainty in our decision-making process? Couple of ideas for it Mailbox specific - invalid account, recently closed account, mailbox full, recipient-configured rejection rules ISP specific - server/network saturation (which we should treat with a full stop on traffic from all our senders rather than an extended retry for a single sender with traffic shaping relating to reputation), LDAP failure, server farm under attack by backhoe or glowing molerats IP specific - traffic shaping for excessive volume for current reputation (very handy for the holidays and ramp ups), blocked for complaints, blocked for excessive invalid users/spamtraps, blocked for phishing/malware, traffic spread across too many IPs, snowshoe, your provider sucks, get off my lawn Sender specific - could be broken down for domain, subdomain, or localpart combinations if we're feeling really ambitious but that could be providing too much feedback that could be abused. Marketing vs transactional is often split this way, though. Helpful for customers using their mailbox provider's domain. Would allow ESPs to set rules to stop mailing for specific senders immediately and definitely ties in with compliance standards. Authentication and configuration failures - DMARC, no rDNS, missing A or MX records (I had a fight with a customer this week about setting those up) Content specific - Again, could be easily abused but there are some ways it could be helpful. Redirector who doesn't handle their spam, linking to commonly phished sites, bad landing page rep (possibly malicious), Normally good sender who included third party content on a send. Karen On Wed, Dec 16, 2015 at 11:35 PM, Brandon Long wrote: > We have automated systems, especially for Google groups, which are > basically doing the same thing, and it's a pain. > > I agree that the SMTP status code is mostly useless from this prospective, > and the extended ones aren't much better. > > It might be nice if there was a concept of whether a failure is message > specific, sender specific, etc... But anything like that would be gamed > both for antispam and for spammers. > > Still, may be worth a thought experiment, a replacement for the extended > status codes or even a bcp about how they should be used. > On Dec 16, 2015 6:03 PM, "Karen Balle" wrote: > >> Since there's been a lot of drift on this topic and I'm not talking about >> IPv6, DNSSEC, or delivery to Gmail >> >> For NDRs and DSNs to be truly useful to an ESP, we tend to break them >> down into more buckets than two. >> >> Hard bounce/invalid (do not retry, generally a 5xx) >> Soft bounce (temporary and related to a specific email address, generally >> a 4xx, try again later during the current send, Yahoo uses 4xx where we >> would expect a 5xx such as with some of the traffic shaping deferrals) >> Technical (DNS failures and the like, try again later, generally 5xx but >> depends on the reason) >> Spam or block (stop for this send, try this recipient on future sends, >> mix of 5xx and 4xx) >> Unknown (parser doesn't have an appropriate string, manual review and >> update of systems required) >> >> The primary challenge from a technical perspective is making sure that >> any changes in friendly language in an NDR or DSN is updated on the bounce >> parser. We do tend to MOSTLY ignore 5xx and 4xx, but that is more a >> function of how those are used by mailbox providers. The desired end >> result is that we send all email in a manner that is acceptable to each >> mailbox provider based on their (technical and personal) feedback and >> desired rate limits. Extended codes are useful, when you know how a >> prov
Re: [mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6
Although the reply messages are gamed, as we see too, we do not let the outcome be any different. It is up to the mailserver operator to decide how we are to view bounces. That is their responsibility and not ours. In the end I want to make it possible to explain my actions to everyone involved. Our internal buckets are below. Anything we found could be pressed into these categories, types and subtypes. Yours, David Category of bounce outOfOffice/autoresponder We received an out-of-office email. Default = ignore this email. These mails will be parsed further for definitive indicators of inactive mailboxes. Technical bounce/delayed We received a message that stated that this email was in transit (and not yet delivered). Default = ignore this email. Technical bounce (but no delay indicator, therefore treated as NDR) We received a technical email back from a mailserver. Default = softbounce this email. These mails will be parsed further. See below. Spam, default = softbounce this email. spam blacklisted Some part of the email or the sender was identified as blacklisted. spam content-related The content was identified as spam. spam sender-denied The sender, you or us, was denied for non-specific reasons. spam spf-failure The email was not allowed to be forwarded due to anti-spam configuration issues. spam unknown It was identified as spam for unknown reasons. personalBlacklist personal-blacklist The recipient has a specific blocklist against you. Hardbounce this email. Hardbounce hardBounce domain-unknown The domain is not valid. hardBounce mailbox-disabled The mailbox is there, but no longer in use. hardBounce mailbox-unknown The mailbox is not known to the mailserver. hardBounce unknown The mailbox is not working anymore for non-specific reasons. Softbounce Softbounce access issues softBouncerelay-denied softBounceaccess-denied This often means a configuration error on the domain or the mailserver. It does not accept email for that domain (without authentication). softBouncesender-denied The recipient has not granted you access to email him/her. Softbounce mailbox issues: softBouncemailbox-temp-disabled The mailbox is (temporarily) disabled. softBouncemailbox-temp-error There is an error for this mailbox which could be temporary. softBouncemailbox-full The mailbox is full, which could be temporary. Softbounce message errors: softBouncemessage-error There was something wrong with the message itself softBouncemessage-expired The message could not be delivered within a reasonable time frame. softBouncemessage-size The size of the message was too large. Softbounce networking related softBounceconnection-error There was something wrong while connecting to the mailserver. softBouncerouting-error softBouncerouting-loop The email was sent but returned because it could not be delivered to the inbox (of another domain). Softbounce mailserver related softBounceconfig-error softBouncesystem-error softBounceservice-unavailable Some technical error occurred while sending the mail to that mailserver and that is why it could not accept the message. softBounceunknown Some other error occurred that could not be determined reliably. It could be temporary. Van: mailop [mailto:mailop-boun...@mailop.org] Namens Brandon Long Verzonden: donderdag 17 december 2015 05:35 Aan: Karen Balle CC: mailop; Ian Eiloart Onderwerp: Re: [mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6 We have automated systems, especially for Google groups, which are basically doing the same thing, and it's a pain. I agree that the SMTP status code is mostly useless from this prospective, and the extended ones aren't much better. It might be nice if there was a concept of whether a failure is message specific, sender specific, etc... But anything like that would be gamed both for antispam and for spammers. Still, may be worth a thought experiment, a replacement for the extended status codes or even a bcp about how they
[mailop] NDRs and DSNs was: Re: Delivery to gmail via IPv6
Since there's been a lot of drift on this topic and I'm not talking about IPv6, DNSSEC, or delivery to Gmail For NDRs and DSNs to be truly useful to an ESP, we tend to break them down into more buckets than two. Hard bounce/invalid (do not retry, generally a 5xx) Soft bounce (temporary and related to a specific email address, generally a 4xx, try again later during the current send, Yahoo uses 4xx where we would expect a 5xx such as with some of the traffic shaping deferrals) Technical (DNS failures and the like, try again later, generally 5xx but depends on the reason) Spam or block (stop for this send, try this recipient on future sends, mix of 5xx and 4xx) Unknown (parser doesn't have an appropriate string, manual review and update of systems required) The primary challenge from a technical perspective is making sure that any changes in friendly language in an NDR or DSN is updated on the bounce parser. We do tend to MOSTLY ignore 5xx and 4xx, but that is more a function of how those are used by mailbox providers. The desired end result is that we send all email in a manner that is acceptable to each mailbox provider based on their (technical and personal) feedback and desired rate limits. Extended codes are useful, when you know how a provider applies them, but again, there is such variation in the how codes are applied and when that it's all but impossible for someone not steeped in the intricacies of RFCs to interpret them properly. Not all customers have access to people who spend a lot of time going over bounces and making them actionable. A lot of our job as an ESP is taking the technical and making it understandable to someone who doesn't have the training and background on RFCs and "proper" technical jargon. I've spent the last 18 years or so going over NDRs and DSNs and some still throw me. Filters are also increasingly more complex and we see the same bounce used for multiple purposes, so cross-referencing which bounces happen where is becoming more important to understanding the root issue for a customer. Cheers, Karen On Fri, Dec 11, 2015 at 9:06 AM, Ian Eiloart wrote: > 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 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 > wrote: > > And unfortunately the friendlier they are, the less useful they usually > are. > > > > The ugly ones ar
