spf-discuss
[Top] [All Lists]

SES - what exactly is it and what is it supposed to do?

2004-06-06 16:26:42
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!

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.

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. 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.

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.

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,}/

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.

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.

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.

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.

S.

-- 
Shevek                                    http://www.anarres.org/
I am the Borg.                         http://www.gothnicity.org/