On Sun, 6 Jun 2004, Seth Goodman wrote:
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.
Agreed. But no forged bounces ever get through. So you aren't vulnerable.
Please, READ and UNDERSTAND the protocol! It's published, clearly
described, with many scenarios at http://www.libsrs2.org/srs/srs.pdf
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.
Then the paragraph in your original mail is misleading.
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.
heh. When people start using signed SES address as a source for spam,
tunes will change very rapidly, and there will be much, much regret.
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
So is MAIL FROM.
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.
That wasn't what I said. I said that anyone who doesn't supprort >64 byte
local parts will probably not support RSP.
* 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.
SUBMITTER and PRA are also both bad ideas which achieve as little as 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.
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
[SNIP]
Please write a web page so we have a complete, coherent, non-moving,
non-distributed target to discuss. (And please, write it in plain, clear,
readable language, don't wrap it up in all the garbage the RFCs are
written in. RFCs are unreadable nowadays.) Please put all the content in
one place, rather than referring to "he said" "she said", because that
doesn't increase the credibility of the protocol.
Don't get me wrong, I think SES has value. I also think it can be
implemented perfectly well by doing SRS on the first step, rather than
introducing a new format to the world. I would advocate it in this format.
However, I think it's being severely mis-marketed as a replacement for
SRS, as a tool to stop phishing, and as a magic bullet for just about
every other problem mentioned on this list.
S.
--
Shevek http://www.anarres.org/
I am the Borg. http://www.gothnicity.org/