Sender Rewriting Scheme

Sender Rewriting Scheme (SRS) is a technique to re-mailan email message so that eventual Delivery Status Notificationscan reach the original message sender. In this context, "re-mailing"is an alternative to Email forwarding, which is not allowed bythe Sender Policy Framework.

Background

Historically all Mail transfer agents (MTAs)added their host name to the "reverse path". Inthe Simple Mail Transfer Protocol (SMTP) this"reverse path" is also known as MAIL FROM, butpaths were also used before and outside of SMTP,e.g. as "bang paths" in UUCP and Usenet(NetNews). All news articles still contain aPath header, example:

Path: news.server.example!other.example!not-for-mail

The same info in an RFC 821 e-mail "envelope" -that is the SMTP info like MAIL FROM - would be:

# MAIL FROM:<[e-mail]>
# MAIL FROM:<@news.server.example:[e-mail]>

The 1st step reflects the sender, the 2nd step thenext MTA, etc. In this example let's assume thatthe 2nd MTA forwards the mail to a 3rd MTA, whereit is finally delivered. The final MTA is alsoknown as Mail delivery agent (MDA), puttingthe mail into the mailbox of the recipient. TheMDA transforms the "reverse path" into the knownReturn-Path header field:

Return-Path:<@news.server.example:[e-mail]>

SMTP uses MX records for its forward routing.Explicit source routes as in...

RCPT TO:<@news.server.example:[e-mail]>

...to route mail from other.examplevia MTA news.server.exampleto MDA destination.example werecumbersome. To make things worse sometimes the"new" (1982) style of addresses was mixed withold UUCP "bang paths" in constructs like...

destination.example![e-mail] other.example![e-mail]

...and various other kludges. SMTP and MX recordsmade all this essentially useless. Thereforesource routing was deprecated 1989 in RFC 1123.

One special case in RFC 1123 are gateways from orto other networks like UUCP and NetNews, where thefirst sending MTA cannot reach the final receiverdirectly with
TCP. It issolved by MX records and if necessary rewritingforeign addresses at the gateway. MX is anacronym for Mail eXchanger.

Another special case are
mailing lists, wherethe list server rewrites all "reverse paths" toits own error handling address for
bounces (error messages) byrecipients. The list server could automaticallyunsubscribe bouncing recipients. This type ofaddress rewriting is known since RFC 821 and stillused today ( RFC 2821 obsoleted the SMTP chapterin RFC 1123 ).

Last but not least forwarding to another addressalways worked by rewriting the address in the"forward path" also known as RCPT TO, if andonly if the forwarding MTA accepted theresponsibility for both forwarding the mail andreturning potential bounce messagesto the sender. RFC 821 and all later SMTPspecifications offer two result codes for thissituation:

251 user not local (attempted forward)
551 user not local (mail rejected)

For privacy reasons these result codes are todayrarely used, they include the forwarded to (251) ornot forwarded to (551) address. But the meaningand the effect of forwarding to third parties isidentical for result code 250 and error code 550respectively.

As noted RFC 1123 deprecated source routing, thatimplicitly also deprecated the reverse routing ofbounces. It was a relativelysmall Internet back in 1989, mail admins(postmasters) often knew each other and fixed problemson the fly. Routing bounce messagesback via any forwarders was a waste of time andbandwidth if the MTA noting a problem (e.g. arejection with a 5xx error code) could send theerror message directly back to the MX of sender.

Since RFC 1123 forwarders to third parties stillrewrote the RCPT TO address, but kept the MAILFROM as is. As a side-effect MTAs wishing toaccept mail from forwarders generally accept anyMAIL FROM address.

More than a decade later spammersstarted to abuse this flaw in post-1123 SMTP,today most mails are spam andmost "reverse paths" are forged. Note that
spammers typically forgeworking "reverse paths", many MTAs reject mailif callback verification or otherplausibility checks fail for the "reverse path".

RFC 2821 states that non-delivery reports( bounces ) must be sent tothe "originator" as"indicated in the reverse path" after an MTAaccepted the responsibility for delivery. This isa paradox in a world where the "indicated"Return-Path is typically forged. One wayto solve it is to reject suspicious mails,accepting responsibility only for mail fromtrustworthy sources.

Open relays and forwarders are in an unluckyposition with regards to this issue, generally they can'tguarantee that the MAIL FROM address indicatesthe "originator", and they also can't guaranteethat final delivery will succeed.

This SMTP problem caused as side-effect ofRFC 1123 is addressed by
SPF, and theexecutive summary is "SPF breaks forwarding" -actually that's not the case, SPF FAIL only asksreceivers to check SPF at their border MTA, notlater.

Receivers can arrange their forwarding in a waythat works with SPF with in essence threestrategies:

# not checking SPF behind their border, e.g. "white list" forwarders
# just reject SPF FAIL, resulting in a bounce (similar to SMTP error 551)
# rewrite the MAIL FROM at the forwarder (as done by mailing lists)

Sender Rewriting Scheme (SRS) is one way forthe third strategy.

See also

* Sender Policy Framework (SPF)
* Bounce message (SMTP non-delivery report)
* Bounce Address Tag Validation (BATV)
* Simple Mail Transfer Protocol (SMTP)

External links

* [http://www.libsrs2.org libsrs2 home page]
* [http://www.libsrs2.org/srs/srs.pdf Paper on SRS] (PDF)
* [http://www.openspf.org/svn/project/specs/drafts/draft-mengwong-sender-rewrite-01.txt Historical SRS draft] by Meng Weng Wong (2003)
* [http://opensource.mco2.net/qmail/srs/ qmail SRS patch]