On Wed, 2004-09-15 at 15:10 -0500, Seth Goodman wrote:
SPF is hop-by-hop authentication and cannot tell you anything about
any site prior to the present SMTP client. You simply have to trust the
present SMTP client, if you choose to accept this limitation.
Right. It provides nothing more than hop-by-hop authentication. So let's
embrace that and use something other than the domain name as the
identifier by which we assign trust to each hop. We can still use some
kind of verifyable grouping of domains to identify a responsible party
-- like signatures on a TLS certificate, or some SPF-like checking of
the HELO greeting. But to tie it to the reverse-path is misleading.
This gigantic loophole can be closed by using an adjunct protocol along with
SPF that does end-to-end validation of forwards. SES is one such protocol.
The combination of SPF + SES gives you what SPF was designed for in the
first place: confidence in the authenticity of the domain in the
return-path and immunity from joe-jobs.
Actually SES does that all by itself -- they're not really related. SPF
with the 'exists' mechanism just happens to give you one possible method
of implementing the signature checking for SES. Others just use SMTP
sender verification callbacks -- and have already 'magically' stopped
accepting mail which pretends to be from me.
Keep in mind that every hop-by-hop authentication scheme has similar
weaknesses. The only way to be sure of the originating domain for a message
in the presence of intermediate hosts to use an end-to-end protocol.
Yes, but people out there for reasons which aren't entirely clear to me
seem to _want_ a hop-by-hop scheme. I don't understand that, but I'm
just trying to get them to settle on a variant which isn't easily
mistaken by the naïve part-time sysadmin for a true end-to-end
authentication method, and in particular which doesn't have all the
problems that the classic variant of SPF does (in particular the
requirement for ubiquitous deployment of something like SRS).
--
dwmw2