There are three ways that an email can fail to be delivered:
- immediate rejection
- timeout
- asynchronous bounce
Rejection
A rejection is any delivery attempt where the sending smarthost can tell immediately that the mail can’t be delivered.
That will often be when the receiving machine accepts a connection but returns a “hard bounce” or “5xx” error at some point in the transaction, but can also be caused by the email address being malformed, the recipients domain not existing or the domain’s DNS being configured (accidentally or intentionally) to deny any email.
Traditionally this rejection will be recorded by the smarthost generating an asynchronous bounce email locally and sending that back to the local user who sent the message – that’s usually where the bounce message you see when you typo a recipient comes from. That’s an inefficient way of handling rejections at volume, though, so smarthost designed for high-volume email will typically report rejections some other way rather than creating asynchronous bounce.
Timeout
If something fails during an attempt to deliver a message, but the sending smarthost either can tell that it’s just a temporary problem, or it can’t tell for sure that it’s a permanent problem then the smarthost will keep a copy of that outbound message in it’s spool and schedule an attempt to resend it later.
One common cause of this is a “soft bounce” or “4xx” error at some point in the transaction, but broken DNS records, overloaded or unavailable servers, network problems or firewall level filtering can also cause delivery to fail in a potentially “temporary” way.
Some of these “temporary” problems aren’t really temporary, and the scheduled attempts to resend the mail will also fail. Eventually the smarthost will have give up on the delivery attempt and report a failure. That can take a long time – while the smarthost owner can configure how long it should keep trying it will often default to a week or so. Once the smarthost gives up it will report the failure, often by generating an asynchronous bounce email locally.
Asynchronous bounce
If the receiving mailserver accepts the message it is accepting responsibility for delivering it to the final recipient. If it finds out afterwards that it can’t deliver the message it sends a notification to the sender of the message, typically with more information about why delivery failed and a partial or complete copy of the message.
Like this:
Hi. This is the qmail-send program at yahoo.com.
I’m afraid I wasn’t able to deliver your message to the following addresses.
This is a permanent error; I’ve given up. Sorry it didn’t work out.
<cacakande@gmail.comx>:
74.125.142.27 failed after I sent the message.
Remote host said: 550-5.7.1 [98.138.207.123 Â Â Â Â Â 12] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked. Please visit
550-5.7.1Â http://support.google.com/mail/bin/answer.py?hl=en&answer=188131Â for
550 5.7.1 more information. g2si7192949igq.45 – gsmtp
— Below this line is a copy of the message.
Or this:
Delivery to the following recipient failed permanently:
nev.w.goodman@gone.bristol.ac.ukx
Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the server for the recipient domain gone.bristol.ac.uk byaspmx.l.google.com. [173.194.67.27].
The error that the other server returned was:
550-5.1.1 The email account that you tried to reach does not exist. Please try
550-5.1.1 double-checking the recipient’s email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1Â http://support.google.com/mail/bin/answer.py?answer=6596Â k3si5496468wjb.158 – gsmtp
—– Original message —–
That’s an asynchronous bounce – “asynchronous” because it’s not synchronized with the delivery of the original message; it may come at any time after the delivery appeared to succeed, even weeks later.
There are quite a few operational problems with asynchronous bounces. One of the bigger ones is what’s known as backscatter. The mailserver generating the asynchronous bounce will send it to the email address in the bouncing email’s “envelope from” / “bounce address” – and when the mail being bounced is spam that email address is usually fake or an innocent third party. Several hundred backscatter bounces showed up in my inbox this morning, so it’s a bit of a sore point right now.
Because of the backscatter issue it’s considered a best practice to do as much filtering and other delivery decision making as possible while you have the sending mailserver still connected, so that you can safely reject the mail. Only as a last resort when you find out later that the message can’t be delivered should you send an asynchronous bounce.
Some people go further and suggest that any competently run mailserver should never send asynchronous bounces, and that there is never any operational need for them. I think they’re wrong, and judging from the bounces in my inbox, so do Google, Yahoo, Microsoft, Telstra, Eircom, Orange, OCN, t-online.de, Interhost.it, xs4all.nl and many, many other ISPs, companies and universities across the world…
RSS - Posts
THANK YOU! I get so tired of un-professional RBLs that insist that even ONE asynchronous bounce message is criteria to black list you.
You can’t eliminate all asynchronous bounces, for the simple reasons that email addresses churn, and some of the scripts that pipe to mailx can’t read inbound email.
I agree that there’s architectural things you can do on both the inbound relay and outbound smarthost side to minimize them, but those things are not always high priorities, since “because some nerd on the internet said so” is usually not a great business case.
I did a little write-up in the past of what I called the 3 stages of email feedback. It had a different purpose than this post so only 2 of the 3 things overlapped. Good post. We don’t send asynchronous bounces on our email hosting solutions, but I might reconsider after reading this. Also, we don’t do a very good job processing such bounces on our outbound services. It just hasn’t bubbled up in the priority list.
I think an asychronous bounce can be justified if the mail has been accepted from an authenticated client or from a trusted system.
The real issue most people have with asynchronous bounces is when they are generated by one of the systems in a multi-stage inbound relay where perhaps content filtering, user lookup or other causes of bounces are not performed by the system that handles the mail first. This has led to deprecation of naive secondary MXes and other implementations that blindly accept mail from the wider Internet.