On Tue, 2004-09-14 at 14:36 +0200, Claus Färber wrote:
This observation raises an important question: Why should building a
database based on a 'trust key' reduce spam?
The most obvious 'trust key' is the IP address of the sending MTA.
Databases based on the IP address have already been built and are in
production use. They do reduce spam but there is still a lot of spam
that gets through.
If Sender ID/SPF just changes the key from 'IP address' to something
else, then I don't see how it can reduce spam UNLESS spammers can't
change that key as easily as IP addresses. With domain-based keys, this
is not the case: It's actually easier to register a throw-away domain
name than to get a new block of IP addresses.
Well, IP address-based databases have some problems on their own, which
may or may not have hindered deployment (e.g. the server behind a DSL
`dialup'' line). But SPF has similar problems.
All this is true, but people still seem to rabidly want SPF/SenderID.
Partly I think this stems from a lack of realisation that in the
presence of SRS or the Resent-From:^WForwarded-For: header addition, SPF
and SenderID are still only capable of providing a way of determining
who claims to be responsible for the individual mail server in question,
rather than being a true end-to-end validation that the mail in question
really did come from the user from whom it claims to come.
But partly it does make some sense. Databases based on IP addresses are
not entirely perfect, and some improvement could be obtained by using an
alternative 'trust key' to identify the party responsible for the server
in question. Not only can the problem of false positives and false
negatives due to dynamic IP be avoided, but by using a key which covers
_groups_ of servers, such as a domain name or the signer of a TLS
certificate, we get to reduce the size of the database dramatically.
What does _not_ make sense is to allow people to think that the use of a
'domain name' as the key actually gives any secure indication that the
mail really did come from the domain it claims to come from. There are
other groups working on such end-to-end authentication, and that is an
orthogonal issue. Or at least it _should_ be; but some people seem
confused.
--
dwmw2