Bounce message
Encyclopedia
In the Internet's standard e-mail protocol
SMTP, a bounce message, also called a Non-Delivery Report/Receipt (NDR), a (failed) Delivery Status Notification (DSN) message, a Non-Delivery Notification (NDN) or simply a bounce, is an automated electronic mail message from a mail system informing the sender of another message about a delivery problem. The original message is said to have bounced.
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, jill@example.edu, and that the latter server refused the message for whatever reason.
The library.example mail server then must send a bounce message to jack@store.example, 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 From: field, e.g., if spammer@example.net sends an unsolicited bulk message claiming to be from jack@store.example. 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 e-mail abuse of innocent third parties.
. Auto replies are mails sent by a program—as opposed to a human user—in reply to a received mail and sent to the bounce address
.
Examples of other auto replies are vacation mails, challenges from challenge-response spam filtering
, replies from list servers
, 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 transport 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 e-mail address
es, 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.
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.
, which usually utilizes forged Return-Paths. It is then often impossible for the MTA to inform the originator, and sending a bounce to the forged Return-Path would hit an innocent third party. In addition, there are specific reasons why it is preferable to silently drop a message rather than reject it (let alone bounce it):
Quoting again RFC 5321, section 6.2:
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
.
filters. In addition, there are MUAs that allow users to bounce a message on demand.
Bounce messages in SMTP are sent with the envelope sender address
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).
multipart/report message composed of three parts:
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:<nonexistinguser@store.example>
<<< 550 No such user here
Communications protocol
A communications protocol is a system of digital message formats and rules for exchanging those messages in or between computing systems and in telecommunications...
SMTP, a bounce message, also called a Non-Delivery Report/Receipt (NDR), a (failed) Delivery Status Notification (DSN) message, a Non-Delivery Notification (NDN) or simply a bounce, is an automated electronic mail message from a mail system informing the sender of another message about a delivery problem. The original message is said to have bounced.
Delivery errors
Errors can occur at multiple places in mail delivery. A sender may sometimes receive a bounce message from the sender's mail server, and other times from a recipient's mail server. Bounce-back messages from the recipient's mail server are required when a mail server accepted a message that was undeliverable; when a server accepts a message for delivery, it is also accepting the responsibility to deliver a DSN in the event the delivery fails. With the rise in forged spam and e-mail viruses, users now frequently receive erroneous bounce messages sent in response to messages they never actually sent. Modern servers try hard to ascertain that a message can be delivered before they accept it.Example
Imagine that Jack (jack@store.example) sends a message to Jill (jill@library.example) at a different site. 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 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
Daemon (computer software)
In Unix and other multitasking computer operating systems, a daemon is a computer program that runs as a background process, rather than being under the direct control of an interactive user...
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, jill@example.edu, and that the latter server refused the message for whatever reason.
The library.example mail server then must send a bounce message to jack@store.example, 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 From: field, e.g., if spammer@example.net sends an unsolicited bulk message claiming to be from jack@store.example. 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
Backscatter (e-mail)
Backscatter is incorrect automated bounce messages sent by mail servers, typically as a side effect of incoming spam....
.
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 e-mail abuse of innocent third parties.
Terminology
Bounces are a special form of autoresponderAutoresponder
An autoresponder is a computer program that automatically answers e-mail sent to it. They can be very simple or quite complex.The first autoresponders were created within mail transfer agents that found they could not deliver an e-mail to a given address. These create bounce messages such as "your...
. Auto replies are mails sent by a program—as opposed to a human user—in reply to a received mail and sent to the bounce address
Bounce address
A bounce address is an e-mail address to which bounce messages are delivered. There are many variants of the name, none of them used universally, including return path, reverse path, envelope from, envelope sender, MAIL FROM, 5321-FROM, return address, From_, Errors-to, etc...
.
Examples of other auto replies are vacation mails, challenges from challenge-response spam filtering
Challenge-response spam filtering
A challenge–response system is a type of spam filter that automatically sends a reply with a challenge to the sender of an incoming e-mail. In this reply, the sender is asked to perform some action to assure delivery of the original message, which would otherwise not be delivered...
, replies from list servers
Mailing list
A mailing list is a collection of names and addresses used by an individual or an organization to send material to multiple recipients. The term is often extended to include the people subscribed to such a list, so the group of subscribers is referred to as "the mailing list", or simply "the...
, and feedback reports
Feedback Loop (email)
A feedback loop , sometimes called a complaint feedback loop, is an inter-organizational form of feedback by which an Internet service provider forwards the complaints originating from their users to the sender's organizations. ISPs can receive users' complaints by placing report spam buttons on...
. 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
Mail delivery agent
A mail delivery agent or message delivery agent is a computer software component that is responsible for the delivery of e-mail messages to a local recipient's mailbox...
(MDA) (which is usually combined with a mail transport 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 e-mail address
E-mail address
An email address identifies an email box to which email messages are delivered. An example format of an email address is lewis@example.net which is read as lewis at example dot net...
es, as the old SMTP 'source routing
Source routing
In computer networking, source routing allows a sender of a packet to partially or completely specify the route the packet takes through the network...
' was deprecated in 1989; for some historical background info see Sender Rewriting Scheme
Sender Rewriting Scheme
Sender Rewriting Scheme is a technique to re-mail an email message so that eventual Delivery Status Notifications can reach the original message sender...
. 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
Bounce Address Tag Validation
In computing, Bounce Address Tag Validation is a method, defined in an Internet Draft, for determining whether the bounce address specified in an E-mail message is valid...
.
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
Variable envelope return path
Variable envelope return path is a technique used by some electronic mailing list software to enable automatic detection and removal of undeliverable e-mail addresses...
(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.
Bouncing vs. rejecting
Excluding MDAs, all MTAs forward mails to another MTA. This next MTA is free to reject the mail with an SMTP error message like "user unknown", "over quota", etc. At this point the sending MTA has to bounce the message, i.e. inform its originator. A bounce may arise also without a rejecting MTA, or as RFC 5321 puts it:"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.
Silently dropping messages
Today, however, most email is spamE-mail spam
Email spam, also known as junk email or unsolicited bulk email , is a subset of spam that involves nearly identical messages sent to numerous recipients by email. Definitions of spam usually include the aspects that email is unsolicited and sent in bulk. One subset of UBE is UCE...
, which usually utilizes forged Return-Paths. It is then often impossible for the MTA to inform the originator, and sending a bounce to the forged Return-Path would hit an innocent third party. In addition, there are specific reasons why it is preferable to silently drop a message rather than reject it (let alone bounce it):
- Heuristically filtered spam. Spam filters are not perfect. Rejecting spam based on content filtering implies giving to spammers a test environment where they can try several alternatives until they find a content that passes the filter.
- VirusComputer virusA computer virus is a computer program that can replicate itself and spread from one computer to another. The term "virus" is also commonly but erroneously used to refer to other types of malware, including but not limited to adware and spyware programs that do not have the reproductive ability...
es and wormComputer wormA computer worm is a self-replicating malware computer program, which uses a computer network to send copies of itself to other nodes and it may do so without any user intervention. This is due to security shortcomings on the target computer. Unlike a computer virus, it does not need to attach...
s. Most times these are sent automatically from an infected machine. Since a bounce may contain a copy of the worm itself, it may contribute to its diffusion.
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
Bounce Address Tag Validation
In computing, Bounce Address Tag Validation is a method, defined in an Internet Draft, for determining whether the bounce address specified in an E-mail message is valid...
and SPF
Sender Policy Framework
Sender Policy Framework is an email validation system designed to prevent email spam by detecting email spoofing, a common vulnerability, by verifying sender IP addresses. SPF allows administrators to specify which hosts are allowed to send mail from a given domain by creating a specific SPF...
.
Causes of a bounce message
There are many reasons why an e-mail may bounce. One reason is if the recipient address is misspelled, or simply does not exist on the receiving system. This is a user unknown condition. Other reasons include resource exhaustion — such as a full disk — or the rejection of the message due to spamE-mail spam
Email spam, also known as junk email or unsolicited bulk email , is a subset of spam that involves nearly identical messages sent to numerous recipients by email. Definitions of spam usually include the aspects that email is unsolicited and sent in bulk. One subset of UBE is UCE...
filters. In addition, there are MUAs that allow users to bounce a message on demand.
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:
- The date and time the message was bounced,
- The identity of the mail server that bounced it,
- The reason that it was bounced (e.g. user unknown or mailbox full),
- The headers of the bounced message, and
- Some or all of the content of the bounced message.
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).
Format
A DSN may be a MIMEMIME
Multipurpose Internet Mail Extensions is an Internet standard that extends the format of email to support:* Text in character sets other than ASCII* Non-text attachments* Message bodies with multiple parts...
multipart/report message composed of three parts:
- a human readable explanation;
- a machine parsable message/delivery-status, a list of "name: type; value" lines that state several possible fields; and
- the original message, or a portion thereof, as an entity of type message/rfc822.
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
- is sometimes reported as, e.g.,
while talking to smtp.store.example [192.0.2.3]
>>> RCPT TO:<nonexistinguser@store.example>
<<< 550 No such user here
See also
- BackscatterBackscatter (e-mail)Backscatter is incorrect automated bounce messages sent by mail servers, typically as a side effect of incoming spam....
(Backscatter of email spam) - Bounce Address Tag ValidationBounce Address Tag ValidationIn computing, Bounce Address Tag Validation is a method, defined in an Internet Draft, for determining whether the bounce address specified in an E-mail message is valid...
(BATV) - Return receiptReturn receiptA return receipt is a postal service document confirming the arrival of a message or parcel at its intended destination. Internationally, the service is known as avis de réception , but in some English-speaking countries, acknowledgement of receipt or advice of receipt is used.-Email:As applied to...
- Sender Policy FrameworkSender Policy FrameworkSender Policy Framework is an email validation system designed to prevent email spam by detecting email spoofing, a common vulnerability, by verifying sender IP addresses. SPF allows administrators to specify which hosts are allowed to send mail from a given domain by creating a specific SPF...
(SPF) - Sender Rewriting SchemeSender Rewriting SchemeSender Rewriting Scheme is a technique to re-mail an email message so that eventual Delivery Status Notifications can reach the original message sender...
(SRS) - Simple Mail Transfer ProtocolSimple Mail Transfer ProtocolSimple Mail Transfer Protocol is an Internet standard for electronic mail transmission across Internet Protocol networks. SMTP was first defined by RFC 821 , and last updated by RFC 5321 which includes the extended SMTP additions, and is the protocol in widespread use today...
(SMTP) - Variable envelope return pathVariable envelope return pathVariable envelope return path is a technique used by some electronic mailing list software to enable automatic detection and removal of undeliverable e-mail addresses...
(VERP)
Related RFCs
- RFC 3461 - Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
- RFC 3463 - Enhanced Status Codes for SMTP
- RFC 3464 - An Extensible Message Format for Delivery Status Notifications
- RFC 3834 - Recommendations for Automatic Responses to Electronic Mail
- RFC 5337 - Internationalized Delivery Status and Disposition Notifications