On Tue, 2004-09-14 at 11:29 -0700, Douglas Otis wrote:
I'm more interested in knowing that example.com is accountable for mail sent
in its name. I can deal with whether example.com is worthy or not later.
Neither Sender-ID nor SPF provide an identity that will allow this later
reputation to be safely established.
Right.
When example.com sends mail using a EHLO name of mx.example.com, this
is not much different than example.com using a MAIL FROM domain of
rp.example.com.
Indeed. It's just an arbitrary key into some form of trust database now
-- just some identification handle for the 'entity' which claims to take
responsibility for the mail server or group of mail servers in question.
For that matter, the From mailbox domain does not need to match the
identity checked for either Sender-ID and SPF.
This is a very important point. We're _not_ verifying the From: header
or indeed anything which the user is actually going to see. It _doesn't_
help stop your muppet users from clicking on the link and entering all
their bank details. You'd need an end-to-end solution for that, not a
hop-by-hop solution which permits me to send:
MAIL FROM:<SRS0+x+y+bigbank(_dot_)com+admin(_at_)mydomain(_dot_)org>
From: admin(_at_)bigbank(_dot_)com
To: sucker(_at_)darwinwaswrong(_dot_)com
Forwarded-For: sucker(_at_)mydomain(_dot_)org
Please enter your details <A HREF="...>here</A>
It's _only_ about how much you trust the individual mail server which is
actually offering the mail. You can't really tell, in the interesting
cases, if the mail actually was generated by the purported author whose
address is given in the From: header.
Even if it comes _directly_ from an IP address which is listed as
permitted for the domain -- if it comes from a port above 1023 it could
have been from _anyone_ with access to that box. Even in the absence of
forwarding, the mailfrom/pra-replacement scopes aren't sufficient for
real authentication.
Compare and contrast with real end-to-end solutions such as PGP, or the
scheme I operate to sign outgoing MAIL FROM: rather than ever using MAIL
FROM:<dwmw2(_at_)infradead(_dot_)org>. If you get a mail which is signed by my
PGP
key, or on which the return-path is an address of the form
SRS0+x+y+infradead(_dot_)org+dwmw2(_at_)x(_dot_)srs(_dot_)infradead(_dot_)org
and to which address my
servers actually accept bounces, then you have a _very_ good chance it
actually came from me.
SenderID has its place -- in determining a 'responsible entity' for mail
servers which are submitting mail, and hence allowing some level of
trust to be determined. But let's not kid ourselves that it's a
replacement for a true method of proving that the mail really did come
from where it claims to come from.
This makes EHLO no different. Using EHLO does protect customers from
lax providers. Making the authenticated EHLO visible would also
greatly help reduce phishing. EHLO offers consumer protections that
Sender-ID had only promised but without many of the risks.
Right. Almost _any_ alternative lookup key would suffice, as long as a
sending host can be provably associated with the entity which is
represented by the key. HELO works, the signatures on TLS certs also
work -- and I'm sure there are many more. Most of which could be used
without all the breakage and the changes to existing practice which the
mailfrom and pra-replacement scopes would require, and without the
potential IPR problems. Let's explore those alternatives some more.
--
dwmw2