Now that we’ve plowed our way through SPF, including the syntax (I can’t believe I took the time to do it, but if I ever go into a university and have to teach it I guess I should know it), let’s take a look at some real life examples of domains that publish SPF records and try to interpret them.

Example 1 - Frontbridge

Let’s start with Frontbridge, the antispam company that Microsoft bought in July 2005. Their SPF record is the following:

“v=spf1 ip4:64.56.194.142 ip4:64.56.194.146 include:spf.frontbridge.com -all”

The version of SPF is 1.0, and the IPs that are permitted to send mail are 64.56.194.142, 64.56.194.146 and then we have the SPF record spf.frontbridge.com. The SPF record for spf.frontbridge.com is the following:

“v=spf1 include:spfa.frontbridge.com include:spfb.frontbridge.com -all”

Not content to make this example easy, we have another include directive. Looking up the SPF records for spfa.frontbridge.com, we get the following:

“v=spf1 ip4:12.129.199.32/27 ip4:206.16.192.224/27 ip4:216.148.222.32/27 ip4:63.161.60.0/25 ip4:207.46.163.0/24 ip4:12.129.219.64/26 ip4:62.209.45.160/27 ip4:213.199.154.0/25 ip4:217.117.146.224/27 ip4:12.129.219.152/29 ip4:65.55.251.0/26 -all”

For spfb.frontbridge.com:

“v=spf1 ip4:131.107.0.0/16 ip4:12.129.219.128/27 ip4:12.129.20.19 ip4:207.46.51.64/26 ip4:213.199.154.0/25 -all”

So, the only IPs permitted to send mail as frontbridge.com are the ones above. If an IP is not in any of the above IPs, return a Hard Fail.

Example 2 - The Motley Fool

My next example is The Motley Fool, a financial website. I’ve subscribed to The Motley Fool for a number of years and some of the articles are alright. Their SPF record is below:

“v=spf1 a mx ip4:74.8.50.0/24 ip4:64.94.26.0/24 ip4:64.94.27.0/24 ip4:69.25.30.0/24 ip4:212.36.33.0/24 ~all”

This is simpler. To interpret it, the version of SPF is 1.0. The IPs allowed to send mail are the A-record, the MX-record, and all of the rest of the IPs that are mentioned. The A-record of The Motley Fool is 64.94.26.1, the mx-records of fool.com are 74.8.50.182 and 74.8.50.183. If the IP is in any of those ranges, return a Pass. If not, return a Soft Fail.

Example 3 - Yahoo

The following is Yahoo’s SPF record:

” “

That’s not a typo, Yahoo does not publish SPF records so there’s nothing to authenticate. Yahoo uses DomainKeys, which is another method of email authentication. I guess they think that because it’s such a good method they are not going to bother publishing SPF records (they need to support the home team and no one else).

That’s one way of looking at. Of course, the drawbacks to this would be that spam filtering services that don’t use DomainKeys to authenticate but do use SPF will treat any email from Yahoo as suspicious, since spammers (historically) have spoofed Yahoo.

Example 4 - Gmail

Our next example is Gmail. The SPF record for Gmail is the following:

“v=spf1 redirect=_spf.google.com”

I didn’t look into this modifier in my explanation of the syntax of SPF, but it means that the SPF record for _spf.google.com replaces the record for gmail.com. For _spf.google.com:

“v=spf1 ip4:216.239.32.0/19 ip4:64.233.160.0/19 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ip4:74.125.0.0/16 ?all”

Again, this one is relatively easy to interpret. If the transmitting IP is claiming to be coming from Gmail, the IP must be within any of the ranges mentioned above. But what is interesting is if it doesn’t, the result is SPF Neutral. What’s up with that? Why wouldn’t Google explicitly state which IPs they authorize to transmit mail? While I don’t know for sure, I think it is because Google also uses DomainKeys, which is another form of email authentication. Still, it’s a little annoying that they would be so ambiguous as to be Neutral, rather than a Soft Fail. I could see it if they didn’t explicitly control google.com, but they do. So why the need for ambiguity?

It’s only speculation on my part. There’s probably something simple I am overlooking.

Example 5 - Hotmail

Finally, let’s have a look at Hotmail.

“v=spf1 include:spf-a.hotmail.com include:spf-b.hotmail.com include:spf-c.hotmail.com include:spf-d.hotmail.com ~all”

