| Sender Rewriting Scheme |
Article Index for Sender |
Shopping Scheme |
Website Links For Sender |
Information AboutSender Rewriting Scheme |
| CATEGORIES ABOUT SENDER REWRITING SCHEME | |
| e-mail authentication | |
|
Sender Rewriting Scheme (SRS) is designed to make it possible for E-mail forwarders to be compatible with Sender Policy Framework . 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 MAIL FROM, 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 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:<not-for-mail@other.example> # MAIL FROM:<@news.server.example:not-for-mail@other.example> 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 Return-Path header field: Return-Path:<@news.server.example:not-for-mail@other.example> SMTP uses MX Record s for its forward routing. Explicit source routes as in... RCPT TO:<@news.server.example:user@destination.example> ...to route mail from other.example via MTA news.server.example to MDA destination.example were cumbersome. To make things worse sometimes the ''new'' (1982) style of addresses was mixed with old 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 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 List s, 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 2821 obsoleted 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 RCPT TO, 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: 251 user not local (attempted forward) 551 user not local (mail rejected) For privacy reasons these result codes are today rarely used, they include the forwarded to (251) or not forwarded to (551) address. But the meaning and the effect of forwarding to third parties is identical for result code 250 and error code 550 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 RCPT TO address, but kept the MAIL FROM as is. As a side-effect MTAs wishing to accept mail from forwarders generally accept any MAIL FROM 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 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. This is a Paradox in a world where the ''indicated'' Return-Path is typically forged. One way to solve it is to reject suspicious mails, accepting responsibility only for mail from trustworthy sources. Open Relay s and forwarders are in an unlucky position with regards to this issue, generally they can't guarantee that the MAIL FROM 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, SPF FAIL 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: # 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 for the third strategy. SEE ALSO
EXTERNAL LINKS
|
|
|