Warining! Don’t Let Your Firm’s Spam Filter Prevent Electronic Case Noticing Infoworld.com reports: The trouble at Franklin D. Azar & Associates PC began with pornographic spam. via Legal Dockets Online Blog
Read More… (From Email Spam News)

Today is a special day at Microsoft, it is the three-year anniversary of the day I joined Frontbridge (now Microsoft Exchange Hosted Services) as a spam analyst. Ah, what a memorable three years it has been.

On our first day on the job, me and three others (the Fantastic Four) went down to Los Angeles for four weeks of training. We met the other lone spam analyst and we spent the next two weeks learning about spam and how to fight it and then the subsequent two weeks doing that over and over again before returning north to Canada.

I have processed a lot of spam in my time but for the first two years my main focus was false positives. I used to process about 90% of the FPs we saw and I became incredibly good at predicting which spam rules were going to perform well in the field and which ones were not. In those days, our spam team’s primary tricks of the trade were writing regular expression spam rules on the contents of the email message. I would process all of the false positives and then go on to spam. Whenever I came across a legitimate false positive (which wasn’t often) I could often look at the message and predict what part of the message was tagged as spam by our spam rules.

Some time passed and we added on another spam filtering service (component) which was automated. I was responsible for setting up the false positive process, and I became good at predicting what FPs were caused by this new component and which ones were caused by our spam rules. Time passed but the spam stayed the same. In those days, pornographic spam was one of the most common types of spam and obfuscation of words was the preferred filter-evasion technique. We saw image spam back then, but it always was embedded in a link.

In 2005, we continued to process spam but we started seeing some more foreign stuff (due to our customer base). Still, not much changed. We saw stock spam, pharmacy spam, 419s, and so forth. All the while I was still handling false positives.

In summer 2006, we saw a sudden shift in spam tactics. Image spam hit our networks. I had seen image spam before, spammers sometimes used it in their CAN-SPAM boilerplates in the footers of their messages. But, this was a new tactic for which we were ill-prepared. Spammers were inserting gif and jpg images into their spam messages and delivering mail that way. At the time, there was a new outbreak every week and I was working six days a week trying to handle all of this stuff. However, time passed, we got some new features implemented and the image spam problem started to drastically reduce. My own personal image spam rules have blocked over a billion messages since they were implemented back in September.

Time passed and 2007 has rolled around. There’s a new breed of spam floating around, pdf spam and “gift-card” spam (which isn’t new, but the payload to a virus is). I don’t process much spam anymore these days, but I still troll through our various inboxes to get a feel for what’s going on. Now, I am a Program Manager of (anti) spam effectiveness, which means I am in charge of collecting various measurements on our networks. Furthermore, the scope of my duties has greatly expanded in the past three months so now I have a great deal of influence into driving and defining new antispam features. In my opinion, this is a very natural progression because I felt that as a rule writer / spam analyst, I was getting close to the end of how far I could go and the logical next step was to move beyond spam rules. I had to become familiar with a whole variety of anti-spam techniques. This is not to say that we did not have techniques other than spam rules (far from it), but now I have a great deal of influence of reshaping the process of how we do it.

So, it’s been an interesting three years. Hopefully the next three are just as interesting.

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

Categories: Patch Watch , Hackers , Zero-day attacks , Apple , Microsoft , Windows Vista , Browsers , Rootkits , Vulnerability research , Responsible disclosure , Spam and Phishing , Spyware and Adware , … via ZDNet Blogs
Read More… (From Email Spam News)

“We’re pleased to engage with IceWEB in co-marketing our uniquely powerful solution that offers customers significant value by enabling them to dramatically reduce spam volumes, lower bandwidth expenditures, and reduce overall infrastructure costs.”

IceWEB Inc., www.iceWEB.com announced that the company has launched a joint marketing initiative with F5 Networks, which is designed to increase market awareness and sales of F5’s Message Security Module for … via Customer Interaction Solutions
Read More… (From Email Spam News)

“Customers appreciate the difference our all-fiber network brings by delivering faster speed, better reliability, more advanced services, and superior entertainment and online experiences.”

Verizon FiOS Internet was the only service to achieve top ratings in each of the survey’s nine categories: overall satisfaction, connection reliability, download speed, upload speed, customer service, technical … via TVover.net
Read More… (From Email Spam News)

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)

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)

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)

