On Wed, 2004-09-15 at 13:07 -0400, Rik van Riel wrote:
On Wed, 15 Sep 2004, David Woodhouse wrote:
The example which really interests me is #1. Forgive me, I'll repeat it:
MAIL
FROM:<SRS0+xx+yy+example(_dot_)com+joeuser(_at_)pentafluge(_dot_)srs(_dot_)infradead(_dot_)org>
and
Received: from [2002:c1ed:8229:10:2c0:f0ff:fe31:e18]
(helo=joeslaptop)
by pentafluge.infradead.org with esmtpsa id 1C7Ej2-0008II-SZ;
Tue, 14 Sep 2004 15:56:09 +0100
From: <joeuser(_at_)example(_dot_)com>
Now who can tell me if this really came from Joe or not?
How can we even tell whether it really came from example.com at all ?
You can't -- the question is _purely_ 'how much do you trust my mail
server pentafluge.infradead.org?'
Unless I overlook some big things, it would appear to me that SRS
could just be the perfect forgery mechanism ...
Right. The 'domain' being checked is no more than an arbitrary cookie
provided by the sending mail server. And it's only really useful for
checking on how much you trust the owner of that mail server.
Pretending that it's actually tied to the _sender_ of the mail is
unrealistic. SPF is broken without SRS, because forwarding breaks -- and
SRS turns SPF into simply a question of how much you trust the one mail
server which is actually sending you the mail on the final hop.
The same goes for the SenderID scope based on RFC2822 headers. It ends
up _only_ giving you some handle to work out how much you trust the
sending mail host by looking it up in some database or
blacklist/whitelist.
There are better things we could use as an identifier in such a database
-- many people already use the IP address but that has problems with
dynamic IP addresses as we know. We could use the signature on a TLS
certificate, or we could use the HELO name, or maybe SUBMITTER or one of
_many_ other such arbitrary lookup keys, none of which would require all
the breakage that SPF does.
--
dwmw2