The version of SPF is 1.0. It has the include directive for spf-[abcd].hotmail.com, which means that all of those domains are searched for a match. If no match is found among them, return a Soft Fail.

Let’s look up the SPF record for spf-a.hotmail.com:

“v=spf1 ip4:209.240.192.0/19 ip4:65.52.0.0/14 ip4:131.107.0.0/16 ip4:157.54.0.0/15 ip4:157.56.0.0/14 ip4:157.60.0.0/16 ip4:167.220.0.0/16 ip4:204.79.135.0/24 ip4:204.79.188.0/24 ip4:204.79.252.0/24 ip4:207.46.0.0/16 ip4:199.2.137.0/24 ~all”

Obviously, I picked a winner here by selecting an example with a huge number of IPs. Let’s interpret this; the version of SPF is 1.0, the IPs permitted to send mail for spf-a.hotmail.com are 204.240.192.0/24 - 204.240.224.0/24 (if I did my math right), expanding all the way to the end of range. If the sending IP is not in this range, return a Soft Fail. However, we don’t return a Soft Fail because of spf-[abcd].hotmail.com, we return it because the SPF record for hotmail.com says to return the Soft Fail.

Read More… (From Terry Zink’s Anti-spam Blog)

“This latest step in the Commission’s anti-spam initiative is intended to protect investors from fraud artists who would treat the investing public as their personal ATM machines”

A Katy man faces organized crime charges in connection with an alleged scheme to sell worthless stocks over the Internet, according to the Texas Attorney General’s Office. via Houston Chronicle
Read More… (From Email Spam News)

The mx mechanism

mxmx/<prefix-length>mx:<domain>mx:<domain>/<prefix-length>

All the A records for all the MX records for domain are tested in order of MX priority. If the client IP is found among them, this mechanism matches.

If domain is not specified, the current-domain is used.

The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.

Example 1

"v=spf1 mx mx:deferrals.domain.com -all"

Check the mx record of the domain in the envelope sender. Also check the mx-record of deferrals.domain.com, which looks like it is another set of servers whose job is to retry mail for deferring domains. In any case, if the transmitting IP is found among those A-records, return a Pass. Otherwise, return a Fail.

Example 2

"v=spf1 mx/24 mx:offsite.domain.com/24 -all"

Check the mx-record of the current domain and expand it to its /24 CIDR range, and do the same thing with offsite.domain.com (expand it to its /24 CIDR range). If the transmitting IP is found in the ranges, return a Pass. Otherwise, return a Fail.

The ptr mechanism 

ptrptr:<domain>

The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches.

If domain is not specified, the current-domain is used.

If at all possible, this mechanism should be avoided because it will result in a larger number of expensive DNS lookups.

Example 1

"v=spf1 ptr -all"

If this SPF record is specied, we would typically see it in a domain which directly controls all its machines (unlike a dialup or broadband ISP) and allows all its servers to send mail. For example, hotmail.com or paypal.com might do this.

Suppose that the transmitting IP is 4.8.15.16 and the envelope sender is me@lost.com. The process works as follows:

- The receving mail agent looks up the SPF record for lost.com and sees that it is the above.
- The hostnames for 4.8.15.16 are discovered to be lost.com (acquired by a reverse DNS lookup), island.lost.com and others.lost.com.
- The A-record for lost.com is 4.8.15.13, island.lost.com is 4.8.15.15, and others.lost.com is 4.8.15.16. The last one matches the original IP. If none had matched, then the result would have returned a Fail.
- Note that since the envelope domain is lost.com and the reverse DNS all included lost.com, this also constituted a match.

Example 2

"v=spf1 ptr:otherdomain.com -all"

Any server whose hostname ends in otherdomain.com is designated to send mail and returns a pass. Otherwise, return a fail.

The exists mechanism 

exists:<domain>

Perform an A query on the provided domain. If a result is found, this constitutes a match. It doesn’t matter what the lookup result is it could be 127.0.0.2.

Example 1

In the following example, the client IP is 16.23.42.108 and the current-domain is lost.com.

"v=spf1 exists:example.net -all"

If example.net does not resolve, the result is Fail. If it does resolve, this mechanism results in a match.

The include mechanism 

include:<domain>

The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.

Example 1

In the following example, the transmitting IP is 4.8.15.16 and the current-domain is lost.com.

