"Daniel"
It seems to me that its the people who decide to reject mail just because the the spf records on the incoming message don't match, are the people who will make sender id systems unusable. Having working spf records has nothing to do with being SPAM, in fact percentage wise SPAM is better for correct spf records. It is purely for verifing that the mail came from an authorised server, not whether it is SPAM or not.
You're right, it is pointless to whitelist just because the SPF records check out. It's like believing an email which has a PGP signature, without checking who signed it.
If you are rejecting mail because of the spf records then you are forcing people like Ewen here to open the records just to get the mail working. Hence the records become less useful. So you should hang your head in shame.
The SPF draft says that you MAY reject on a fail. It seems to me like this is a problem with the design of SPF, rather than a misconfiguration on behalf of mail admins. The SPF record is specifically telling you that the message is not legitimate - even though that might be because the mail list/exploder/forwarder is not doing the appropriate SRS magic. cheers, Jamie http://spf.pobox.com/spf-draft-200406.txt "3. SPF Record Evaluation An SPF client evaluates an SPF record and produces one of seven results: None: The domain does not publish SPF data. Neutral (?): The SPF client MUST proceed as if a domain did not publish SPF data. This result occurs if the domain explicitly specifies a "?" value, or if processing "falls off the end" of the SPF record. Pass (+): the message meets the publishing domain's definition of legitimacy. MTAs proceed to apply local policy and MAY accept or reject the message accordingly. Fail (-): the message does not meet a domain's definition of legitimacy. MTAs MAY reject the message using a permanent failure reply code. (Code 550 is RECOMMENDED. See [RFC2821] section 7.1.) Softfail (~): the message does not meet a domain's strict definition of legitimacy, but the domain cannot confidently state that the message is a forgery. MTAs SHOULD accept the message but MAY subject it to a higher transaction cost, deeper scrutiny, or an unfavourable score." -- James Riden / j.riden(a)massey.ac.nz / Systems Security Engineer Information Technology Services, Massey University, NZ. GPG public key available at: http://www.massey.ac.nz/~jriden/