Bounce message

Last updated

A bounce message or just "bounce" is an automated message from an email system, informing the sender of a previous message that the message has not been delivered (or some other delivery problem occurred). The original message is said to have "bounced".

Contents

This feedback may be immediate (some of the causes described here) or, if the sending system can retry, may arrive days later after these retries end.

More formal terms for bounce message include "Non-Delivery Report" or "Non-Delivery Receipt" (NDR), [Failed] "Delivery Status Notification" (DSN) message, or a "Non-Delivery Notification" (NDN). [1]

Classification

Although the SMTP is a mature technology, counting more than thirty years, its architecture is increasingly strained by both normal and unsolicited load. [2] The email systems have been enhanced with reputation systems tied to the actual sender of the email, with the idea of recipient's email servers rejecting the email when a forged sender is used in the protocol. [3]

Therefore, two types of email bounces have been created: hard bounces and soft bounces. [4] Both of them affect the IP reputation of the sender because the Email Service Providers (ESPs) consider the total bounce rate as a decision factor when directing the email into a user's Inbox. Briefly, the total bounce rate is calculated as the sum of the hard bounce rate and soft bounce rate.

Hard bounces

Hard bounces are permanent and they score higher in terms of sender's IP damage. Hard bounces occur when the sender's mail server determines that there is a high likelihood that the recipient is unavailable and is likely to remain so. A few of the occasions when hard bounces occur are when the recipients of the email find themselves in one of the following situations: incorrect identifier/incorrect domain (such as a typo in the email address or in the domain) or their server does not accept emails anymore. In this case, removal of the email addresses that bounce back is mandatory.

Soft bounces

Soft bounces are temporary. A bounced message that experiences a soft bounce may be tried to be redelivered at another time. [5] Soft bounces happen when the recipient of the email has either a full Inbox and therefore no space to store another email is available, or a limit on the size of the emails that it is allowed to receive has been reached. Additional situations in which a soft bounce appears is a block set up on the recipient's email to mark a certain sender as a 'spam' sender, or to blacklist a certain sender. Moreover, a temporary suspension of the recipient's email or a temporary error on the server are also causes of a soft bounce.

Delivery errors

Errors may occur at multiple places in mail delivery. A sender may sometimes receive a bounce message from their own mail server, reporting that it has been unable to send a message, or alternatively from a recipient's mail server reporting that although it had accepted the message, it is unable to deliver it to the specified user. When a server accepts a message for delivery, it is also accepting the responsibility to deliver a bounce message in the event that delivery fails.

Bounce due to lack of disk space

When an e-mail arrives at the destination server for an address (such as mymail.example, when sending to alice@mymail.example), it may be that the mail daemon is unable to deposit the message in the specified user's mailbox if the underlying hard drive of the server has insufficient space.

Bounce due to unreachable destination

When sending an e-mail, the service from which the e-mail is sent may be unable to reach the destination address. In such case, the sender would receive a bounce message from their own mail server. Common causes for mail servers being unable to reach a destination:

Bounce from forged message

Users may receive erroneous bounce messages about messages they never actually sent. This can happen in particular in the context of email spam or email viruses, where a spammer (sender) may forge a message to another user (intended recipient of spam), and forges the message to appear from yet another user (a third party). If the message cannot be delivered to the intended recipient, then the bounce message would be "returned" to the third party instead of the spammer. This is called backscatter.

Other causes

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.

Terminology

Bounces are a special form of autoresponder. Auto-responses (automatic 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.[ citation needed ]

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 email addresses, 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, 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. [6]

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, it can be common to receive mostly spam emails, which usually uses 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 content that passes the filter.
  • Viruses and worms. 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 and SPF.

Causes of a bounce message

There are many reasons why an email 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 spam filters. In addition, there are MUAs that allow users to "bounce" a message on demand. [7] These user-initiated bounces are bogus bounces; by definition, a real bounce is automated, and is emitted by a MTA or MDA.

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 their 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).

Format

MTAs involved in a reject are named according to the point of view of the Reporting MTA. MTA names are often of type dns. Bounce-DSN-MTA-names.png
MTAs involved in a reject are named according to the point of view of the Reporting MTA. MTA names are often of type dns.

The format for the reporting of administrative messages is defined by RFC   6522. A DSN may be a MIME multipart/report message composed of three parts:

  1. a human readable explanation;
  2. a machine parsable message/delivery-status, a list of "name: type; value" lines that state several possible fields; and
  3. 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;550Nosuchuserhere
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

Related Research Articles

<span class="mw-page-title-main">Email</span> Mail sent using electronic means

Electronic mail is a method of transmitting and receiving messages using electronic devices. It was conceived in the late–20th century as the digital version of, or counterpart to, mail. Email is a ubiquitous and very widely used communication medium; in current use, an email address is often treated as a basic and necessary part of many processes in business, commerce, government, education, entertainment, and other spheres of daily life in most countries.

Within the Internet email system, a message transfer agent (MTA), mail transfer agent, or mail relay is software that transfers electronic mail messages from one computer to another using the Simple Mail Transfer Protocol. In some contexts, the alternative names mail server, mail exchanger, or MX host are used to describe an MTA.

The Simple Mail Transfer Protocol (SMTP) is an Internet standard communication protocol for electronic mail transmission. Mail servers and other message transfer agents use SMTP to send and receive mail messages. User-level email clients typically use SMTP only for sending messages to a mail server for relaying, and typically submit outgoing email to the mail server on port 587 or 465 per RFC 8314. For retrieving messages, IMAP is standard, but proprietary servers also often implement proprietary protocols, e.g., Exchange ActiveSync.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.

