Sender Rewriting Scheme
For a RFC 5321 mail transfer agent (MTA), the Sender Rewriting Scheme (SRS) is a scheme for rewriting the envelope sender address of an email message, in view of remailing it. In this context, "remailing" is a kind of email forwarding. SRS was devised in order to forward email without breaking the Sender Policy Framework (SPF), in 2003. Background. In a number of cases, including change of email address and mailing lists, an MTA accepts an email message that is not destined to a local mailbox but needs to be forwarded. In such cases, the question arises  of who deserves 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 () 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 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. The rewriting scheme. 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 "" forwarding a message originally destined to to his new address : The example above is adapted  from Shevek. With respect to VERP, the local part () is moved after her domain name (), further adding a prefix (), a hash ('), and a timestamp ('). That reflects an operational difference: Eventual bounces back to a VERP address are handled within the rewriting domain, and forged messages can at most unsubscribe some users, a kind of abuse that hasn't seen significant exploits in the last decades. Instead, SRS aims at remailing a possible bounce back to "Alice", so that forged bounces can become an alluring technique for injecting spam apparently originating from the rewriting sender. SRS provides for another prefix, , to  be used for rewriting an already rewritten address, in a multi-hop scenario. If ' has to forward the message in turn, it can spare adding another timestamp and repeating the original local part (). That is, each new forwarder adds just its own hash (') and the domain name of the preceding forwarder: Database alternative. Using a database can definitely control the growth of rewritten addresses, since it is sufficient to put just a unique key in the rewritten local part. It also allows for a certain amount of anonymity in the resending process, if this is desired. However, a database requires  centralization and is a single point of failure. Header field alternative. Another possibility is to store the long rewritten address somewhere in the message header. The = 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. Historical background. 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 , but  paths were also used before and outside of SMTP, e.g. as "bang paths" in UUCP and Usenet (NetNews). All news articles still contain a header, example: The same information in an RFC 5321 e-mail "envelope" - that is the SMTP info like - would be: The 1st step reflects the sender, the 2nd step the next MTA, etc. In this example let's assume that the 2nd MTA forwards the mail to a 3rd MTA, where it is finally delivered. The final MTA is also known as Mail delivery agent (MDA), putting the mail into the mailbox of the recipient. The  MDA transforms the "reverse path" into the known header field: SMTP uses MX records for its forward routing. Explicit source routes as in... ...to route mail from via MTA to MDA were cumbersome. To make things worse sometimes the "new" (1982) style of addresses was mixed with old UUCP "bang paths" in constructs like... ...and various other kludges. SMTP and MX records made all this essentially useless. Therefore, source routing was deprecated 1989 in RFC 1123. One special case in RFC 1123 are gateways from or to other networks like UUCP and NetNews, where the first sending MTA cannot  reach the final receiver directly with TCP. It is solved by MX records and if necessary rewriting foreign addresses at the gateway. MX is an acronym for Mail eXchanger. Another special case are mailing lists, where the list server rewrites all "reverse paths" to its own error handling address for bounces (error messages) by recipients. The list server could automatically unsubscribe bouncing recipients. This type of address rewriting is known since RFC 821 and still used today (RFC 5321, as well as RFC 2821, updated the SMTP chapter in RFC 1123). Last but not least forwarding to another address always  worked by rewriting the address in the "forward path" also known as , if and only if the forwarding MTA accepted the responsibility for both forwarding the mail and returning potential bounce messages to the sender. RFC 821 and all later SMTP specifications offer two result codes for this situation: For privacy reasons these result codes are today rarely used; they include the or . But the meaning and the effect of forwarding to third parties is identical for and respectively. As noted RFC 1123 deprecated source routing, that implicitly also deprecated the reverse routing of bounces. It was a relatively small  Internet back in 1989, mail admins (postmasters) often knew each other and fixed problems on the fly. Routing bounce messages back via any forwarders was a waste of time and bandwidth if the MTA noting a problem (e.g. a rejection with a 5xx error code) could send the error message directly back to the MX of sender. Since RFC 1123 forwarders to third parties still rewrote the address, but kept the as is. As a side effect MTAs wishing to accept mail from forwarders generally accept any address. More than a decade later spammers started to abuse this flaw in  post-1123 SMTP, today most mails are spam and most "reverse paths" are forged. Note that spammers typically forge working "reverse paths", many MTAs reject mail if callback verification or other plausibility checks fail for the "reverse path". RFC 5321, as well as RFC 2821, states that non-delivery reports (bounces) must be sent to the "originator" as "indicated in the reverse path" after an MTA accepted the responsibility for delivery. However, the bounce message may be suppressed when the original content is "hostile" (cf. spam or virus mail) or the message is forged (RFC 5321, Section 6). Note that all  current forgery detection methods require the mailbox owner to supply information for them to work. Failing to supply the criteria should not make any bounce message classifiable as backscatter, although some people mistakenly think it should. Open relays and forwarders are in an unlucky position with regards to this issue, generally they can't guarantee that the address indicates the "originator", and they also can't guarantee that final delivery will succeed. This SMTP problem caused as side effect of RFC 1123 is addressed by SPF, and the executive summary is "SPF breaks forwarding" - actually that's not the case , only asks receivers to check SPF at their border MTA, not later. Receivers can arrange their forwarding in a way that works with SPF with in essence three strategies: Sender Rewriting Scheme (SRS) is one way for the third strategy.