Moving onwards to mechanisms, let’s take a look at them in a bit more detail. Again, this information comes straight from the OpenSPF page, with extra commentary by me. The all mechanism all This mechanism always matches. It usually goes at the end of the SPF record.

Example 1 v=spf1 mx -all Allow the domain’s MXes to send mail for the domain, prohibit all others. Reading the syntax from left to right, the version of SPF is 1.0, return a pass if the sending IP is in the MX records for the domain, return a Fail on everything else. Note that the implied syntax is the following: v=spf1 +mx -all
Example 2 v=spf1 -all The domain sends no mail at all. Read left to right, the version of SPF is 1.0, return a Fail on everything (ie, if any IP has this domain name in the envelope sender, return a Hard Fail).
Example 3 v=spf1 +all A record like this defeats the purpose of SPF. To interpret it, the version of SPF is 1.0, return a pass on everything. If you are returning a pass on everything, it means that whatever IP is sending mail for your domain, you say that’s okay. That means any IP can forge your domain.

The ip4 mechanism

ip4:<ip4-address>ip4:<ip4-network>/<prefix-length>

The argument to the “ip4:” mechanism is an IPv4 network range. If no prefix-length is given, /32 is assumed (singling out an individual host address). This is one of the easier records to interpret.

Example 1"v=spf1 ip4:192.168.0.1/16 -all"Allow any IP address between 192.168.0.1 and 192.168.255.255. If the transmitting IP is not within this range, return a Hard Fail.

The ip6 mechanism

ip6:<ip6-address>ip6:<ip6-network>/<prefix-length>

The argument to the “ip6:” mechanism is an IPv6 network range. If no prefix-length is given, /128 is assumed (singling out an individual host address).

Example 1"v=spf1 ip6:1080::8:800:200C:417A/96 -all"Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF.
Example 2"v=spf1 ip6:1080::8:800:68.0.3.1/96 -all"Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF.

The a mechanism

aa/<prefix-length>a:<domain>a:<domain>/<prefix-length>

All the A records for the domain are tested. 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 a -allLookup the A-record of the current domain. If it matches the transmitting IP, return a Pass. If not, return a Fail.
Example 2v=spf1 a:example.com -allLookup the A-record of example.com. If it matches the transmitting IP, return a Pass. If not, return a Fail.
Example 3v=spf1 a:mailers.example.com -allExample.com has explicitly listed all of its outbound mailers in a special A-record under mailers.example.com. Lookup the A-record for mailers.example.com, and if the transmitting IP is found amoung them, return a Pass. If it is not, return a Fail.
Example 4v=spf1 a/24 a:offsite.example.com/24 -allThis SPF record lists two possible mailers, a/24 and a:offsite.example.com/24. Lookup the A-record of teh current domain and assume that it resolves to 192.0.2.1; the entire class C of 192.0.2.0/24 would be searched for the client IP. Similarly, assume that the A-record for offsite.example.com is 192.0.3.1. It would be expanded to 192.0.3.0/24 and would be searched for transmitting IP. If more than one A record were returned for the domain, each one would be expanded to a CIDR subnet.

If not match was no found, a Fail would be returned.

In my next post, we will get to the mx, ptr, exists and include mechanisms. Then, we will take a look at some real-life SPF records.
Read More… (From Terry Zink’s Anti-spam Blog)

This is essentially going to be a summary of the information that appears on the OpenSPF documentation web page. Really, what else can I say that isn’t said there? But, if you’re like me and rarely bother clicking on links inside of blog posts and would prefer to read it within the same web page you navigated to, then read on. For brevity’s sake I will split this into a couple of posts. In my previous posts, I’ve stated that SPF is a method of authentication where the receiving email host checks to see if the transmitting IP is allowed to send mail for the domain in the envelope sender. It’s actually a bit more complicated than that. In an SPF record, a domain defines zero or more mechanisms. Mechanisms can be used to describe the set of hosts which are designated outbound mailers for the domain in the envelope sender. all | ip4 | ip6 | a | mx | ptr | exists | include Domains may also define modifiers. Each modifier can appear only once. redirect | exp
Mechanisms Mechanisms can be prefixed with one of four qualifiers:

“+” Pass
“-” Hard Fail
“~” Soft Fail
“?” Neutral

