pageoneresults - 10:44 am on Jul 10, 2008 (gmt 0)

I never said they should be ignored.

I know, I have to be careful and be more literal in my responses. But, when I read this...

The mail warnings are quite common...

That more or less gives everyone reading the impression that they are okay to ignore since they are "quite common", yes? ;)

Show me.

Ooops, busted! But, not really...

Lots of domains have published records, including AOL, Amazon, Google, O'Reilly, SAP, TicketMaster, Mail.com, w3.org, Earthlink and Verizon. And the ones who haven't published are working on it.

We expect adoption to pick up exponentially; according to some estimates, the number of sites checking SPF doubles every three weeks. SPF plugins are available for all the major Mail Transfer Agents (MTAs).

For me coopster, it is a Standard and has been since 2004 October. Back in the beginning when we were first "understanding" it all, there was an eye opening experience with "554 refused mailfrom because of SPF policy" bounced emails where we had some misconfiguration issues initially which were fixed immediately. Those bounces told me that hey, these recipient servers are checking for SPF and that was back in late 2004 early 2005. Fast forward 3 years and SPF is now a standard within various high level organizations like Financial Institutions, Government Agencies, Google, etc.

coopster, do you use SPF?

SPF Adoption Rates
[openspf.org...]

Because a rule can be written does not necessarily mean it will be employed.

When they are part of the "default" ruleset, are those the ones that are "usually employed"? By default? And then you would go in and change those if you so desired?

BTW, the SpamAssassin test link is a couple releases behind. Here is the latest: [spamassassin.apache.org...]

Ah, touche! Thank you for the updated link, I overlooked that in my Bookmarks. Shame on me! ;)

As I first stated, this is where top priority should be right now.

Ah, the meat of the matter.

The first question I would ask is "Are they running their own DNS server(s).

I do believe they are.

Oh, in regards to the SpamAssassin Rules, thank you for the updated link. That just gives me more ammunition for the discussion. Look at the difference between 3.0 and 3.2. They've beefed things up a bit and also added two new rules for SPF in 3.2. ;)

SpamAssassin Default Rules 3.0 vs 3.2

3.0 - header SPF: sender matches SPF record SPF_PASS -0.001
3.2 - header SPF: sender matches SPF record SPF_PASS -0.001

3.0 - header SPF: sender does not match SPF record (fail) SPF_FAIL 0 0.001 0 0.875
3.2 - header SPF: sender does not match SPF record (fail) SPF_FAIL 2.600 0.992 1.669 0.693

3.0 - header SPF: sender does not match SPF record (softfail) SPF_SOFTFAIL 0.500 0.842 0.500 0.500
3.2 - header SPF: sender does not match SPF record (softfail) SPF_SOFTFAIL 2.301 0.654 0.698 0.596

3.0 - header SPF: HELO matches SPF record SPF_HELO_PASS -0.001
3.2 - header SPF: HELO matches SPF record SPF_HELO_PASS -0.001

3.0 - header SPF: HELO does not match SPF record (fail) SPF_HELO_FAIL 0 0.405 0 0.001
3.2 - header SPF: HELO does not match SPF record (fail) SPF_HELO_FAIL 2.298 0.365 0.540 0.001

3.0 - header SPF: HELO does not match SPF record (softfail) SPF_HELO_SOFTFAIL 0 1.002 0 3.140
3.2 - header SPF: HELO does not match SPF record (softfail) SPF_HELO_SOFTFAIL 2.599 1.533 1.427 0.841

Two (2) new rules in 3.2

3.2 - header SPF: sender does not match SPF record (neutral) SPF_NEUTRAL 2.199 1.210 0.756 0.686
3.2 - header SPF: HELO does not match SPF record (neutral) SPF_HELO_NEUTRAL 2.231 2.000 0.744 0.576

BTW, our tech team had this issue on their to-do list but it was not top priority because our sites are mostly brochure sites. They apparently weren't as concerned about the ramifications for email.

Unfortunately that is how many view this whole DNS thing. Since it is really the responsibility of the person maintaining the servers, DNS, etc. "you" should not have to be concerned about it. Well, in the real world, I think everyone with a website should be concerned.

I just can't see leaving something like this up to fate. If there are FAILs and WARNs, why not just fix them and stop using the excuse that "it is quite common". Yes it is, and so is HTML tag soup but that doesn't mean we should perpetuate and/or prolong those "not best practices".