No Spam Score Penalty for SPF_NONE and DMARC_FAIL_NONE

[yeah]

I have read the discussion in #1755 and the PR #1836 and I generally like this change as it helps MIAB users get less spoofed spam email.

However, I believe that we are going a bit too far now with the DMARC_FAIL_NONE and SPF_NONE rules. They essentially give incoming emails a 2.0 score penalty if the originating mail domain does not have an SPF record and another 2.0 penalty if the domain has a DMARC record that was set to p=none.

While generally speaking, domains which are sending email should have set up SPF and DMARC records, the absence of a SPF record or the voluntary opt-out of DMARC by setting p=none should not result in a spam penalty.

Both cases should not affect the spam score in my opinion. For DMARC, I could find a source backing up this opinion. For SPF, I couldn't find a source, but it would seem pertinent here as well.

I'd be happy to prepare a PR if we come to a consensus on this issue.

[jvolkenant]

If the values are a bit strict; We can always adjust to other values if needed. I have only had 1 spam email since testing that PR that was not spam, but it was a newsletter from a domain that had no SPF. At this point SPF for a mail domain should be a bare minimum so I don't fault the weights for that one.

[myfirstnameispaul]

I do not favor changing the SPF_NONE or DMARC_FAIL_NONE spamscore modifiers.

I recommended the SPF no record found setting because nearly all domains legitimately sending email these days have an SPF record, though I based this on my own emails that I receive (including many old free email accounts and going through them). SPF is now a very old standard and not having SPF usually causes a lot of problems with the free mail providers, so anyone desiring to not be in spam boxes pretty much has to have this record. In fact, most spam emails will have SPF configured when they aren't trying to spoof a domain, so the only domains I normally come across that don't have an SPF record are ones that are spamming, and even then it isn't very many though tends to be the nastiest sorts.

For the penalizing of DMARC when p=none, if the admin went through the trouble of creating a DMARC record, then there is reasonable cause to add some score, especially when there is an alignment issue.

A failure of both of the above two examples results in increasing spamscore by four points, which is still below the score of 5 where spamassassin declares an email as spam. Most email has other modifiers, so if an admin is using a server not on the SPF record, then likely they will have other modifiers that are in the opposite direction, and will not be declared as spam by spamassassin. However, spammers will also have modifiers that are likely to be in the direction of spam, so increase the spamscore to above the threshold.

The MiaB server will go against recommendations based on the project's goals. For example, when p=reject the admin is supposed to configure the server to reject the email completely, but the MiaB project prefers to be inclusive and never reject mails based purely on a [mis]configuration, so instead p=reject failures result in very high spamscore modifier.

I actually wish there were a tool for reporting what is actually going on with not-spam/spam on a server to gain a better idea of how to configure these settings, because many of these decisions can effectively be subjective due to high variance.

[meineerde]

I think we may discuss the two parts separately.

With a DMARC p=none rule, it is possible to verify a DMARC policy or just to get an idea about how mails are being sent. Most importantly, a p-none policy still allows to set up a reporting via a rua / ruf rule, without affecting the deliverability of existing mails. This is even recommended by the DMARC FAQ as a first step in setting up DMARC in an existing infrastructure.

To quote the FAQ again:

With a policy of “p=none”, DMARC does not change in any way how your email is handled at the receiver.

As such, mailinabox should not penalize a p=none DMARC record as those record are added specifically to test DMARC without affecting deliverability of the mails. Also, the 2 points currently added for a p=none policy are even more surprising considering that an entirely missing DMARC policy only gives 0.1 point.

As such, I would be in favor of removing the DMARC_FAIL_NONE rule entirely and to not deduct or add any spam points for such a DMARC policy.

Now, as for a missing SPF rule, while it's true that most production systems currently define an SPF policy, such rules are intended only to penalize mails not matching the defined SPF policy. There are still valid reasons to not have a SPF rule in place (or to define an overly broad policy). A missing rule should not result in penalties applied — only a broken rule should.

As far as I'm aware, this is also mirrored by how other large mail providers are handling this and how the standard was intended to be used: a broken SPF rule results in penalties, a matching rule may result in positive signals applied, but a missing or neutral rule (which may be indicated with a spf=neutral header and can also actively be defined in SPF) should result in neither penalties nor positive signals applied.

Given that, I would be in favor or removing the SPF_NONE spam rule, or at least to reduce its score to 0.1.

[myfirstnameispaul]

I am just wondering if you can address my more operational based acquired knowledge and desired server behavior discussion.

Personally, I don't find following the rules to be sufficient in how I determine a server configuration, but that's just my preference.