From: Michael R. Brumm
Sent: Saturday, June 05, 2004 4:13 PM
Michael R. Brumm wrote:
-SRS is ONLY required by forwarders (not senders or receivers), and
extensions to SMTP are NOT needed.
-SUBMITTER is required by forwarders AND receivers, and an
extension to SMTP
is needed. And, worst of all, bounces can be forged.
Stuart D. Gathman wrote:
-RSP (Reverse Source Path) is ONLY required by forwarders, and
extensions to SMTP are NOT needed.
You left out the fact that RSP also allows injections of forged bounces.
No, we have been saying this for a very long time. This has nothing to do
with reverse source route and everything to do with how SPF operates.
Forged bounce spam has been a weakness of SPF since the beginning. SRS is
one solution, but unless _all_ forwarders adopt it, you are still
vulnerable. SES works without anyone else adopting anything and you get the
benefits from the day you start using it.
The basic problem stems from the fact that SPF does hop-to-hop verification
as opposed to end-to-end verification. As such, it is vulnerable to forging
an originator address unless you take some additional measures. SRS is one
possible solution to these problems. I is complicated, but it would work if
universally adopted. Quite a few people feel that it is completely
unrealistic to expect that _all_ forwarders will adopt SRS and thus they
will never get complete protection from forged bounce spam. This was the
impetus for proposing SES. In fact, there is nothing incompatible between
SES and SRS. SES signed mail can also survive SRS rewriting, should any
forwarder decide they really want to do that. Meng apparently decided,
after getting feedback from enough third parties, that SRS was a significant
adoption barrier to SPF. He then proposed using SUBMITTER instead if SRS
and recommended that senders use SES to prevent forged bounce spam.
SES+SUBMITTER is an equivalent solution to SRS. Reverse source route is a
direct functional equivalent to SUBMITTER, but with a couple of practical
advantages. It is already in the RFC's, so that streamlines the
specification process. It also doesn't break legacy systems, which is a
very important feature for phased adoption. In fact, it doesn't even
require ESMTP. Since there is nothing that SUBMITTER does that reverse
source route does not, this looks like a fairly solid argument to use
reverse source route and forget about SUBMITTER. If you can think of any
disadvantages, please list them so we can discuss it.
Like SUBMITTER, in order to prevent injections of forged bounces,
you have to add some type of signing on the sender (often SES is
proposed) to detect them. So SRS still wins because it only
requires modifications to the forwarders.
SRS does not protect you from forged bounce spam, so I wouldn't call that a
win. Senders use an unsigned MAIL FROM: and therefore cannot distinguish
forged bounce spam from a real DSN.
--
Seth Goodman