so there's this argument that goes:
"well we won't really see the benefits until it's FULLY and RIGIDLY implemented." However, look at all the major providers with messed up records and neutral or soft fail. They should have the most resources to accomplish this and the most incentives to list all their netblocks and set to hard fail. Google is soft fail. Hotmail is soft fail. (etc etc ad nauseum) I rest my case. After 14+ years we are still having this ridiculous argument about how in 14 MORE years when we finally fully implement this flawed technology, it'll do something useful. Meanwhile i see it as being more risk than benefit. Frankly I'd rather these manhours be used on having correct A & PTR records, which seems to be beyond the pale for some bulkmail vendors. ________________________________ From: David Jones <djo...@ena.com> Sent: Wednesday, January 24, 2018 12:12:56 PM To: users@spamassassin.apache.org Subject: Re: Penalty for no/bad SPF On 01/24/2018 01:58 PM, Vincent Fox wrote: > 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. > The Internet is very slow to change. It takes a large force like Google to improve things slowly over time. They are doing good work in the TLS and browser encryption area. SA could be the large force that helps improve the mail standards like DMARC -- SPF + DKIM with a little extra on top. > > 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. > I have a script that checks all of our customer's SPF records for syntax problems and too many DNS lookups based on pyspf just like http://www.kitterman.com/spf/validate.html does so I can correct it or notify them immediately. > > Endless hours explaining to campus clients, what SPF is and why > If SA all around the world says the same thing you are telling them then they will have to listen and fix their problem or remove their SPF record which is better than having an incorrect one. > 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. > -- David Jones
