I'd rather not think about the manhours I've wasted this year on SPF.
The guy at Evotec.com, among others, who thinks rejecting for SOFTFAIL is a perfectly valid anti-spoofing strategy and doesn't blink when pointed to RFC 4408 sec 2.5.5. Vendors who's first response is: "Our LEGIT spam....errr bulkmail is ending in your Junk. Response #1 in our binder is you MUST list us in your SPF record." Dig, dig, dig maillogs. All emails using Envelope From properly so SPF is a waste of everyone's time. Records we included to ours, where the vendor makes a typo in THEIR SPF record on a Friday night. Or decides to add 9 sub-includes. Either way our record suddenly returning PERMERROR and we have to get someone in, and boot vendor off the island on a Sunday. Endless hours explaining to campus clients, what SPF is and why it is not a good primary strategy to solve Junk mail issues. The only good thing I have to say about SPF, is it seems to be a permanent employment program for people who are otherwise useless. ________________________________ From: Martin Gregorie <mar...@gregorie.org> Sent: Wednesday, January 24, 2018 11:32:27 AM To: users@spamassassin.apache.org Subject: Re: Penalty for no/bad SPF On Wed, 2018-01-24 at 19:01 +0000, Vincent Fox wrote: > SPF is a zombie legacy that someone should shoot in > the head. > SPF is still good for what I've always thought was its main use: detecting spam delivered by backscatter. Given that its dirt cheap to implement, and easy too verify now that there are good checking tools there's no reason or necessity to kill it. > Maybe then we could design something that is useful for what we all > desire, which is properly authenticating senders. > ... provided that you can persuade all legit senders to buy into using it while preventing all spammers and bots from hijacking it. Martin
