On Tue, 2004-09-14 at 09:12 -0500, 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.
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.
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:<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=me) by
pentafluge.infradead.org with esmtpsa id 1C7Ej2-0008II-SZ;
Tue, 14 Sep 2004 15:56:09 +0100
From: <joeuser(_at_)example(_dot_)com>
Forwarded-For: joeuser(_at_)joeuser(_dot_)srs(_dot_)infradead(_dot_)org
(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 <joeuser(_at_)example(_dot_)com>, 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 joeuser(_at_)example(_dot_)com? 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 joeuser(_at_)example(_dot_)com(_dot_)
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