If a mechanism results in a hit, its qualifier value is used. The default qualifier is “+“, i.e. “Pass”. If no mechanism or modifier matches, the default result is “Neutral”. Mechanisms are evaluated in order. If a domain has no SPF record at all, the result is “None”. If a domain has a temporary error during DNS processing, the result is “TempError” (called “Error” in earlier posts and earlier drafts of SPF). If some kind of syntax or evaluation error occurs (eg. the domain specifies an unrecognized mechanism) the result is “PermError” (formerly “Unknown”).
Sample SPF records Below are some examples of sample SPF records that a domain could publish using the syntax above. The first part, v=spf1, means that the version of SPF that the domain has set up for that record is SPF version 1.0. We will revisit how to interpret the rest of the line in subsequent posts.

"v=spf1 -all" "v=spf1 a -all" "v=spf1 a mx -all" "v=spf1 +a +mx -all"

Evaluation Evaluation of the SPF record can return any of these results: Result: Pass
Explanation: The SPF record designates the host to be allowed to send.
Intended action: Accept This is the type of action I like to see. This is useful when combined with safe senders as it means that the envelope sender that claims to have sent the mail really did send the mail. Result: Hard Fail
Explanation: The SPF record has designated the host as NOT being allowed to send.
Intended action: Reject In Exchange Hosted Services, we have custom delivery options for Hard Fails. If the customer chooses, we will auto-quarantine SPF Hard Fails. If they don’t opt-in, we add spam points more aggressively but do not automatically send it to spam quarantine. Result: Soft Fail
Explanation: The SPF record has designated the host as NOT being allowed to send but is in transition.
Intended action: Accept but mark In Exchange Hosted Services, we add spam points but not as aggressively as a Hard Fail. Result: None
Explanation: The domain does not have an SPF record or the SPF record does not evaluate to a result.
Intended action: Accept My own opinion on SPF None differs from OpenSPF. Rather than having the intended action as accept, I would treat it as “proceed, but we’re keeping an eye on you.” I say this because domains without SPF records are more easily exploited (spoofed). Result: Neutral
Explanation: The SPF record specifies explicitly that nothing can be said about validity.
Intended action: Accept My opinion on an SPF Neutral is similar to SPF None, but I would not be as suspicious. At least with SPF Neutral, the owner of the domain took the time to set up SPF records and explicitly stated “We neither confirm nor deny.” Result: PermError (Unknown)
Explanation: A permanent error has occured (eg. badly formatted SPF record).
Intended action: Unspecified My own opinion on this is the following: Come on, avoid syntax errors in your SPF records. Sheesh… On the other hand, maybe you’re a spammer and you’re doing it on purpose. Result: TempError (Error)
Explanation: A transient error has occured.
Intended action: Accept or Reject I’m not sure an reject is justified on this action. Errors can occur because of network hiccups so I wouldn’t reject it because of that. One thing I’d like to point out is that OpenSPF uses the term “Fail” where I say “Hard Fail.” We call it Hard Fail in our filters and I’ve gotten used to saying it that way. However, if I ever say SPF Fail, I mean an SPF Hard Fail and never a Soft Fail.
Read More… (From Terry Zink’s Anti-spam Blog)

Moving onwards to mechanisms, let’s take a look at them in a bit more detail. Again, this information comes straight from the OpenSPF page, with extra commentary by me. The all mechanism all This mechanism always matches. It usually goes at the end of the SPF record.

Example 1 v=spf1 mx -all Allow the domain’s MXes to send mail for the domain, prohibit all others. Reading the syntax from left to right, the version of SPF is 1.0, return a pass if the sending IP is in the MX records for the domain, return a Fail on everything else. Note that the implied syntax is the following: v=spf1 +mx -all
Example 2 v=spf1 -all The domain sends no mail at all. Read left to right, the version of SPF is 1.0, return a Fail on everything (ie, if any IP has this domain name in the envelope sender, return a Hard Fail).
Example 3 v=spf1 +all A record like this defeats the purpose of SPF. To interpret it, the version of SPF is 1.0, return a pass on everything. If you are returning a pass on everything, it means that whatever IP is sending mail for your domain, you say that’s okay. That means any IP can forge your domain.

The ip4 mechanism

ip4:<ip4-address>ip4:<ip4-network>/<prefix-length>

