The problem of backscatter, part 6 – Who sends the NDRs

Earlier in my third post, I said that if server A sends a message to server B and server B cannot deliver it, server B sends a message back to server A called an NDR.  It's not quite that simple, there are differing cases on who generates the NDR. Let me quote from Wikipedia since they summarize the issue nicely.

Imagine that Jack ( sends a message to Jill ( at a different site. (Note that these are two different domains: Jack uses a COM domain while Jill is using an ORG one). Once Jack's mail server has accepted the message, it must either pass it along to Jill's mail server, or else deposit a bounce message in Jack's mailbox.

Let us say that Jack's mail server passes it on to Jill's mail server (at, which accepts the message for delivery. However, unfortunately, a moment later the disk on the server fills up, and so the mail daemon cannot deposit the message in Jill's mailbox.

The mail server then must send a bounce message to, informing Jack that his message to Jill's mailbox could not be delivered.

Had the mail server known that the message would be undeliverable (for instance, if Jill had no user account there) then it would not have accepted the message in the first place, and therefore would not have sent the bounce. Instead, it would have rejected the message with an SMTP error code. This would leave Jack's mail server (at the obligation to create and deliver a bounce.

So, not always does the recipient mail server generate an NDR, only in some of the cases after it accepts the message and the SMTP conversation finishes (ie, after the DATA command) will the recipient mail server be responsible for generating it.  If the reject happens during the SMTP conversation, then the transmitting mail server sends the NDR.

There we have it, at this point we have seen how NDRs work - if you send a message and it can't be delivered by the receiving mail server after it has been accepted, you should get a bounce message back saying that it couldn't be delivered.  The bounce message should contain human-readable text as well as machine-parsable text.  That's how things are supposed to work... until spammers ruined everything (like usual).

Comments (3)
  1. Tony Toews says:

    But you still haven’t covered the true cause of most backscatter.  Or is that on your next posting?  (Of which I received over 1,000 today on one email account.  500 a few days ago.)

    And that is there the receiving MTA accepts the entire email, breaks the connection and then decides to bounce the message as being undeliverable.  Of course it was a spammer which sent the email in the first place.  And I get the scatterback.  

    Now if the MTA received the headers, looked to see if the account existed and then rejected the message with an SMTP error code I would never have received the scatter back.

    I can only presume that a few million more spams were rejected appropriately.

    By the way Microsoft Exchange, until very recently, has been a major cause of this problem.

  2. Frank says:

    Tony wrote: "I can only presume that a few million more spams were rejected appropriately." Maybe, not arguing about the number. And presumably there were also many spams (with your Return-Path) making it to existing inboxes of unhappy primary victims. Which is the main purpose of forging a plausible return address like yours instead of making up a less plausible random address.

Comments are closed.

Skip to main content