After a two month long pilot of SPF checks on the inbound mail server, these have been removed. Despite being successful in further minimizing the incidence of spam that leaked through, a few high profile domains were terribly misconfigured resulting in false positives (legitimate mail being rejected for violating a SPF record). I saw everything from multiple SPF records, new SPF syntax directives, to even null terminators (officelive.com. 3600 IN TXT "v=spf1 include:hotmail.com ~all\000")… this isn’t a string in a C, folks.
Because shared hosting is such a high entropy environment, there is no surefire way to know that only a particular class of e-mail may come in, i.e. corporate messages or messages between a handful of companies. We all use our business and personal accounts for a variety of reasons and because of which, it’s impossible to directly communicate with everyone who may have an error in their published SPF records preventing delivery.

The two biggest culprits that prompted the change were Office Live and Capital One, both very prominent, high volume senders. Office Live was the first one I handled in early June regarding its invalid syntax. In fact, not only was its SPF record junk, but all Office Live customers had junk SPF records! I escalated the problem through its help center as best as I could find,

From : msaladna@apisnetworks.com
Sent : Thursday, May 22, 2008 11:54:03 PM UTC
To : OFFLV.0000.00.00.EN.MSF.SEA.UA.T01.RTG.00.EM
Subject : Office Live Workspace Abuse

Service:
Office Live Workspace Abuse

What type of problem do you have?
Shared item URL: Copy the “Click here to view it” URL from the sharing invitation e-mail. To do this, right-click the link and select Copy Hyperlink.
http://www.openspf.org/Why?s=mfrom;id=a@officelive.com;ip=65.55.111.77;r=a@b.com;

Type of abuse
Other [Other]

Location of abusive content
File [File]

Please describe the issue and provide as many details as possible to help us investigate the issue quickly.
Please note that all published SPF records for Office Live customers are synt atically invalid due to the terminating null byte at the end. Please remove the null termination from the TXT records for customers:

;; QUESTION SECTION:
;officelive.com. IN TXT
;; ANSWER SECTION:
officelive.com. 702 IN TXT v=spf1 include:hotmail.com ~all\000

;; QUESTION SECTION:
;domain.com. IN TXT
;; ANSWER SECTION:
domain.com. 2901 IN TXT v=spf1 include:hotmail.com ~all\000

and so on. I assume this problem is present with all domains that have delegated authority to ns1/2.officelive.com. The garbage is causing rejects in both SPF packages for Postfix, pypolicyd-spf and perl-policyd-spf. I assume the problem exists in other software that correctly adhere to SPF specifications (RFC 4408) — http://ww w.openspf.org/Specifications

Thank you for your time and I hope this can be resolved in an efficient manner.

Your full name
Matt Saladna

Your e-mail address (for follow-up questions):
msaladna@apisnetworks.com

Which operating system are you using?Windows Server 2003: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9b4) Gecko/2008030714 Firefox/3.0b4
Which browser are you using: Firefox3.0
Location: en-us – English (United States)
Type of Support: E-mail Support
Browser Default Language: en-us,en;q=0.5

and for the response:

Hello Matt,

Thank you for contacting us at Microsoft Office Live Workspace Support.

This is Ajay Lal from Microsoft Office Live Workspace Support Team. We appreciate the time you took to send us your query and we know how important it is for you to have this addressed immediately.

With reference to your email, you have mentioned that all published SPF records for Office Live customers are syntactically invalid due to the terminating null byte at the end. I appreciate your feedback for Microsoft Office Live. At the same time I am forwarding this feedback to our Product Development Team and they will work upon your request.

Thank you for participating in Microsoft Office Live program. Your feedback is very important in the on-going effort to improve the service and ready it for the live release. We appreciate your assistance in making the Microsoft Office Live Product a great success.

Please continue to let us know your thoughts and suggestions as you use the service.

We also appreciate your solidarity with Microsoft Office Live Workspace. You may be selected to receive a survey. Your feedback is valuable to us as we are always interested in hearing about your support experience. Should you receive a survey, we appreciate you taking the time to respond.

Have a nice day, Matt!

Regards,
Ajay Lal
Microsoft Office Live Workspace Support

One would assume that given the gravity of the situation it would have been promptly resolved. Not quite; still to this day the problem persists requiring an access check bypass in Postfix to permit delivery.
Capital One’s story is a little different. Instead of making up new syntax, its SPF records prohibited delivery from its e-mail account notification program, which can be a problem for those very select few, lucky absent minded individuals, such as myself. As a result, the customer’s e-mail address had been removed from his account with Capital One. Luckily he noticed something was askew and contacted Capital One and in turn sent in an e-mail to me for an override request on the sender’s IP address. What happened ultimately is everyone received an override, because SPF is just too difficult for admins to manage.
SPF may be re-evaluated later on down the road (6 – 18 months later), but for now, until companies can get their acts together, SPF checks will only impart a marginal score in SpamAssassin.

Emulating SPF scoring

SPF scoring may be ratcheted up in SpamAssassin by editing your .spamassassin/user_prefs file within your home directory. Just add the following lines to the file,
score SPF_FAIL 5
score SPF_SOFTFAIL 4.5
Tweak the scores to your liking. A score of 5 is the threshold to be labeled as spam. A score of 10 or above, by default, deletes the e-mail. Tweak the scores and use with caution, because as I have witnessed first-hand not everyone obeys SPF syntax.
MTA SPF Checks Removed