From: spf(_at_)kitterman(_dot_)com
Sent: Friday, July 02, 2004 11:29 AM
This is based on both ideas I've had and stuff I've been reading on the
MARID list...
In the SPF FAQ there is a description of how SPF can help fight SPAM with
"fast automated blacklisting". There is also a discussion about
reputation
services.
http://spf.pobox.com/faq.html#churn
Here is the description of blacklisting:
1. A spammer spams.
* The spam comes from an SPF-conformant domain.
o That domain is on a widely published sender-domain
blacklist.
+ The MTA rejects the message.
o That domain is a throwaway, just-registered domain, and
does not yet
appear on blacklists.
1. The spam gets accepted by unsophisticated
MTAs which
do not use
other traffic-analysis methods to impose a crude
reputation
system on unrecognized senders.
2. The spam also gets accepted by automated
spamtraps.
3. The spamtraps add the domain to the blacklist.
4. (advanced) Some time later, the user checks email.
Immediately
before the display phase, the MUA re-tests the
message against
the blacklists, and discards it.
5. Thanks to the greater level of sender
accountability, lawsuits
may begin against the spammers, and registrars may
be subpoenaed
for domain owner information.
<...>
If we change:
2. The spam also gets accepted by automated spamtraps.
3. The spamtraps add the domain to the blacklist.
to:
2. The spam also gets accepted by automated spamtraps.
3a. If HELO/EHLO is a FQDN, the spamtraps add the HELO/EHLO domain to the
blacklist (the MTA is the actual source of the spam and so must
be guilty in
some manner). If the HELO/EHLO domain is not SPF compliant, add the
HELO/EHLO IP address (as is done now) and the sending domain too. If the
HELO/EHLO domain is SPF compliant, add the IP address and the HELO/EHLO
domain to the blacklist, but not the sending domain.
3b. If HELO/EHLO is not a FQDN, add the sending domain to the blacklist.
3c. The only way the HELO/EHLO domain gets off the blacklist is to finger
the sender (Yes, the user that sent the spam was an authorized sender for
the sender domain - put them on the blacklist and take me off or no that
user wasn't authorized to use that domain and we've cancelled his
account).
Don't you think that rather than go through all this effort at creating a
distributed, fine-grained RHSBL with the explicit goal of protecting small
domain owners whose ISP's do not have adequate controls on their MTA's, it
might be easier to simply _require_ providers to support SMTP AUTH _and_ to
limit the From: and Sender: addresses to the login address? We can then go
back to regular old DNSBL's that we already have and everybody is protected.
I understand that technology is cool, but we shouldn't necessarily do
something just because we can.
--
Seth Goodman