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 (firstname.lastname@example.org) sends a message to Jill (email@example.com) 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 example.org), which accepts the message for delivery. However, unfortunately, a moment later the disk on the example.org server fills up, and so the mail daemon cannot deposit the message in Jill's mailbox.
The example.org mail server then must send a bounce message to firstname.lastname@example.org, informing Jack that his message to Jill's mailbox could not be delivered.
Had the example.org 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 example.com) 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).