The problem of backscatter, part 3 – Legitimate bounces

When a mail server accepts a message and later decides that it can't deliver the message, it is required to send back a bounce email to the sender of the original message. There are a few kinds of bounce notifications that a mail server can send:

  • Recipient does not exist
  • Recipient's email inbox is full
  • Your mail server is on an IP blocklist and therefore their mail server is rejecting your mail
  • Out of office notifications (not technically an NDR but close enough)

I'm sure that there are more but that's all I can think of at the moment.  Anyhow, for the first one, let's say you send a message and the recipient you are sending to does not exist; the recipient mail server let's you know by sending you a message back indicating as much.

Some recipient mail servers are nice about this and they attach the original message to their email.  For example, the message you get back might look something like this:

Date: Fri, 27 Jun 2008 06:56:00 +0000 (UTC)
From: MAILER-DAEMON (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: Me
Reporting-MTA: dns;
X-Postfix-Queue-ID: CCCDA18680DA
X-Postfix-Sender: rfc822;
Arrival-Date: Fri, 27 Jun 2008 06:55:54 +0000 (UTC)

Final-Recipient: rfc822;
Action: failed
Status: 5.0.0
Diagnostic-Code: X-Postfix; host[] said: 550 5.7.1
Email rejected because recipient does not exist.
(in reply to end of DATA command)

Subject: This is a test

From: Guy Incognito

Date: Thu, 26 Jun 2008 23:55:49 -0700

To: Johnny Fairplay <>

This is a test to see if I get can generate an NDR.

The above part contains the reason the message was bounced back to you and the bottom part is the original message (usually sent as an attachment but sometimes sent inline).  Note the key characteristics of the NDR message:

  • The message that arrives in your inbox is From: something that you wouldn't initially recognize like the MAILER-DAEMON, or Mail Delivery System, or something similar.  Of course, by "you" I mean the average person, not sysadmins or spam fighters.

  • The Subject: line of the message in your inbox contains the notification that your mail could not be delivered (in this Undelivered Mail Returned To Sender)

  • The reason that your message could not be delivered is in the bounce message.

  • Your original message is in the bounce message; usually it is attached but sometimes it is sent inline.

Here's where things get interesting.  There is no set format about how NDRs should be structure.  The From: address says Mail Delivery System, but it could say Mailer System, Recipient Mailer, or some other type of message that doesn't even contain the word mail.

The Subject: line could say Undelivered Mail, Undeliverable Mail, Your Message could not be Delivered, Delivery Status Notification, 550 Status Notice, etc.  The messages are usually in a foreign language if we are Europe.  In other words, this subject line could contain a variety of messages.

The reason for the bounce, like the two cases above, could be phrased in a variety of ways, in a variety of languages.

Finally, the bounce message is usually included, but not always.  It could be sent inline, it could be an attachment, or it could be truncated (ie, a partial message).

The SMTP MAIL FROM is usually a null sender, that is, the SMTP MAIL FROM is <>.  This is legal within the SMTP protocol.  Usually an NDR sends mail as a null sender, but not always; sometimes they are <bounce@...> or <postmaster@...> or something similar.  To make matters worse, others use null senders for non-NDR messages.  This happens often with automated messages that send out reports.  So, you can't count on NDRs to have null senders 100% of the time, and you can't count on null senders to be NDRs 100% of the time.

To sum it up, NDRs from legitimate servers can take on a variety of forms.  Everyone does it differently.

Comments (6)
  1. Lee Maguire says:

    It should be pointed out that there is has been a draft standard for bounce message formats for a few years now – a multipart/report message (<a href="">RFC 3462</a>)

    containing a delivery-status (

    <a href="">RFC 3464</a>) message.

    However many of the codebases for mail exchangers predate this, so it’s clearly not a universally adopted standard at this time.

    Your given example, however, was probably delivered in this standard.

  2. Frank says:

    In one of the next parts I hope you come back to the point about client A sending mails to server B. If B rejects one or more of these mails immediately it is actually A that has to create a non-delivery report for the (alleged) sender, e.g., put it into the mailbox of user@A. Only if B was forced to accept a mail "on probation", later finding out that it can’t deliver it, it is B that has to send an NDR.

    Accepting mail "on probation" is a major part of the backscatter problem (but no issue after an SPF PASS, obviously). The not yet published successor of RFC 2821 uses a clearer terminology wrt "bounce" (= send NDR), never confusing it with "reject" (= SMTP error).

    551 "use address X for user Y" is one of many other SMTP reject reasons, 550 for say SPF FAIL is also known.

  3. As one of the commenters in my previous post mentioned, RFC 3464 specifies the content-type for Delivery

  4.”> http://blogs.msdn

  5. Lee Maguire says:

    "To make matters worse, others use null senders for non-NDR messages."

    Traditionally this has been done to avoid receiving "out of office" automated replies.  If you receive mail other than DSN/bounce messages using a null-sender I encourage you to contact them and suggest that they instead try using the "Auto-Submitted:" header field as described in RFC 3834 section 5.

  6. Charles says:

    Actually, your initial paragraph describing this issue is all wrong.

    You should NEVER, EVER bounce a message AFTER you have already accepted it for final delivery.

    The correct behavior is to do an SMTP REJECT – meaning, your server NEVER ACCEPTS it for final delivery – and let the SENDERS server generate the NDR to the original sender.

Comments are closed.

Skip to main content