"v=spf1 include:lost.net -all"

If lost.net has no SPF record, the result is PermError.

Suppose lost.nets SPF record were “v=spf1 a -all”.

Look up the A record for lost.net. If it matches 4.8.15.16, return Pass. If there is no match, the include as a whole fails to match, but the -all value is not used (from lost.net’s SPF record); the eventual result is still Fail from the outer directive set in this example, in this case lost.com.

Note that only the evaluated result of the referenced SPF record is used but its action is not. The action in the outer directive is what is used. In the above, if the SPFrecord for lost.com was the following “v=spf1 include:lost.net ~all”, then lost.net would still return a Hard Fail, but the overall SPF result would be a Soft Fail.

Furthermore, care is needed to ensure that “include:” mechanisms do not place domains at risk for giving SPF Pass results to messages that result from cross user forgery. Unless technical mechanisms are in place at the specified other domain to prevent cross user forgery, “include:” mechanisms should give a Neutral rather than Pass result. This is done by adding “?” in front of “include:“. The example above would be:

"v=spf1 ?include:lost.net -all"

This way, even if the lost.net SPF checks out, we still give it a Neutral because there could be some forging going on. We neither confirm nor deny the result of the cross-domain checking.

Read More… (From Terry Zink’s Anti-spam Blog)

I recently gave a talk at Google recently entitled “Drive-By Pharming and other WebSec Bummers.” I talk about the previously publicized drive-by pharming attack, and also other related web 2.0 issues, giving an overview of what we think the problem boils down to.

Read More… (From Stop-Phishing @ IU)

One of the things that makes stock spam so hard to fight is that it’s easy for the spammers to disassociate themselves from their messages. They don’t need to give out a telephone number, an email address or the name of a website. They just need to send out the name of a stock that they’re interested in and hope someone will buy. In theory, you might try to correlate spam campaigns with trading activity and identify the interested parties that way, but that’s slow and complex, and the evidence tends to be circumstantial at best. For this reason, the identities of the big stock spammers are still mostly a mystery.
Read More… (From Spamnation)

Federal regulators filed civil fraud charges Monday against two Houston-area men, accusing them of hijacking personal computers to send out spam e-mails and bilk investors out of $4.6 million. Separately, state and local authorities announced indictments charging Darrel T. Uselton and his uncle, Jack E. Uselton, with engaging in organized criminal activity and money laundering.
Read More… (From Spam News)

MX Lab warns for messages with “PayPal E-TAN” in the subject. These messages are not send by PayPal and is containing attached malware. The piece of code called E-TAN Software_2.68.zip is actually a so-called “downloader” and will download and install other pieces of mallware on your computer. Be aware of this dangerous message.
Read More… (From Email Spam News)

“The US used to be the dominant player in spam but when legislation was brought in many US spammers moved offshore”

Posted by Mike Slocombe on 9 July 2007 at 12:45 pm Tagged as: Web , Business The US found itself sitting right at the top of the Irish spam charts for June 2007, according to e-mail security statistics from … via Digital-Lifestyles
Read More… (From Email Spam News)

The mx mechanism

mxmx/<prefix-length>mx:<domain>mx:<domain>/<prefix-length>

All the A records for all the MX records for domain are tested in order of MX priority. If the client IP is found among them, this mechanism matches. If domain is not specified, the current-domain is used. The A records have to match the client IP exactly, unless a prefix-length is provided, in which case each IP address returned by the A lookup will be expanded to its corresponding CIDR prefix, and the client IP will be sought within that subnet.

Example 1 "v=spf1 mx mx:deferrals.domain.com -all" Check the mx record of the domain in the envelope sender. Also check the mx-record of deferrals.domain.com, which looks like it is another set of servers whose job is to retry mail for deferring domains. In any case, if the transmitting IP is found among those A-records, return a Pass. Otherwise, return a Fail.
Example 2 "v=spf1 mx/24 mx:offsite.domain.com/24 -all" Check the mx-record of the current domain and expand it to its /24 CIDR range, and do the same thing with offsite.domain.com (expand it to its /24 CIDR range). If the transmitting IP is found in the ranges, return a Pass. Otherwise, return a Fail.

The ptr mechanism 

ptrptr:<domain>

The hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP. Invalid hostnames are discarded. If a valid hostname ends in domain, this mechanism matches. If domain is not specified, the current-domain is used. If at all possible, this mechanism should be avoided because it will result in a larger number of expensive DNS lookups.

