On Sun, 6 Jun 2004, Seth Goodman wrote:
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
This is not true. You are not "vulnerable" if all forwarders don't adopt
it. SPF will simply reject some mails.
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
SUBMITTER does not do end to end verification either. Neither does SES.
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
This is simply not true. Nowhere is there a document describing why this
is or how it will work. SUBMITTER is just as hop-to-hop as SPF/SRS. SES
leaves you vulnerable to replay attacks.
advantages. It is already in the RFC's, so that streamlines the
RSP is in the RFCs as a syntax, but the semantics are entirely ignored.
This means that you become silently vulnerable to SPF checks being
mis-performed against the domain, not the RSP.
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.
SUBMITTER clearly has no advantages over RSP. RSP is end-to-end while
SUBMITTER is not. However, RSP is
* Silently ignored if it's even supported
* Spoofed at will since it has no cryptographic protection
* Probably not supported by anyone who restricts to 64 byte local parts
* Not inspected by SPF systems in the field.
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.
This is also simply not true. SPF/SRS protects you from forged bounce spam
(joe jobs), as originally intended. What it does not protect you from is
MTAs sending you mail directly using <> as a source. Neither does SES.
A major disadvantage of these schemes is the lack of any clear description
of SES or SUBMITTER explaining in clear language how it is supposed to be
used and how it prevents joe jobs and forged bounce spam.
The statements made here are entirely unjustified by any form of
documentation, illustration or analysis. SES is a fundamentally weak
system and does not achieve the objectives it claims to achieve. When a
coherent document appears on the web describing a single set of semantics
and protocols for it, I will explain in more detail why this is. Right
now, I feel that I'm trying to justify statements about a target that
moves as fast as Labour party policy after the general election.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/