Hi,
- Serious design flaws (such as the forwarding problem).
SPF is there to prevent mail with your sender envelope address to be relayed/forwarded by mailservers that are not meant to use your address. When you forward a mail in your MUA, you don't use the original sender in the From: header, do you? When a mailserver is relaying mail it is supposed to use its own sender envelope address. One possibility for that is SRS.
- Peopele who don't understand SPF. If the not-understandig is a
mailserver admin it gets fatal (and lots of them are).
Both leads to legitimate rejected mail (And not just "some" false positives, sometimes complete domains get locked out by mailservers).
So consider....
That is a problem which in not restricted to SPF. If a mailadmin doesn't know how to use an RBL and blocks everything, then he can't be helped.
- Think twice before publishing SPF Records for your Domains.
There are admins in the wild who treat "neutral" as "hard fail".
I haven't had the chance to be in this situation yet.
- I use SPF to reject mails with spoofed origings from my private
mailserver. The number of rejected mails because of failed SPF checks is less than one percent of all REJECTED email. If I wouldn't be doing it for studies about mail, SPAM and means against it I'd completely let it be. It's not worth the effort to support a standard which is broken by design and so rarely used.
If you consider SPF to be the solution against all kinds of SPAMs then you will indeed be disapointed. SPF is meant to prevent the abuse of your domain as mail envelope from address. There are still worms out there that use harvested e-mail addresses as sender. And when the people receiving this kind of spam come back to you, you can at least tell them: hey, we published spf records to show you which IPs are allowed to send mail with this envelope address. if you don't check it and accept the obvious forgery, then it's your problem.
Regards,
Jean-Pierre