From: Shevek
Sent: Sunday, June 06, 2004 1:14 PM
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.
If some forged bounces get through, you are vulnerable.
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.
Since I never made that claim for SES used as a forged bounce protection
tool and Meng never made that claim for SUBMITTER, we agree.
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.
We discussed the specifics of replay attacks at great length, and the result
was that it is largely a non-issue.
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.
That is entirely dependent on the code that implements SPF. SPF checks can
be performed wrong in all kinds of ways with disastrous results. If the
implementation is good, there is no reason to expect that there will be any
more problems with reverse source route than SUBMITTER or SRS.
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
By the existing MTA functions, not necessarily by the SPF implementation on
the MTA.
* Spoofed at will since it has no cryptographic protection
SUBMITTER has no cryptographic protection because it doesn't need any. It
is the current sender and you do an SPF check to make sure their IP is a
designated sender for their domain. Once it passes SPF and PRA matches, it
has no further purpose.
* Probably not supported by anyone who restricts to 64 byte local parts
The reverse source route is not part of the local-part of the address.
* Not inspected by SPF systems in the field.
That is true, but neither is SUBMITTER nor PRA. If we are going to do what
Meng has proposed, clearly SPF implementations will have to change.
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.
SES absolutely protects you against null-sender forgeries. As part of the
merged SPF-CID proposal, that is it's only purpose.
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.
Though the details are in flux, the basic ideas have been discussed at
length on this forum and on the IRC channel (which you were logged in to
during the original discussion). As far as I can tell, the basic ideas
haven't changed at all. Meng and others have described the basic operation,
before and after a flag day, for SPF with a purported responsible sender
field (SUBMITTER/RFROM/FRED/DAVE/reverse source route) in concert with PRA
extraction after DATA. If you want to take issue with the basic protocol,
please respond to one of those posts.
As far as SES goes, it is recommended as part of the merged proposal
specifically to prevent forged bounce spam and nothing more. The format has
been the same for a long time and is a minor simplification of SRS0:
MAIL FROM:<SES0=HHHH=TT=local-part(_at_)domain>
It is used by the sender to reject forged bounces. Upon receiving a
null-sender message, the MX examines the RCPT TO: argument and rejects on
any of the following: not an SES signed address, timestamp expired, address
not a valid local address or hash does not verify. Just like SRS, the final
gateway MTA should strip the crypto information and only use
local-part(_at_)domain for the Return-Path: header.
As for your political comment, I am not a Brit, so it is a waste of a
perfectly good insult :)
--
Seth Goodman