On 01/25/18 11:19, Bill Shirley wrote: > I'm all for tightening up standards compliance with email, but what I would > see > if this would happen is a request from my customers saying: > Bob'semails (b...@bad-spf.com) are going to the spam folder; whitelist him > please > Bob's email admin won't ever know that his SPF is failing. > IMHO when the majority (including some big providers) will put Bob's email into spam folders, his admin will take a look at his spf records; nobody knows if it will work or not but I think it is worth trying. Nobody cared about https till last year, now even very simple web sites uses it only because web browsers are giving warnings, not because they do care about security. Giovanni
> Bill > > On 1/24/2018 2:59 PM, David Jones wrote: >> On 01/24/2018 01:33 PM, Bill Cole wrote: >>> On 24 Jan 2018, at 9:12, David Jones wrote: >>> >>>> What does everyone think about slowly increasing the score for SPF_NONE >>>> and SPF_FAIL over time in the SA rulesets to force the awareness and >>>> importance of proper SPF? >>> >>> -1 >>> >>> In every real mailstream I've worked with in the lifetime of SPF, lack of >>> SPF has *always* had a correlation with ham, not spam. >>> >> >> I am not suggesting that SPF_PASS = ham and SPF_FAIL = spam. >> >>> >>> SPF hard failures are a more complicated case because the sort of spam that >>> hits SPF_FAIL tends to come from IPs that show up in good DNSBLs within a >>> few minutes, making it hard for a site using DNSBLs to know how much of it >>> there is. With that caveat, I see more ham hitting SPF_FAIL than I do spam >>> where SPF_FAIL (which I have locally nailed at 2.0) is a decisive factor. >>> Most SPF_FAIL spam scores well into double digits here. >> >> I am proposing that if SPF were more accurately deployed then SPF_FAIL would >> be worth something. We could whitelist_auth more trusted senders and then >> be able to turn up the scores for the rest of the mail flow. >> >> If the huge SA community around the world were to help push SPF adoption and >> accurate deployments, then we could move on to DKIM too. Right now, the >> best option we have is to get DMARC properly deployed as much as possible >> where p=reject actually rejects the message unlike SPF_FAIL that we can't >> trust. >> >
