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.