From: Shevek
Sent: Sunday, June 06, 2004 4:56 PM
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
MAIL FROM:<>
RCPT TO:<user(_at_)domain>
This will be accepted as long as the SMTP-client sending it uses a HELO
string that results in an SPF PASS for their IP. You can identify the
perpetrator after the fact, but wouldn't it be better to just reject before
DATA? I suppose it depends on how you like to spend your on-line time,
adjusting spam filters and reporting spammers or reading your email.
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.
I mis-typed that line, and I thank you for bringing it to my attention. It
should have read,
"Since I never made that claim for SES used as an end-to-end verification
tool and Meng never made that claim for SUBMITTER, we agree."
I think your previous sentence I was responding to makes it clear this was a
typo, and I appreciate that you brought it up. I obviously do make the
claim that SES protects against forged bounces.
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.
Just how will spammers get these SES-signed addresses to use? Since this is
of central importance, please be specific.
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.
Only under SRS or other return-path rewriting schemes. Current practice and
the RFC's are that MAIL FROM: is the address that DSN's are to be sent to
and are the message originator. That is one of the objections to SRS: it
changes the nature of SMTP to a degree that people are not comfortable with,
at least not yet.
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.
Sorry, I misunderstood. How many commercial MTA's do you know of to date
that don't support local-parts longer than 64-bytes? I believe from
previous posts that the answer is one.
* 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.
Thank you for the feedback.
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.
Good grief, we are not at a University. RFC's drive the process, not pretty
position papers. The ideas have been on this list available for discussion
and criticism for a long time. The details do change rapidly, but not the
central ideas. If you believe that no debate or discussion should take
place without formal presentations, by all means, keep on waiting. Meng has
recommended, not required, that MTA's implement SES to give them protection
from forged bounce spam. That is all it is currently proposed for. Please
stop making claims to the contrary.
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.
Unfortunately, the rest of SRS comes along with that format, and that's what
people have objected to. I do think this would have been an improvement to
SRS. It was suggested by many people and got absolutely no response from
you. It would have been especially helpful if you had removed the
requirement to put in the source domain name twice. This would have meant
creating a third format, but would be more practical for the intended
purpose. It would also allow you to distinguish an original message from a
forwarded one before DATA.
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.
No one can answer an unsupported statement such as this.
--
Seth Goodman