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.
Background
In a number of cases, including change of email address and mailing lists, a message transfer agent (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 (sender Rewriting Scheme) is a fairly general one. Its notion of reversing the path resembles the original routing dispositions for email, see below.
Please note: Using SRS protocol fails the SPF Alignment check for your DMARC record, and it's by design. Your DMARC record can still pass with a DKIM check.
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 :
ORIGINAL
: :
REWRITTEN
: :
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.
The local part, in this case , is moved because it may contain equal signs (=), so putting it at an extremity of the rewritten local part makes the latter parsable. The timestamp () has a one-day resolution in order to make the address invalid after a few days. Computed as , it can be stored as a two base32 characters, with a recycling period of about 3.5 years. The hash-based message authentication code () is computed against a local secret, but only a part of it is used; for example, storing the first 4 characters of a base64 representation provides 24 bits of security. The hash is checked by the domain who generated it, in case a bounce arrives. The prefix, , is meant to disambiguate regular addresses from rewritten ones; it is up to example.com to ensure that none of its users has an email address starting with .
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:
FURTHER REWRITTEN
: :
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.