Hector Santos wrote: > based on SPF experience, since day one I have outlined on > numerous occassions how this is being ignored by some SPF > implementation
If you're talking about SOFTFAIL I wonder what "ignored by some SPF implementation" means, does the code return FAIL or NEUTRAL instead of SOFTFAIL ? Or are you talking about receivers interpreting SOFTFAIL like FAIL or NEUTRAL ? RFC 4408 recommends a kind of "greylisting" for a SOFTFAIL, or flagging / scoring the mail as suspicious. If some SPF implementation "ignores" SOFTFAIL by returning a different result like NONE, TEMPERROR, NEUTRAIL, FAIL, or what else, it's broken. If a receiver treats SOFTFAIL like another result it's ok., his server, his rules, "receiver policy". A publisher using SOFTFAIL over a long time will find that "interpreting SOFTFAIL as suspicious" actually means that SOFTFAILing mails could vanish in the black holes of "spam folders". It's dangerous to use SOFTFAIL over long periods of time, the likely behaviour of mail receivers is hard to predict for a SOFTFAIL, unlike FAIL. What Ebay and Paypal do is wrong, no doubt about it. Frank (certainly no SOFTFAIL fan) _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
