On Tue, 2 Nov 2004, wayne wrote:
In
<Pine(_dot_)LNX(_dot_)4(_dot_)44(_dot_)0411021552230(_dot_)14800-100000(_at_)sokol(_dot_)elan(_dot_)net>
"william(at)elan.net" <william(_at_)elan(_dot_)net> writes:
As subject says I'd like to know if SRS has ever been published as
Internet Draft and if not why not and is there plans to do it soon?
Shevek and I have are working on one, but I've been sidetracked and
dropped the ball.
The reason I ask is that I wanted to create something like BCP document
for forwarders which summarizes the ideas and technical details that are
explained in various other documents (RFC3461, spf, responsible-submitter,
emailredirection-traceheaders, etc) and makes it easy (with full examples)
for authors of MTA software to see what they need to do. But after thinking
about I thought it might be better idea instead reference SRS from the
SUBMITTER draft.
The way I see that they can work together is that forwarder MTA (or MRA
as I call it now) would check if the next SMTP server supports SUBMITTER
(i.e. SMTP server advertises that ESMTP extension) and if it does not
it would rewrite MAIL FROM with SRS and send its submitter information
that way (which next server if it supports SPF would authenticate against
and it would pass) while if next system supports SUBMITTER then it is
not necessary to do SRS and system can just send new submitter information
with new extension (which SPF system can then use to whitelist the
forwarder).
The reason for doing it this way is that SRS as Meng wrote couple times
before is "ugly" and I don't think IETF will like it by itself (no more
so then reusing TXT records) at the same time SUBMITTER only works if
everyone supports this extension, but this way we present it in the way
that in the future when SUBMITTER is widely used it can replace SRS while
SRS remains as a way to support current and legacy SMTP base (i.e. same way
TXT records are used while we move to SPF record type in the future).
This does require some change to how SPF currently works and to SRS and to
SUBMITTER. As far as SRS it means that for multiple forwarders the 2nd
one would not do SRS rewriting and will just replace original forwarder's
domain with its own but would keep same local part (which is MAIL FROM
rewritten by SRS by first forwarder). As far as SPF it means SUBMITTER is
now used for SPF verification if its present and if its not then MAIL-FROM.
As far as changes to SUBMITTER it means that SUBMITTER should be used
with MAIL command only if its address is different the actual MAIL FROM.
I would like to know what people think about this (which to me appears to
be close to original vision Meng had when he started working with Microsoft
or at least as far as I understood it when he first explained it) and its
still 100% SMTP session verification of the address of person/entity
responsible for previous hop of SMTP transmission.
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/