This is kind of a response to all the follow ups this morning. I can't afford to use this test on the majority of my domains because I can't currently make use of WHITELIST AUTH, and I have enough customers that use third-party outgoing mail servers for one reason or another that this would cause issues there as well.
It seems that a lot of people don't really understand the full power of SPF. Most people assume it is pass/fail, but it is actuall pass/fail/unknown. What this means is that you can set up an SPF record that instead of saying "E-mail from @example.com that comes from 192.0.2.25 is definitely legitimate, but everything else is bogus" ("v=spf1 +ip4:192.0.2.25 -all"), you can say ""E-mail from @example.com that comes from 192.0.2.25 is definitely legitimate, but any E-mail from @example.com from other IPs may or may not be bogus" ("v=spf1 +ip4:192.0.2.25 ?all").
This is *guaranteed* to give you better results than no SPF record, even if many of your users do not send mail directly through your mailserver.
I was already debating what to do with a spamdomains variant that was coded for local domains, and I was only scoring that at 20% of my fail weight. I could remove that test and replace it with SPF scored at 20%, however the effects of the SPF would carry over to other sources that would potentially have problems and over which I would have no control over.
But that's exactly the point -- you have no control over it! If we set up declude.com as "v=spf1 +mx -all", and I send an E-mail from another IP and it gets caught on your server, that is *my* fault (or the fault of whoever authorized the SPF record for declude.com).
In this case, if one of your users says "But my friend with a competing ISP can get mail from Scott!", you can tell him "But, the company Scott works for does not allow mail to be sent except from their servers." Often, you get stuck telling a customer "That company has serious problems" (open relay, no reverse DNS, etc.). But with SPF, it is company policy, which you are honoring.
There is some potential with this as a negative weight test, however once the spammers catch on, the value would be diminished greatly, and of course legit mail servers are sources of spam, just not as often as the illegitimate ones, and I don't see the need to credit senders based only on the fact that they matched their SPF records. ... Considering these issues, I don't see why I should push something forward with such a flaw.
This might be best discussed on the SPF mailing list, where the creator of SPF and others can better comment on how SPF will deal with this. Only time will tell if spammers will be able to successfully abuse SPF, but at the very least it will give them more work to do, costing them more money.
I'm very sorry to have not liked either this effort or the Web-O-Trust thing, and I don't want to sound like I'm just being critical for the sake of it (though sometimes I am overly critical), but I feel that it is constructive for me to say this if for no other reason than to warn others about the potential of issues, but hopefully rather to influence the process for the better. I'm sure there are others around here that feel the same way, but choose not to voice their opinions out of fear of insulting someone else...or maybe I'm just whacked :)
That's fine -- if there are flaws with an idea and nobody comes out and says it, everybody loses.
-Scott
---
Declude JunkMail: The advanced anti-spam solution for IMail mailservers.
Declude Virus: Catches known viruses and is the leader in mailserver vulnerability detection.
Find out what you've been missing: Ask about our free 30-day evaluation.
--- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]
--- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