Various anti-spam techniques are used to prevent email spam.

Sender Policy Framework (SPF) is an email authentication method which ensures the sending mail server is authorized to originate mail from the email sender's domain. This authentication only applies to the email sender listed in the "envelope from" field during the initial SMTP connection. If the email is bounced, a message is sent to this address, and for downstream transmission it typically appears in the "Return-Path" header. To authenticate the email address which is actually visible to recipients on the "From:" line, other technologies such as DMARC must be used. Forgery of this address is known as email spoofing, and is often used in phishing and email spam.

Greylisting is a method of defending e-mail users against spam. A mail transfer agent (MTA) using greylisting will "temporarily reject" any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again after a delay, and if sufficient time has elapsed, the email will be accepted.

In email, a return receipt is an acknowledgment by the recipient's email client to the sender of receipt of an email message. What acknowledgment, if any, is sent by the recipient to the sender is dependent on the email software of the recipient.

Email authentication, or validation, is a collection of techniques aimed at providing verifiable information about the origin of email messages by validating the domain ownership of any message transfer agents (MTA) who participated in transferring and possibly modifying a message.

<span class="mw-page-title-main">Message submission agent</span>

A message submission agent (MSA), or mail submission agent, is a computer program or software agent that receives electronic mail messages from a mail user agent (MUA) and cooperates with a mail transfer agent (MTA) for delivery of the mail. It uses ESMTP, a variant of the Simple Mail Transfer Protocol (SMTP), as specified in RFC 6409.

The Sender Rewriting Scheme (SRS) is a scheme for bypassing the Sender Policy Framework's (SPF) methods of preventing forged sender addresses. Forging a sender address is also known as email spoofing.

Variable envelope return path (VERP) is a technique used by some electronic mailing list software to enable automatic detection and removal of undeliverable e-mail addresses. It works by using a different return path for each recipient of a message.

Sieve is a programming language that can be used for email filtering. It owes its creation to the CMU Cyrus Project, creators of Cyrus IMAP server.

Emailtracking is a method for monitoring whether the email message is read by the intended recipient. Most tracking technologies use some form of digitally time-stamped record to reveal the exact time and date when an email is received or opened, as well as the IP address of the recipient.

A challenge–response system is a type of that automatically sends a reply with a challenge to the (alleged) sender of an incoming e-mail. It was originally designed in 1997 by Stan Weatherby, and was called Email Verification. In this reply, the purported sender is asked to perform some action to assure delivery of the original message, which would otherwise not be delivered. The action to perform typically takes relatively little effort to do once, but great effort to perform in large numbers. This effectively filters out spammers. Challenge–response systems only need to send challenges to unknown senders. Senders that have previously performed the challenging action, or who have previously been sent e-mail(s) to, would be automatically receive a challenge.

<span class="mw-page-title-main">Callback verification</span> Technique used with SMTP to validate e-mail addresses

Callback verification, also known as callout verification or Sender Address Verification, is a technique used by SMTP software in order to validate e-mail addresses. The most common target of verification is the sender address from the message envelope. It is mostly used as an anti-spam measure.

Email forwarding generically refers to the operation of re-sending a previously delivered email to an email address to one or more different email addresses.

An email alias is simply a forwarding email address. The term alias expansion is sometimes used to indicate a specific mode of email forwarding, thereby implying a more generic meaning of the term email alias as an address that is forwarded in a simplistic fashion.

Backscatter is incorrectly automated bounce messages sent by mail servers, typically as a side effect of incoming spam.

A bounce address is an email 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. It is not uncommon for a single document to use several of these names.

References

  1. ↑ "Examples of rogue unsolicited email messages", Security Risks in Social Media Technologies, Elsevier, pp. 241–242, 2013, doi:10.1016/b978-1-84334-714-9.50022-x, ISBN   978-1-84334-714-9
  2. ↑ AferganMike; BeverlyRobert (2005-01-01). "The state of the email address". ACM SIGCOMM Computer Communication Review. 35: 29–36. doi:10.1145/1052812.1052822. S2CID   16604893.
  3. ↑ "Countering illegal traffic: A snapshot of monitoring and enforcement". 2016-09-27. doi:10.18356/0f24bf9f-en.{{cite journal}}: Cite journal requires |journal= (help)
  4. ↑ "Hard Bounces vs Soft Bounces and how to remove them | Blog". bounceremove.com. Retrieved 2020-05-14.
  5. ↑ ,"Managing delivery of electronic messages using bounce profiles",issued 2005-05-26
  6. ↑ Stross, Randall (2008-06-15). "In the E-Mail Relay, Not Every Handoff Is Smooth". The New York Times. Retrieved 2010-04-26.
  7. ↑ Ray, William; Ray, John (2005-07-15). "Using Internet Applications in Mac OS X Tiger" . Retrieved 2008-10-02. Another method of defeating spam is to bounce mail back to them. This creates the appearance that your account doesn't exist and, if you're lucky, results in having your name removed from their lists., and Breen, Christopher (2006-01-27). "Bouncing the creeps". Macworld. Retrieved 2008-10-02. As you're probably aware, using Mail's Bounce command (Message > Bounce) isn't effective against spammers because nearly all the spam your receive carries a forged "from" address.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.