From: Michael R. Brumm
Sent: Friday, June 04, 2004 5:48 AM
Michael R. Brumm wrote:
SRS:
ugly
not exploitable
requires upgrading only the MTAs which forward
SUBMITTER:
pretty
bounce forgery is exploitable
requires upgrading ALL MTA which want to receive a forward
(much larger pool)
Stuart D. Gathman wrote:
Resurrecting Deprecated Reverse Source Path:
pretty
bounce forgery is exploitable (fixable with SES, btw. See
suggestion for validating SES via DNS instead of CBV.)
requires upgrading (or downgrading :-) only the MTAs which forward
Seth Goodman wrote:
Absolutely. This is already in the RFC's, it won't break any MTA's that
don't implement the protocol and it requires no new ESMTP
parameters. This
really seems like a pretty obvious choice.
Ok, anyone got anything written up on various implications of
resurrecting reverse source path for use with SPF?
Not yet, but here's a start:
1) RFC2821 requires that SMTP-servers accept and ignore the deprecated
reverse source route format from RFC821. MTA's MUST ignore the routing
information and use only the rightmost field as MAIL FROM:.
2) Since MTA's must accept and ignore this format, using it to pass the
SUBMITTER information will not break any existing MTA that is RFC2821
compliant.
3) Forwarders may prepend their domain and retain the whole routing path, or
they may first delete the old routes and then prepend their domain. This
would lead to shorter MAIL FROM: strings. In the case of an originator and
three forwarders, all of the following are valid MAIL FROM: addresses:
MAIL FROM:<@fwd3,@fwd2,@fwd1:local-part(_at_)originator>
MAIL FROM:<@fwd3,@fwd2:local-part(_at_)originator>
MAIL FROM:<@fwd3:local-part(_at_)originator>
MAIL FROM:<@fwd3,@fwd1:local-part(_at_)originator>
4) Recipients always use the leftmost field of MAIL FROM: to do the SPF
check. This is always the current sender.
5) The source route information does not count against the 64-character
limit for the local-part of the originating address.
6) Bounces are sent directly to the originating address (the rightmost field
in MAIL FROM:). To protect themselves from null-sender forgeries, senders
SHOULD implement SES signing of all outgoing messages.
And, if you need to add SES to reverse source path to prevent
bounce forgery, then why not just use SRS?
SRS is something that forwarders implement. As such it does not give the
sender any protection from null-sender forgeries unless the mail goes
through a forwarder that implements SRS. Recipient systems also have to
maintain whitelists of forwarders that don't use SRS so their mail will be
delivered.
In contrast, SES signing of all outgoing mail gives the sending domain
complete protection against null-sender forgeries regardless of what anyone
else does. No special action is required by forwarders and no whitelists
are needed at the sender.
Since SES is based on the SRS format, it has a similar computational load to
SRS. Because SES only contains the originating address and not a forwarding
address, more characters are available for the local-part of the originating
address.
--
Seth Goodman