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.
I've posted previously about concerns about false positives for people who
don't use a dedicated MTA or at least a shared MTA the will not permit users
to use domain names other than those for which they are authorized. If you
substitute "That domain is a domain that lists an MTA the spammer has gotten
access to in its SPF record" for "That domain is a throwaway,
just-registered domain" I think it encapsulates my concern fairly well.
If we are doing "Unified SPF" and checking the HELO/EHLO of the MTA to see
if it is lying about who it is, there is a slightly modified approach that
both makes the transition to domain based blacklisting easier and reduces
the risks of shared MTA users being blacklisted due to a false positive.
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).
Note that if an MTA gets put on the blacklist and then taken off to many
times (yes, I confess, someone spammed from my MTA), their reputation will
suffer.
This approach has a few advantages going for it:
1. Builds from the current IP based blacklisting of the MTA to blacklisting
the MTA domain name too and then to the sender domain. People will be able
to follow this progression stepwise with lower perceived risk.
2. Focuses the blacklisting on the organizations least likely to have throw
away domains and most likely to have a reputation to protect (the MTA
owner). Should have more impact on making it harder for spammers to find
real MTAs to send through.
3. Protects small domain owners (like me I'll confess) from the risk of
being blacklisted by a false positive. Today I have ?include:verizon.net in
my SPF record. If this type of approach were recommended I'd be comfortable
using +include:verizon.net. As I've said in previous posts, I trust
Verizon, it's their other customers I don't trust. With this approach "Do
you trust your MTA provider" actually means something. All I have to do to
protect my domain from blacklisting is use permitted senders that use a FQDN
in their HELO/EHLO and publish SPF records for their MTAs (which Verizon
would have to do before I would "Trust" them).
4. Makes publishing SPF records for your MTA a competitive advantage for
non-spammer hosts.
The only disadvantage I can see is that it would slow down blacklisting of
the domains that the spam is being sent from.
I think that there would be more SPF PASS results and fewer false positives
with this approach. That would increase the value of SPF and also increase
the value of domain based blacklists.
Scott Kitterman