Example 1 "v=spf1 ptr -all" If this SPF record is specied, we would typically see it in a domain which directly controls all its machines (unlike a dialup or broadband ISP) and allows all its servers to send mail. For example, hotmail.com or paypal.com might do this.

Suppose that the transmitting IP is 4.8.15.16 and the envelope sender is me@lost.com. The process works as follows:- The receving mail agent looks up the SPF record for lost.com and sees that it is the above.
- The hostnames for 4.8.15.16 are discovered to be lost.com (acquired by a reverse DNS lookup), island.lost.com and others.lost.com.
- The A-record for lost.com is 4.8.15.13, island.lost.com is 4.8.15.15, and others.lost.com is 4.8.15.16. The last one matches the original IP. If none had matched, then the result would have returned a Fail.
- Note that since the envelope domain is lost.com and the reverse DNS all included lost.com, this also constituted a match.
Example 2

"v=spf1 ptr:otherdomain.com -all" Any server whose hostname ends in otherdomain.com is designated to send mail and returns a pass. Otherwise, return a fail.

The exists mechanism 

exists:<domain>

Perform an A query on the provided domain. If a result is found, this constitutes a match. It doesn’t matter what the lookup result is it could be 127.0.0.2.

Example 1 In the following example, the client IP is 16.23.42.108 and the current-domain is lost.com. "v=spf1 exists:example.net -all" If example.net does not resolve, the result is Fail. If it does resolve, this mechanism results in a match.

The include mechanism 

include:<domain>

The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.

Example 1 In the following example, the transmitting IP is 4.8.15.16 and the current-domain is lost.com. "v=spf1 include:lost.net -all" If lost.net has no SPF record, the result is PermError. Suppose lost.nets SPF record were “v=spf1 a -all”.

Look up the A record for lost.net. If it matches 4.8.15.16, return Pass. If there is no match, the include as a whole fails to match, but the -all value is not used (from lost.net’s SPF record); the eventual result is still Fail from the outer directive set in this example, in this case lost.com.

Note that only the evaluated result of the referenced SPF record is used but its action is not. The action in the outer directive is what is used. In the above, if the SPFrecord for lost.com was the following “v=spf1 include:lost.net ~all”, then lost.net would still return a Hard Fail, but the overall SPF result would be a Soft Fail. Furthermore, care is needed to ensure that “include:” mechanisms do not place domains at risk for giving SPF Pass results to messages that result from cross user forgery. Unless technical mechanisms are in place at the specified other domain to prevent cross user forgery, “include:” mechanisms should give a Neutral rather than Pass result. This is done by adding “?” in front of “include:“. The example above would be: "v=spf1 ?include:lost.net -all" This way, even if the lost.net SPF checks out, we still give it a Neutral because there could be some forging going on. We neither confirm nor deny the result of the cross-domain checking.
Read More… (From Terry Zink’s Anti-spam Blog)

Spamhaus, the well known organisation against spam, is ‘promoted’ in a spam message. This is one of the strategies that spammers use to place this anti spam organisation in discredit.

WORKING TO PROTECT INTERNET NETWORKS WORLDWIDE Spamhaus tracks the Internet’s Spammers, Spam Gangs and Spam Services, provides dependable realtime anti-spam protection for Internet networks, and works with Law Enforcement to identify and pursue spammers worldwide. The SBL database is maintained by a dedicated international Spamhaus team based in 9 countries, working 24 hours a day, 7 days a week to list new confirmed spam issues and - just as importantly - to delist resolved issues. The Spamhaus Exploits Block List (XBL) is a realtime database of IP addresses of illegal 3rd party exploits, including open proxies (HTTP, socks, AnalogX, wingate, etc), worms/viruses with built-in spam engines, and other types of trojan-horse exploits. The Exploits Block List can be used by all modern mail servers, by setting your mail server’s anti-spam DNSBL feature (sometimes called “Blacklist DNS Servers” or “RBL servers”) to query xbl.spamhaus.org. Use of the XBL is free for users with normal mail servers (but networks with high email traffic should see DataFeed). You can get MUCH MORE if you contact us: The Spamhaus Project Ltd. 18 Avenue Louis Casai, CH-1Geneva, Switzerland, Tel +41225330399

Read More… (From Email Spam News)