For various reasons, particularly forged spam and email viruses, users may receive erroneous bounce messages sent in response to messages they never actually sent.
Let us say that Jack's mail server passes it on to Jill's mail server (at library.example), which accepts the message for delivery. However, unfortunately, a moment later the disk on the library.example server fills up, and so the mail daemon cannot deposit the message in Jill's mailbox. As an alternative cause of failure, consider that Jill might have instructed the library.example server to forward her mail to, say, firstname.lastname@example.org, and that the latter server refused the message for whatever reason.
The library.example mail server then must send a bounce message to email@example.com, informing Jack that his message to Jill's mailbox could not be delivered.
Had the library.example 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 store.example) the obligation to create and deliver a bounce.
However, problems arise if Jill's mail server receives a message with a forged Return-Path, e.g., if firstname.lastname@example.org sends an unsolicited bulk message claiming to be from email@example.com. In this case, Jill's mail server would send the bounce message to Jack even though Jack never sent the original message to Jill. This is called backscatter.
accept-then-bounce backscatter may be a type of spam. Effort should be made to reject the message during the SMTP session to avoid participating in email abuse of innocent third parties.
Examples of other auto replies are vacation mails, challenges from challenge-response spam filtering, replies from Mailing list, and feedback reports. These other auto replies are discussed in RFC 3834: auto replies should be sent to the Return-Path stated in the received mail which has triggered the auto reply, and this response is typically sent with an empty Return-Path; otherwise auto responders could be trapped in sending auto replies back and forth.
The Return-Path is visible in delivered mail as header field Return-Path inserted by the SMTP mail delivery agent ( MDA) (which is usually combined with a mail transfer agent, or MTA). The MDA simply copies the reverse path in the SMTP MAIL FROM command into the Return-Path. The MDA also removes bogus Return-Path header fields inserted by other MTAs; this header field is generally guaranteed to reflect the last reverse path seen in the MAIL FROM command.
Today these paths are normally reduced to ordinary , as the old SMTP 'source routing' was deprecated in 1989; for some historical background info see Sender Rewriting Scheme. One special form of a path still exists: the empty path MAIL FROM:<>, used for many auto replies and especially all bounces.
In a strict sense, bounces sent with a non-empty Return-Path are incorrect. RFC 3834 offers some heuristics to identify incorrect bounces based on the local part (left hand side before the "@") of the address in a non-empty Return-Path, and it even defines a mail header field, Auto-Submitted, to identify auto replies. But the mail header is a part of the mail data (SMTP command DATA), and MTAs typically don't look into the mail. They deal with the envelope, that includes the MAIL FROM address (a.k.a. Return-Path, Envelope-FROM, or "reverse path") but not, e.g., the RFC 2822-From in the mail header field From. These details are important for schemes like BATV.
The remaining bounces with an empty Return-Path are non-delivery reports ( NDRs) or delivery status notifications (DSNs). DSNs can be explicitly solicited with an SMTP Service Extension (ESMTP), however it is not widely used. Explicit requests for delivery failure details is much more commonly implemented with variable envelope return path (VERP), while explicit requests for them are rarely implemented.
NDRs are a basic SMTP function. As soon as an MTA has accepted a mail for forwarding or delivery it cannot silently delete ("drop") it; it has to create and send a bounce message to the originator if forwarding or delivery failed.
"If an SMTP server has accepted the task of relaying the mail and later finds that the destination is incorrect or that the mail cannot be delivered for some other reason, then it MUST construct an "undeliverable mail" notification message and send it to the originator of the undeliverable mail (as indicated by the reverse-path)."
This rule is essential for SMTP: as the name says, it's a 'simple' protocol, it cannot reliably work if mail silently vanishes in black holes, so bounces are required to spot and fix problems.
Quoting again RFC 5321, section 6.2:
"As discussed in Section 7.8 and Section 7.9 below, dropping mail without notification of the sender is permitted in practice. However, it is extremely dangerous and violates a long tradition and community expectations that mail is either delivered or returned. If silent message-dropping is misused, it could easily undermine confidence in the reliability of the Internet's mail systems. So silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate."
Not validating the sender is an inherent flaw in today's SMTP, which is without the deprecated source routes mentioned earlier. This is addressed by various proposals, most directly by BATV and SPF.
Bounce messages in SMTP are sent with the envelope sender address <>, known as the null sender address. They are frequently sent with a From: header address of MAILER-DAEMON at the recipient site.
Typically, a bounce message will contain several pieces of information to help the original sender in understanding the reason his message was not delivered:
RFC 3463 describes the codes used to indicate the bounce reason. Common codes are 5.1.1 (Unknown user), 5.2.2 (Mailbox full) and 5.7.1 (Rejected by security policy/mail filter).
The second part of a DSN is also quite readable. It is essential to understand which MTA played which role. The Reporting-MTA is responsible for composing and sending the DSN.
When a Remote-MTA rejects a message during an SMTP transaction, a field Diagnostic-Code of type smtp may be used to report that value. Note that beside the numerical 3-digit value, the SMTP response contains itself a human readable part. The information
Remote-MTA: dns; smtp.store.example [192.0.2.3] Diagnostic-Code: smtp; 550 No such user here
while talking to smtp.store.example [192.0.2.3] >>> RCPT TO:<firstname.lastname@example.org> <<< 550 No such user here