The argument to the “ip4:” mechanism is an IPv4 network range. If no prefix-length is given, /32 is assumed (singling out an individual host address). This is one of the easier records to interpret.

Example 1"v=spf1 ip4:192.168.0.1/16 -all"Allow any IP address between 192.168.0.1 and 192.168.255.255. If the transmitting IP is not within this range, return a Hard Fail.

The ip6 mechanism

ip6:<ip6-address>ip6:<ip6-network>/<prefix-length>

The argument to the “ip6:” mechanism is an IPv6 network range. If no prefix-length is given, /128 is assumed (singling out an individual host address).

Example 1"v=spf1 ip6:1080::8:800:200C:417A/96 -all"Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF.
Example 2"v=spf1 ip6:1080::8:800:68.0.3.1/96 -all"Allow any IPv6 address between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF.

The a mechanism

aa/<prefix-length>a:<domain>a:<domain>/<prefix-length>

All the A records for the domain are tested. 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 a -allLookup the A-record of the current domain. If it matches the transmitting IP, return a Pass. If not, return a Fail.
Example 2v=spf1 a:example.com -allLookup the A-record of example.com. If it matches the transmitting IP, return a Pass. If not, return a Fail.
Example 3v=spf1 a:mailers.example.com -allExample.com has explicitly listed all of its outbound mailers in a special A-record under mailers.example.com. Lookup the A-record for mailers.example.com, and if the transmitting IP is found amoung them, return a Pass. If it is not, return a Fail.
Example 4v=spf1 a/24 a:offsite.example.com/24 -allThis SPF record lists two possible mailers, a/24 and a:offsite.example.com/24. Lookup the A-record of teh current domain and assume that it resolves to 192.0.2.1; the entire class C of 192.0.2.0/24 would be searched for the client IP. Similarly, assume that the A-record for offsite.example.com is 192.0.3.1. It would be expanded to 192.0.3.0/24 and would be searched for transmitting IP. If more than one A record were returned for the domain, each one would be expanded to a CIDR subnet.

If not match was no found, a Fail would be returned.

In my next post, we will get to the mx, ptr, exists and include mechanisms, and then we will get to the modifiers. Finally, we will take a look at some real-life SPF records.
Read More… (From Terry Zink’s Anti-spam Blog)

With IBM’s free DB2 Express C database you get more for your money: Support for pure XML data not found in MySQL Support for production-strength deployment not found in Oracle 10g Express Edition Support for … via Small Business Computing
Read More… (From Email Spam News)

A study by Trend Micro suggests that corporate computer users have a cavalier attitude to IT security in the workplace. The study tracked responses from 1,200 corporate users across the US and UK.
Read More… (From Spam News)

I don’t know what’s going on, but every so often I get an email message in Microsoft Entourage that doesn’t have any message body, even though the person who sent it insists that they included a message. via Ask Dave Taylor!
Read More… (From Email Spam News)

A new round of greeting-card spam that draws users to visit attack sites relies on a sophisticated multipronged, multiexploit attack to infect machines.
Read More… (From Spam News)

OK, here’s one for the books. Spammer Bill Stanley created businesses called DefamationAction.com and ComplaintRemover.com which are and I’m not making this up “reputation services” dedicated to helping clients clear their good names by removing defamatory information about them from the internet.

Well, it ended about as well as you would expect. Stanley’s methods apparently consist of putting up defamatory web pages about, and making death threats to, web sites that won’t remove material his clients object to. For example, he sent this message to RipOffReport’s owner, Ed Magedson:

This letter is being sent to you in the name of more than 500 businesses. No matter where you go, we will cause you a problem. Your life is in danger until you comply with our demands. This is your last warning. …

Stanley has also targeted Magedson’s lawyers and business providers.

On May 11, an Arizona judge issued a restraining order against Stanley and others in the reputation services business. Needless to say, Stanley ignored the restraining order, leading to more unpleasantness in court on June 21.

For the full story, including much longer excerpts from Stanley’s death threats, visit c|net article Police Blotter: Dark side of ‘reputation defending’ service.
Read More… (From The Spam Diaries)

I first wrote about Scoble, then the Microsoft Blogger Enfant Terrible back in 2004 or something. Maybe even earlier. But he was the breath of fresh air the company needed at the time. Now the ‘markets are naked conversations’ thing…
Read More… (From loose wire blog)