Subject: RE: [Accountability!] RE: SPF abused by spammers

From: "Gordon Fecyk" <[email-masked]>
Date: Tue, 14 Sep 2004 09:12:39 -0500

> That's the point -- it's a hop-by-hop scheme. It's _all_ 
> about how much
> you trust the one mail server which is sending you mail. 
> Where before we
> had IP-based blacklists, now there are domain-based 
> blacklists, without
> which SPF/SenderID is largely not useful.

I would live with domain based blacklisting.  It's easier to manage currently
than IP based blacklisting, until reputation services start to take hold or
other measures could apply to domains - named entities - instead of numbers.

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.

-- 
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email-masked]>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>

---

From: David Woodhouse <[email-masked]>
Date: Tue, 14 Sep 2004 18:08:54 +0100

On Tue, 2004-09-14 at 09:12 -0500, Gordon Fecyk wrote:
> in its name. 

But for that you need an end-to-end scheme. What you're talking about
now is only sufficient to determine the status of _one_ hop. Suppose you
receive a message with...

	MAIL FROM:<[email-masked]>
and
	Received: from [2002:c1ed:8229:10:2c0:f0ff:fe31:e18] (helo=me) by
	        pentafluge.infradead.org with esmtpsa id 1C7Ej2-0008II-SZ;
		Tue, 14 Sep 2004 15:56:09 +0100
	From: <[email-masked]>
	Forwarded-For: [email-masked]

	(Note I don't use Resent-From: as an example since no reason
	 has been presented for using it instead of a new header. I
	 picked 'Forwarded-For' mostly at random).

... from one of my servers. The mail obviously appears as if it were
originally sent by <[email-masked]>, with authenticated SMTP
('esmtpsa') through my server. Certainly there are people who use my
servers that way, because I listen on the MSA port as well as port 25,
and some ISPs block port 25.

But was it _really_ sent by [email-masked]? You have no way of
knowing, because this is _not_ an end-to-end validation scheme. You can
only decide how much you trust _my_ servers.

Note that most current mail user agents will display only the 'From:'
header in the above example; the naïve user will see nothing to indicate
that this might not actually be from [email-masked].

By introducing the rewriting schemes which modify the RFC2821 and
RFC2822 identities, which is _required_ for SenderID to be viable in
practice, we have turned the 'domain' into nothing more than an
arbitrary key which can be selected by each sending mail server. There's
nothing _wrong_ with that per se -- at least if we make the naïve
assumption that we can get the whole world to 'upgrade' -- but it's
unrealistic to pretend that SenderID will let you verify for certain
that such a mail really did come from Joe. 

SenderID can offer only validation of a single hop, and to get any real
benefit it needs to be used in conjunction with a trust-database using
domain names as its key. And there are _better_ things you could use as
a key in your database, without all the breakage that either the
mailfrom or pra-replacement scopes require.

-- 
dwmw2

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Sep 2004 11:29:44 -0700

On Tue, 2004-09-14 at 07:12, Gordon Fecyk wrote:
> > That's the point -- it's a hop-by-hop scheme. It's _all_ about how
> > much you trust the one mail server which is sending you mail. Where
> > before we had IP-based blacklists, now there are domain-based 
> > blacklists, without which SPF/SenderID is largely not useful.
> 

Neither Sender-ID nor SPF provide an identity that will allow this later
reputation to be safely established.  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.  For that
matter, the From mailbox domain does not need to match the identity
checked for either Sender-ID and SPF.  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.

-Doug

---

From: David Woodhouse <[email-masked]>
Date: Tue, 14 Sep 2004 22:45:12 +0100

On Tue, 2004-09-14 at 11:29 -0700, Douglas Otis wrote:
> 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:<[email-masked]>
	From: [email-masked]
	To: [email-masked]
	Forwarded-For: [email-masked]

	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:<[email-masked]>. If you get a mail which is signed by my PGP
key, or on which the return-path is an address of the form
[email-masked] 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