|< Day Day Up >|| |
Sender Policy FrameWork (SPF), now known as Sender ID, is a new technology currently being developed by a joint venture between Microsoft and Meng Weng Wong (the founder of pobox.com). Originally dubbed SPF when released by Meng Weng Wong in May 2004 (the full SPF spec draft can be read at www.ietf.org/internet-drafts/draft-mengwong-spf-01.txt), it was later adapted and merged into a similar Microsoft-developed methodology called Caller-ID and then the new combined effort was renamed Sender ID.
The fundamental idea behind SPF is to hold the host accountable for the e-mail it sends. If a host should not be sending e-mail for a particular domain, the e-mail is discarded as spam. Accountability comes in the form of an SPF record assigned to a particular mail domain. When e-mail is delivered to another mail server the receiving server checks the SPF record online to make sure that the sending host is the correct host for that particular domain.
This example shows the flow of a message through an SPF filter:
Spambox.spammerx.com (22.214.171.124) sends email@example.com an email, the recipient address of the email is firstname.lastname@example.org Coolmail.com receives the email destined for user joe and checks the SPF record for cia.gov, to see if the sender is allowed to say it is from cia.gov. According to the SPF record, cia.gov should only send mail from 126.96.36.199 (relay7.ucia.gov). This mail did not really come from cia.gov and is fraudulent in its nature, deleted.
If spammerx.com had a valid SPF record published listing 188.8.131.52 (spambox.spammerx.com) as the mail host for all of spammerx.com e-mails and the e-mail’s recipient address was email@example.com, the mail would be delivered successfully to firstname.lastname@example.org. Although SPF is very simple in nature, it offers a very effective catch rate on spam. The only way spam can evade an SPF filter is for the recipient to hold a valid SPF record and be truthful about what domain they are coming from. A recent study conducted by CipherTrust (www.ciphertrust.com) found that, after checking two million e-mails sent to CipherTrust customers between May and July 2004, 5 percent of all incoming mail had published SPF records. However, within that 5 percent over 50 percent contained spam. Spammers are faster at adopting technology than the rest of the world; most spam is sent from hosts with legitimate SPF records. CipherTrust’s study went on to say that spam messages are three times more likely to pass an SPF record check than to fail. This shows that although the host is known for sending spam, the SPF record is not being actively tagged invalid, thereby keeping the record legitimate.
At the time of this writing, SPF/Sender ID is still in the design process. There is no clear protocol draft at the Internet Engineering Task Force (IETF), and the current implementations are just test-bed solutions. This is probably why so much spam is currently evading the SPF system; there is nothing in place to stop a host once it is known as sending spam. This fault is due to the implementation of SPF, not SPF itself.
Perhaps once several million dollars are invested in the idea of SPF/Sender ID all spam will end, but at this time, it is far from the end.
Naturally, SPF has some obvious advantages. The strict rules of accountability will inhibit any dubious host trying to send e-mail or forge its whereabouts. Hosts such as a cable modem in China that belong to part of a Botnet will have a higher filtering rate depending on the settings of the SPF implementation. Worms and viruses will be significantly hindered during their propagation stage, since the majority of malicious content is spread via e-mail. If you were to drop all e-mail that did not have a valid SPF record, you could catch the majority of virus-carrying e-mail. Banks and other critical financial organizations could use SPF as a method of verifying that e-mail originated from their networks in an attempt to squash out phishing spams (fraudulent spam, where the recipient is tricked into disclosing sensitive bank account information).
Spammers who make a living from spam are much harder to catch with SPF-based rules. I don’t believe SPF offers adequate protection against experienced spammers. Although SPF has the potential to be highly efficient against inexperienced spammers or spammers who don’t have the time or knowledge to be SPF-compliant, it is too easy to look legitimate on the Internet, especially when using countries like Russia or China to send from; the recipient has no idea of the host’s true validity.
Microsoft’s Sender ID technology is fast losing support. Recently, AOL announced that they will not be supporting the encumbered system and instead will look at using the original SPF specification.
“AOL has serious technical concerns that Sender ID appears not to be fully, backwardly-compatible with the original SPF specification—a result of recent changes to the protocol and a wholesale change from what was first envisioned in the original Sender ID plan,” Nicholas Graham, AOL
Looking legitimate proves its worth when trying to evade SPF-based filters. The only way to beat SPF is to join it and look like you belong to it. For example: A spammer decides he wants to set up an SPF-based spam-sending server. He rents a dedicated spam host at a spam-friendly Chinese-based network provider. Next, he registers 100 domain names, each totally random (domains can cost as little as $5 to $10 each, so there is a relatively small set-up cost). Each domain is registered under a fake name and address. The spammer installs and runs an instance of Berkeley Internet Name Domain (BIND [a DNS daemon]) on the Chinese server and uses it to serve all DNS information for the 100 domains. Next, DNS entries for each of the hosts are set up, including a valid pointer record (PTR), a mail exchange (MX), and reverse DNS entry for each domain. Next, a self-published SPF record is appended to each domain’s DNS entry, identifying the host as a valid, self-created SPF host that is responsible for any e-mail coming from its domain. An example for spammerx.com would b v=spf1 mx ptr a:spambox.spammerx.com.
If we break down this string you can see what an SPF entry consists of. V=spf1 identifies the text-based entry as the entry that contains the SPF record. MX defines that any host listed as an MX host for the domain (such as mx1.spammerx.com) is authorized to send e-mail. PTR furthers the filter by also allowing any host ending in spammerx.com to send e-mail, such as spambox2.spammerx.com. And finally, a:spambox.spammerx.com is a static entry that defines spambox.spammerx.com as a specific host that is authorized to say they are sending e-mail on behalf of spammerx.com.
From this point, a spammer can begin sending large volumes of spam from each domain, acting as legitimate and truthful as possible. For example, using the correct corresponding SPF domain name in the message HELO will keep everything looking kosher and SPF compliant.
|Notes from the Underground…|| |
One of the biggest failures of SPF/Sender ID is the lack of external verification. If an SPF-compliant host sends millions of spam messages daily, its SPF record will never be invalidated. Each host effectively controls its own validity. Client-based technology is never a good basis for security.
What SPF/Sender ID needs is an external third party that is responsible for hosting validity records and making sure that the host deserves an SPF; the equivalent of what VeriSign does for SSL. When a host is found to be sending spam, the record is revoked or marked as invalid. This information could be further gathered by collecting statistics from distributed spam filters such as DCC, Razor, and Pyzor, that could inform a central host about SPF entries that are notorious spammers.
An approach including a small level of bureaucracy would act as a deterrent to any spammer thinking about registering 100 SPF records, since each host would require a new form or contract that would cost the spammer time and money. No one likes the idea of having to register so many hosts if paperwork is required, especially if the SPF records were marked invalid after the first spam run.
The majority of spam filters will treat the e-mail with a higher level of legitimacy because the sender’s domain has a valid SPF entry and is fully accountable for the e-mail it sends. However, due to the number of spammers using SPF-compliant hosts, Spam Assassin will only give a message a -0.001 score if the host domain contains a valid SPF record; a very low amount of legitimacy considering the host is fully accountable for all e-mail. SPF is already losing momentum and the protocol draft has not yet been completed or approved. It has even been suggested that Microsoft’s proposed Sender ID format be abandoned (www.imc.org/ietf-mxcomp/mail-archive/msg03995.html).
SPF entries open up the possibility of having an insecure SPF host.
For example: If mail.host1.com had a valid SPF record but that SPF record allowed “anyone” to claim they were sending e-mail on behalf of mail.host1.com, the SPF record is effectively pointless. However, the record will still seem legitimate and act as a valid SPF record.
This can also be targeted by spammers when sending e-mail from other hosts. If a spammer sets up an SPF record to allow the entire net block of China, Korea, and Japan to be authorized to send e-mail and then sends spam from proxy servers located in those countries, SPF is bypassed while still looking highly legitimate.
|< Day Day Up >|| |