"to different recipients. Protocol engineers sometimes use the term Mediator to refer to a forwarding server. Because of spam, it is becoming increasingly difficult to reliably forward mail across different domains, and some recommend avoiding it if at all possible. Plain message-forwarding changes the envelope recipient(s) and leaves the envelope sender field untouched. The ""envelope sender"" field does not equate to the ""From"" header which Email client software usually displays: it represents a field used in the early stages of the SMTP protocol, and subsequently saved as the ""Return-Path"" header. This field holds the address to which mail-systems must send"
"Bounce address 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. All of these names refer to the email address provided with the MAIL FROM command during the SMTP session. Ordinarily, the bounce address is not seen by email users and, without standardization of the name, it may cause confusion. If an email"
"email should go, and the MAIL FROM command to indicate where it came from. While its original usage was to provide information about how to return bounce messages, since the late 1990s, other uses have come about. These typically take advantage of properties of the bounce address, such as: Extended uses include mailing list handling in Variable envelope return path (VERP), email authentication, spam filtering, and backscatter reduction in Bounce Address Tag Validation. The various terms have different origins and sometimes different meanings, although these differences have often become moot on the modern internet. Bounce address A bounce address is"
"sends the ""DATA"" command, and typically sends several header items, including: and sometimes: The result is that the email recipient sees the email as having come from the address in the ""From:"" header; they may sometimes be able to find the ""MAIL FROM"" address; and if they reply to the email it will go to either the address presented in the ""From:"" or ""Reply-to:"" header - but none of these addresses are typically reliable, so automated bounce messages may generate backscatter. Malware such as Klez and Sober and many more modern examples often search for email addresses within the computer"
"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."
"generate a bounce message back to the supposed sender. However, if (as is often the case with spam), the sender information on the incoming email was forged to be that of an unrelated third party then this bounce message is backscatter spam. For this reason it is generally preferable for most rejection of incoming email to happen during the SMTP connection stage, with a 5xx error code, while the sending server is still connected. In this case then the ""sending"" server will report the problem to the real sender cleanly. Firewalls and routers can be programmed to not allow SMTP"
"message with the undeliverable address that caused the bounce. If the mailing list software can see that a bounce resulted from an attempt to send a message to user@example.com then it doesn't need to understand the rest of the information in the bounce. It can simply count how many messages were recently sent to user@example.com, and how many bounces resulted, and if the proportion of bounced messages is too high, the address is removed from the list. While bounce message formats in general vary wildly, there is one aspect of a bounce message that is highly predictable: ""the address to"
"Backscatter (email) Backscatter (also known as outscatter, misdirected bounces, blowback or collateral spam) is incorrectly automated bounce messages sent by mail servers, typically as a side effect of incoming spam. Recipients of such messages see them as a form of unsolicited bulk email or spam, because they were not solicited by the recipients, are substantially similar to each other, and are delivered in bulk quantities. Systems that generate email backscatter may be listed on various email blacklists and may be in violation of internet service providers' Terms of Service. Backscatter occurs because worms and spam messages often forge their sender"
"in a way that allows them to reliably detect incoming bogus bounce messages. Backscatter (email) Backscatter (also known as outscatter, misdirected bounces, blowback or collateral spam) is incorrectly automated bounce messages sent by mail servers, typically as a side effect of incoming spam. Recipients of such messages see them as a form of unsolicited bulk email or spam, because they were not solicited by the recipients, are substantially similar to each other, and are delivered in bulk quantities. Systems that generate email backscatter may be listed on various email blacklists and may be in violation of internet service providers' Terms"
"not enough room left to accept any more. When a message is sent to a mailing list, the mailing list software re-sends it to all of the addresses on the list. The presence of invalid addresses in the list results in bounce messages being sent to the owner of the list. If the mailing list is small, the owner can read the bounce messages and manually remove the invalid addresses from the list. With a larger mailing list, this is a tedious, unpleasant job, so it is desirable to automate the process. Unfortunately, most bounce messages have historically been designed"
"Bounce message A bounce message or just ""bounce"" is an automated message from a mail system, informing the sender of a previous message that that message had not been delivered (or some other delivery problem occurred). The original message is said to have ""bounced"". 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). 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 deliver a message,"
"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 email abuse of innocent third parties. Bounces are a special form of autoresponder. Autoresponses (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"
"numerical 3-digit value, the SMTP response contains itself a human readable part. The information Bounce message A bounce message or just ""bounce"" is an automated message from a mail system, informing the sender of a previous message that that message had not been delivered (or some other delivery problem occurred). The original message is said to have ""bounced"". 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). Errors may occur at multiple places in mail delivery. A sender may sometimes receive a bounce message from"
"same as the ""envelope"" values, such is not always the case. For example, on electronic mailing lists, the information seen in the ""From:"" header will come from the person who sent the email to the list, while the bounce address will be set to that of the mailing list software, so problems delivering the mailing list messages can be handled correctly. Only the envelope information is looked at to resolve where the email should go; the body of the email is not examined. Mail Transfer Agents (MTA) using the SMTP protocol use the RCPT TO command to determine where the"
"Return address In postal mail, a return address is an explicit inclusion of the address of the person sending the message to. It provides the recipient (and sometimes authorized intermediaries) with a means to determine how to respond to the sender of the message if needed. The return address need not include a sender's name, but should include address or P.O. box details in the same way as the delivery address should. In some countries, the return address is conventionally located in the upper left hand corner of the envelope, card, or label. In the United Kingdom, the return address"
"or alternatively from a ""recipient's"" mail server reporting that although it had accepted the message, it now finds it 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. For various reasons, particularly forged spam and email viruses, users may receive erroneous bounce messages sent in response to messages they never actually sent. 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"
"unsolicited email. Blank spam may be originated in different ways, either intentional or unintentionally: Backscatter is a side-effect of email spam, viruses, and worms. It happens when email servers are mis-configured to send a bogus bounce message to the envelope sender when rejecting or quarantining email (rather than simply rejecting the attempt to send the message). If the sender address was forged, then the bounce may go to an innocent party. Since these messages were not solicited by the recipients, are substantially similar to each other, and are delivered in bulk quantities, they qualify as unsolicited bulk email or spam."
"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. 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,"
"database requires centralization and is a single point of failure. Another possibility is to store the long rewritten address somewhere in the message header. The i= tag of a DKIM-Signature may be a good place, as such choice considerably improves the security. This technique has been just observed. Unless there is a backup mechanism, it can only work if the bounce message is in a standard format. Historically all mail transfer agents (MTAs) added their host name to the ""reverse path"". In the Simple Mail Transfer Protocol (SMTP) this ""reverse path"" is also known as MAIL FROM, but paths were"
"of bounces. Microsoft Exchange can sometimes bounce a message without providing any indication of the address to which the original message was sent. When Exchange knows the intended recipient, but is not willing to accept email for them, it omits their address. If a message is sent to codice_1 and the server knows that this is codice_2, it will bounce the message saying that the message to codice_2 could not be delivered, leaving out the codice_1 address altogether. VERP is the only viable way to handle such bounces correctly. The hard part of bounce handling is matching up a bounce"
"bounce messages — reporting delivery-failure (or success) — if any. By contrast, the terms ""remailing"" or ""redistribution"" can sometimes mean re-sending the message and also rewriting the ""envelope sender"" field. Electronic mailing lists furnish a typical example. Authors submit messages to a ""reflector"" that performs remailing to each list address. That way, bounce messages (which report a failure delivering a message to any list- subscriber) will not reach the author of a message. However, annoying misconfigured ""vacation"" autoreplies do reach authors. Typically, plain message-forwarding does alias-expansion, while proper message-forwarding, also named ""forwarding"" tout-court serves for mailing-lists. When additional modifications to"
"addition, there are MUAs that allow users to ""bounce"" a message on demand. 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 codice_1, known as the ""null sender address"". They are frequently sent with a codice_2 header address of codice_3 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"
"Backscatter occurs when the ""bounce"" method is used, and the sender information on the incoming email was that of an unrelated third party. Every step to control worms and spam messages helps reduce backscatter, but other common approaches, such as those in this section, also reduce the same problem. During the initial SMTP connection, mailservers can do a range of checks, and often reject email with a 5xx error code ""while the sending server is still connected"". Rejecting a message at the connection-stage in this way will usually cause the ""sending"" MTA to generate a local bounce message or Non-Delivery"
"a label over the former address with the current address. The mail is returned to the mailstream to forward to the new location. Mail with addresses that cannot be resolved by the automated system are separated for human intervention. If a local postal worker can read the address, he or she manually sorts it out according to the ZIP code on the article. If the address cannot be read, mail is either returned to the sender (First-Class Mail with a valid return address) or is sent to the Mail Recovery Center in Atlanta, Georgia (formerly known as the dead letter"
"due to changes to email software, both on the client side and the server side, that prevent automatic replies to vacation responses and bounced mail responses. Email loop An email loop is an infinite loop phenomenon, resulting from mail servers, scripts, or email clients that generate automatic replies or responses. If one such automatic response triggers another automatic response on the other side, an email loop is created. The process can continue until one mailbox is full or reaches its mail sending limit. In theory, the email loop could last indefinitely. Email loops may be caused accidentally or maliciously, causing"
"recovering the original envelope address, so that if a bounce does arrive, it can be forwarded along the reverse path—with an empty envelope sender this time. While there are other workarounds, SRS is a fairly general one. Its notion of reversing the path resembles the original routing dispositions for email, see below. SRS is a form of variable envelope return path (VERP) inasmuch as it encodes the original envelope sender in the local part of the rewritten address. Consider ""example.com"" forwarding a message originally destined to codice_2 to his new address codice_3: The example above is adapted from Shevek. With"
"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. 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"
"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 Return-Path, e.g., if spammer@example.net"
"Bounce Address Tag Validation In computing, Bounce Address Tag Validation (BATV) is a method, defined in an Internet Draft, for determining whether the bounce address specified in an E-mail message is valid. It is designed to reject backscatter, that is, bounce messages to forged return addresses. The basic idea is to send all e-mail with a return address that includes a timestamp and a cryptographic token that cannot be forged. Any e-mail that is returned as a bounce without a valid signature can then be rejected. E-mail that is being bounced back should have an empty (null) return address so"
"""backscatter"" emails to innocent parties - in itself a form of spam - or being used to perform ""Joe job"" attacks. Although email spoofing is effective in forging the email address, the IP address of the computer sending the mail can generally be identified from the ""Received:"" lines in the email header. In many cases this is likely to be an innocent third party infected by malware that is sending the email without the owner's knowledge. The SSL/TLS system used to encrypt server-to-server email traffic can also be used to enforce authentication, but in practice it is seldom used, and"
"problems that prevent BATV systems from eliminating all backscatter. Bounce Address Tag Validation In computing, Bounce Address Tag Validation (BATV) is a method, defined in an Internet Draft, for determining whether the bounce address specified in an E-mail message is valid. It is designed to reject backscatter, that is, bounce messages to forged return addresses. The basic idea is to send all e-mail with a return address that includes a timestamp and a cryptographic token that cannot be forged. Any e-mail that is returned as a bounce without a valid signature can then be rejected. E-mail that is being bounced"
"to receive any related bounce message. In general, that is either the author, or a person or other entity who administers the forwarding itself. Sending bounces to the author is administratively simpler and used to be accomplished by just keeping the original envelope sender. However, if the author address is subject to a strict SPF policy (codice_1) and the target MTA happens to enforce it, the forwarding transaction can be rejected. As a workaround, it is possible to synthesize on the fly a temporary bounce address that will direct any bounce back to the current MTA. The scheme provides for"
"a message obliges an MTA to deliver it, and when a message cannot be delivered, that MTA must send a bounce message back to the sender, indicating the problem. Users can retrieve their messages from servers using standard protocols such as POP or IMAP, or, as is more likely in a large corporate environment, with a proprietary protocol specific to Novell Groupwise, Lotus Notes or Microsoft Exchange Servers. Programs used by users for retrieving, reading, and managing email are called mail user agents (MUAs). Mail can be stored on the client, on the server side, or in both places. Standard"