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