Classification
Although the SMTP is a mature technology, counting more than thirty years, its architecture is increasingly strained by both normal and unsolicited load. 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. Therefore, two types of email bounces have been created: ''hard bounces'' and ''soft bounces''. 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. 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 ''[email protected]''), it may be that the mail daemon is unable to deposit the message in the specified user's mailbox if the underlyingBounce 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: * Unable to resolve the destination address. For example, if the domain name does not exist. * Unable to establish a connection with the destination address. For example, if the IP address is not assigned to a server, or if the server is offline.Bounce from forged message
Users may receive erroneous bounce messages about messages they never actually sent. This can happen in particular in the context ofOther 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 theReturn-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 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 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.
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 mostlyReturn-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.
* ''"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<>, 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:
* 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
The format for the reporting of administrative messages is defined by . A DSN may be a