Sender Rewriting Scheme
Sender Rewriting Scheme (SRS) is designed tomake it possible for
e-mail forwarders to be compatible with
Sender Policy Framework.
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 a
Path 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:#
MAIL FROM:<@news.server.example:not-for-mail@other.example>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 known
Return-Path header field:
Return-Path:<@news.server.example:not-for-mail@other.example>
SMTP uses
MX records for its forward routing.Explicit source routes as in...
RCPT TO:<@news.server.example:user@destination.example>
...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!user@news.server.example other.example!not-for-mail@news.server.example
...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
call back 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
indicatedReturn-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.
*
Sender Policy Framework (SPF)
*
Bounce message (SMTP non-delivery report)
*
Bounce Address Tag Validation (BATV)
*
Simple Mail Transfer Protocol (SMTP)
*
libsrs2 home page*
Paper on SRS (PDF)
*
Historical SRS draft by
Meng Weng Wong (2003)
