In reply to my original question:
RS> I am a subscriber to the on-line Security UPDATE newletter
RS> <Security-UPDATE(_at_)list(_dot_)winnetmag(_dot_)com> and have just sent
the message below
RS> to the editors for comment.
RS> I would like to ask the same question to this discussion group - is there
RS> some way for spammers to circumvent the SPF solution short of
hijacking the
RS> DNS or mailservers for a domain?
Chris Wrote:
Spam flows nowdays from zombies, proxies, temporary subscriber
accounts, and a few open servers (hereafter "sender equipment") - so
here's how the spammers need to adapt in the post-SPF world:
1. Their "sender equipment" needs to detect if SPF is in use when
originating an email (a TXT lookup)
If not - no change - pick any random sender, and submit the spam
If so - either...
A) Pick another fake domain to send from instead, and go back to
step 1, or
B) Implement their own SPF on their spam domain and send anyhow,
or
C) Figure out what domain their "zombie" is running from, and if
that domain supports SPF, then spoof random senders from this
domain. (eg: [HKEY_USERS\...\Software\Microsoft\Internet
Account Manager\Accounts\00000001\SMTP Email Address]
You're missing an important point though. SPF is *NOT* an anti-spam
technology. It's got practically nothing to do with spam, and it
won't have any noticeable effect it.
I have a few comments in reply:
1. I have been using Spam Assassin at a number of our customer sites for
some time. Assigning appropriate scores to senders or relayers that appear
on several of the reliable "blacklists" allows me to improve the spam
rejection percentages to more than 90%. These blacklists function primarily
on the IP address information available from the SMTP connection used to
deliver the message (some also look in the header for realying addresses
but, these of course, could be forged).
2. If the use of SPF was widespread, I could verify the "claimed" domain of
the sender against the IP addresses of valid mail handlers for that domain.
If they don't agree, I could add a significant value to the spam score. If
they do agree, I would probably add a negative score (like some do for
habeas certified senders). If enough domains implemented SPF, I would
probably add a bit to the score of any message where the sender domain did
not have an SPF record. This process should definitely increase the overall
spam scores for most of the spam that I see (where the claimed domain of
the sender bears no relationship to the IP address of the server that
delivered the message). Using this procedure, I would identify SPF as a
significant anti-spam tool.
3. If I used the scoring mechanism I described above, I don't understand
how any of the adaptations listed in Chris' reply above would defeat the
process.
In order to avoid a hefty addition to the spam score, the sender would have
to use a valid domain in the From: address and would need to send the spam
from an SPF verifed mail server for that domain.
The spammers could "hijack" the DNS for any domain and send their junk off
with any return address they want. This should not be an easy task to carry
out for any nameservers that are properly managed.
The spammers could register a domain, supply an SPF record in the DNS and
send out their junk. However, registering a domain involves some
traceability and the anti-spam oriented Internet community should be able
to establish a mechanism for identifying the offending domains and either
publishing them in standard RBL lists or arranging for the DNS references
to those domains to be removed from the ROOT nameservers.
Another method would involve sending the spam from an ISP's mailserver to
which they have access, using a return address that corresponds to a domain
whose DNS is managed by the ISP and contains an SPF reference to the IPS's
mailserver. This would still involve traceability since the ISP should know
the exact identity of the customer who sent the spam from their mailserver.
Again I ask - am I missing something about the way SPF can be used to fight
spam ?
Roy C. Snell (rsnell(_at_)trilan(_dot_)com)
President
Tri-Lan Internetwork Ltd
Victoria, British Columbia, Canada
Tel : (250) 477-0104