From: Shevek
Sent: Sunday, June 06, 2004 6:27 PM
On Sun, 6 Jun 2004, Seth Goodman wrote:
From: Shevek
Sent: Sunday, June 06, 2004 4:56 PM
On Sun, 6 Jun 2004, Seth Goodman wrote:
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.
Hang on, SPF inspects MAIL FROM!
Yes, but when MAIL FROM:<>, it uses the FQDN from the HELO string as the
domain to query the SPF record and test the SMTP-client against. As long as
the SMTP-client uses a HELO string that will result in an SPF PASS, any SPF
recipient would accept the message. Am I missing something?
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.
In exactly the same way they get any email address. If we knew this or
could prevent it, we'd have a good handle on the spam problem. You cannot
assume that an email address floating around the public internet
will stay
private for long.
I think we do know something about this. Current sources are mailing list
archives, USENET postings, entering email addresses on registration forms on
web sites, giving email addresses on product registration forms, signing up
for newsletters, giving your email address to your bank, etc. However, all
of these use unsigned addresses and will continue that way.
I argue that the only way a spammer can get a signed return-path is if you
send him one directly. Legitimate MTA's will strip the signature part
before prepending the Return-Path: header. Even if a few of them don't,
your legitimate correspondents would not go posting the headers from a
private message on a newsgroup. Most people don't even know how to view the
full headers.
Now, if you implement the trick of using an extended precision timestamp
that acts as a personal message ID, you can tell who gave up your signed
address and make their miserable lives truly miserable. I think this
scenario would be largely self-correcting because of the traceability.
Three base-32 digits representing fractional days gives you 2.6 second
resolution. That should be more than adequate to assure unique timestamps
per message for individual users and doesn't cost much in terms of
local-part length. I think this would be a useful addition and if we make
it part of the standard, it will always be there, regardless of bad local
policy choices.
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.
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
RFCs don't drive the process. How many people do you think actually read
an RFC when they want to understand a protocol.
Most people with normal intelligence.
All I'm asking for is a
single clear coherent explanation of what SES is and what it is supposed
to do. This shouldn't be hard.
It isn't hard and I think I've already done that, several times actually.
and criticism for a long time. The details do change rapidly,
but not the
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
This isn't true. SRS is merely a format for rewriting addresses. When you
apply it is largely up to you, although the paper on SRS explains where
you can apply SRS (or, indeed, any form of rewriting) without introducing
weaknesses into the system.
Fair enough.
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
"many people" =~ /(Seth Goodman){1,}/
Sorry, that's a misrepresentation. Look at the archives.
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
I have responded repeatedly. I have even published a response on the web
site. SES is fine, you can do it if you want, but it solves a
very limited
problem, and noone is quite clear about what that problem is.
That's interesting, as your current paper flatly states:
"Signed Envelope Sender, or SES, was originally proposed around
http://archives.listbox.
com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200402/0901.html. It doesn't
work."
That's quite an analytical coup, considering you just stated that you don't
know what problem it is trying to solve. I'm also impressed by the depth of
the analysis. Good work.
As I have said probably a dozen times, SES allows domains to reject forged
null-sender messages, otherwise commonly known as forged bounce spam. Now
that you know what problem it purports to solve, perhaps you could redo that
careful and exhaustive analysis in your paper?
creating a third format, but would be more practical for the intended
We need a third format like we need a third leg. It doesn't add anything.
It adds just the capability needed to reject forged null sender messages
without the extra overhead or SRS0.
purpose. It would also allow you to distinguish an original
message from a
forwarded one before DATA.
Why do you care whether a message has been forwarded or not? All that
matters is whether there is at least one cryptographic layer before the
user inbox. This is why there are SRS0 and SRS1 formats. The SRS0 is the
irremovable layer before the user inbox. By keeping the SRS format for
SES, we permit SES MSAs and SRS MTAs to interoperate. Otherwise, as you
say, we have yet another format, and another half dozen interop cases to
deal with.
Sorry if you find that a burden. We don't need the overhead of SRS0 and
frankly, given the response to Meng's quick poll, I don't think a lot of
people will be using SRS at all. If you want SRS to have a chance, it would
be a good idea to build in support for SES.
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.
No-one appears to be able to describe what SES is, what it does or how it
does it in any coherent, centralised form. Your continued references to
"people said", "Meng said", and so forth are becoming tiresome.
There is a
distinct lack of information about this protocol, and even you
haven't yet
clearly defined what you believe it does.
How many times do I have to describe it?
Please read the list.
--
Seth Goodman