spamassassin-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Fox <vb...@ucdavis.edu>
Subject Re: Penalty for no/bad SPF
Date Wed, 24 Jan 2018 22:00:11 GMT
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 <djones@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

Mime
View raw message