Sender Policy Framework

SRS

Difference (from prior major revision) (no other diffs)

Paragraph 1		Paragraph 1
== ''SRS: Sender Rewriting Scheme''		== ''SRS: Sender Rewriting Scheme''

<box type=note width=25em float=right>		<box type=note width=25em float=right>
Paragraph 4		Paragraph 4
RFC 1123 introduced two very convenient but easily abused features: relaying without regard to recipient (open relays) and forwarding without regard to sender. Both features have been abused to the point of unusability. Open relays have been suppressed via blacklisting. SPF stops forwarding without rewriting, but it does so on an opt-in basis. If you, as a recipient do not check SPF, then you can continue to use forwarding without rewriting the sender as before. However, if you do check SPF, and you wish to reject messages that fail SPF, then you must do one of two things to avoid rejecting legitimate mail.		RFC 1123 introduced two very convenient but easily abused features: relaying without regard to recipient (open relays) and forwarding without regard to sender. Both features have been abused to the point of unusability. Open relays have been suppressed via blacklisting. SPF stops forwarding without rewriting, but it does so on an opt-in basis. If you, as a recipient do not check SPF, then you can continue to use forwarding without rewriting the sender as before. However, if you do check SPF, and you wish to reject messages that fail SPF, then you must do one of two things to avoid rejecting legitimate mail:

# whitelist forwarder IP addresses		# whitelist forwarder IP addresses
Paragraph 8		Paragraph 8
</box>		</box>

=== What is SRS		=== What is SRS
SPF "breaks" email forwarding. SRS is a way to fix it. SRS is a simple way for forwarding MTAs to rewrite the sender address. The original concept was published in [[http://www.openspf.org/svn/project/specs/drafts/draft-mengwong-sender-rewrite-01.txt\|draft-mengwong-sender-rewrite]].		SPF "breaks" email forwarding. SRS is a way to fix it. SRS is a simple way for forwarding MTAs to rewrite the sender address. The original concept was published in [[http://www.openspf.org/svn/project/specs/drafts/draft-mengwong-sender-rewrite-01.txt\|draft-mengwong-sender-rewrite]] and further expanded on in a [[http://www.libsrs2.org/srs/srs.pdf\|paper by Shevek]].

SRS: Sender Rewriting Scheme

Why SRS is needed

RFC 1123 introduced two very convenient but easily abused features: relaying without regard to recipient (open relays) and forwarding without regard to sender. Both features have been abused to the point of unusability. Open relays have been suppressed via blacklisting. SPF stops forwarding without rewriting, but it does so on an opt-in basis. If you, as a recipient do not check SPF, then you can continue to use forwarding without rewriting the sender as before. However, if you do check SPF, and you wish to reject messages that fail SPF, then you must do one of two things to avoid rejecting legitimate mail:

whitelist forwarder IP addresses
use forwarders that rewrite the sender

Note that in either case, if your forwarders do not check SPF themselves, then you will not be able to detect forgeries for mail that they relay.

What is SRS

SPF "breaks" email forwarding. SRS is a way to fix it. SRS is a simple way for forwarding MTAs to rewrite the sender address. The original concept was published in draft-mengwong-sender-rewrite and further expanded on in a paper by Shevek.

MTA Integration

Mark Kramer has produced instructions for doing SRS in Sendmail; his instructions do SRS for all outbound mail in a VERP-like fashion. See also http://srs-socketmap.info for a sendmail socketmap daemon in Perl, and http://bmsi.com/python/pysrs.html for a similar daemon in Python. Postfix doesn't support a plugin interface that can do SRS, but there is a source patch for libsrs2, which also supports Sendmail and Exim.

Implementation

Click here for a list of implementations.

If you would like to discuss SRS, please join the SRS mailing list.

Comparing verbatim email forwarding with Sender Rewriting Scheme

In traditional or verbatim forwarding, the return-path is preserved in the outgoing message. In an SPF world, forwarders need to rewrite the return-path to stay in good standing. The SRS library implementations help perform the needed transformation. Full-time forwarding services may prefer to integrate this logic directly into their MTAs. Smaller sites don't have to: they can just call the srs utility which does all the work.

The rewritten return-path contains the original sender so whitelisting can still work, albeit with some tweaking. To prevent bad guys from using forwarders as an open relay, SRS adds a hash (yf09). It also adds a timestamp (Cw) which causes addresses to expire. If cob@third.com is undeliverable, pobox.com gets the bounce; it unwraps ann@orig.com and forwards the bounce back to her. Note that no escaping is needed.

What if there are multiple forwarders? No problem: the SRS0 marker tells other forwarders that SRS has already happened. The second forwarder changes SRS0 to SRS1, slaps on the first forwarder's domain, and leaves everything else untouched. Subsequent forwarders just change the domain at the end. Thus is address growth kept in check. Mail::SRS and pysrs also provide a database-backed version that guarantees short addresses.

Unless noted otherwise, all content on this website is dual-licensed under the GNU GPL v2 and the Creative Commons CC BY-SA 2.5.
The openspf.org domain name was donated by James Couzens, and related domain names by John Pinkerton. Thanks!