On 24 Jan 2018, at 14:59 (-0500), 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.
I did not think or say that you were.
You are proposing that SA as a project should *act as if* these
correlations exist and are steadily becoming stronger:
1. Mail with an envelope sender domain that has no SPF record is more
likely to be spam than the overall mail stream.
2. Mail whose envelope sender domain has a published SPF record which
repudiates the sending IP is more likely to be spam than the overall
mail stream.
I don't see evidence that either of those are true now, that they have
ever been true, or that they are becoming closer to true over time.
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.
That is a truism but what you are proposing is that SA should behave as
if SPF deployment is becoming broader and more accurate steadily over
time, as a sort of sympathetic magic to drive that improvement.
I am saying that history implies that this would not work as hoped.
Also, it is a bad precedent for project policy.Slowly rising SA scores
don't exert any pressure on a sender with broken SPF until they actually
cause mail to be dropped or rejected. We should not be intentionally
increasing false positives no matter how noble the end goal.
Individual sites obviously can make that choice on their own, now. For
example, on my own personal system I would very likely see some FPs due
to my unjustifiably high fixed score for SPF_FAIL, were it not for other
bespoke tweaks which make actually effective FPs extremely unlikely.
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.
SA is not the vehicle for such pressure. What has been driving careful
DMARC deployment is not the long tail of sites with <10k users using SA,
it is the handful of behemoth providers plus some key commercial and
government systems that honor p=reject. This was also the strongest
driver for SPF adoption, until those behemoths recognized how flawed SPF
& DKIM alone were and came up with DMARC as a "solution" with the
unsurprising side effect of damaging traditional discussion mailing
lists.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole
