Let’s talk about a persistent headache in email administration: header forgery. In an ideal world, technologies like SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting & Conformance) would effectively prevent malicious actors from sending emails that appear to originate from legitimate domains.

Unfortunately, as many of you managing cPanel servers know, cPanel doesn’t inherently enforce DMARC validation on incoming emails (as clearly stated in their official documentation: https://support.cpanel.net/hc/en-us/articles/1500001465601-Does-cPanel-perform-DMARC-validation-on-received-incoming-emails).

Altough they introduducted recently DMARC on domains and zone editor,  This lack of built-in DMARC enforcement creates a vulnerability. Even if an email fails SPF – a crucial first line of defense – it can easily still slip through to users’ inboxes, especially if Apache SpamAssassin’s scoring isn’t aggressive enough on SPF verification failures.

Consider testing yourself, by sending an e-mail from a server A to a domain cp-domain.tld residing on server B but lacks an SPF record of A. Sending a simple, unauthenticated email from A:

[root@server-A ~]# echo "This is a test email." | mail -s "Test Subject" [email protected]

It lands directly in the inbox with a completely forged return-path and FROM address! SpamAssassin’s assessment? Less than alarming:

  X-Spam-Score: 1.5      1.5 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)

This simply isn’t good enough. By default cPanel favorizes soft failing on the SPF records ~all. We can’t afford to be lenient with SPF. While the default SpamAssassin configuration acknowledges the discrepancy, it treats it with a mere 1.5 point penalty for a softfail.

The reasoning behind this moderate scoring in SpamAssassin, as we know, is to avoid false positives while basing the scoring on a multiple layer evaluation instead of SPF solely. As some legitimate senders might not have perfectly strict SPF implementations. However, as system administrators, our priority is often protecting our users from the detrimental effects of header forgery. This can range from simple phishing attempts to more sophisticated business email compromise (BEC) attacks. Even a small reduction in these incidents is a win for our users and our server’s reputation.

Let’s look at the default SPF-related scores in cPanel’s SpamAssassin configuration:

grep -Ri SPF /etc/mail/spamassassin/  /etc/mail/spamassassin/CPANEL.cf:ifplugin Mail::SpamAssassin::Plugin::SPFscore SPF_NONE 0score SPF_HELO_NONE 0score SPF_PASS -0.001score SPF_HELO_PASS -0.001score SPF_FAIL 4.0score SPF_HELO_FAIL 4.0score SPF_HELO_NEUTRAL 0score SPF_HELO_SOFTFAIL 1.5score SPF_NEUTRAL 0score SPF_SOFTFAIL 1.5endif

As you can see, an SPF_SOFTFAIL only adds 1.5 to the spam score – barely a slap on the wrist when an email’s origin is questionable.

Taking Control: Adjusting SpamAssassin SPF Scores

To tighten our defenses, we need to increase the scores associated with SPF verification failures. We can adjust SpamAssassin rule scoring either server-wide or on a per-user basis.

• Server-wide: Modify configuration files within /etc/mail/spamassassin/. Refer to cPanel’s documentation for detailed instructions: https://support.cpanel.net/hc/en-us/articles/360053467273-How-to-Adjust-Spam-Assassin-Rule-Scoring-Serverwide
• Per-user: Users can adjust their individual spam filter settings via their cPanel interface under: Spam Filters > Additional Configurations (For Advanced Users) > Calculated Spam Score Settings. This creates or modifies the /home/cpuser/.spamassassin/user_prefs file.

It’s also worth noting that sometimes SPF verification can fail due to temporary issues like DNS resolution problems or server misconfigurations. In such cases, SpamAssassin might assign a score of 0.0 for T_SPF_TEMPERROR:

  0.0 T_SPF_TEMPERROR        SPF: test of record failed (temperror)

While we shouldn’t overreact to occasional temporary errors (especially if they are due to our own misconfigurations), our focus should be on consistently penalizing genuine SPF failures.

My Score Adjustments;

We have 2 solution in this regard:

– Harden the SPF DNS records -all and the default setup of cPanel
– Enforce scoring globally, and let the clients change their scores locally to soften them if required. I’m currently implementing the following score adjustments to better enforce SPF on a custom config /etc/mail/spamassassin/custom-rules.cf:

SCORE SPF_SOFTFAIL 4SCORE SPF_FAIL 7.0score SPF_HELO_FAIL 7.0SCORE SPF_HELO_SOFTFAIL 3.5

These changes significantly increase the spam score for both soft and hard SPF failures, making it much more likely that these emails will be classified as spam and moved to the junk folder (assuming the overall spam threshold allows this, with an average of 4/5).

While a restart of reload spamd isn’t necessary for score changes, if you encounter issues, you can check the service status with:

systemctl status spamd

Testing and Monitoring:

You will need to carefully monitor the impact of these changes. While the goal is to reduce header forgery in user inboxes, we must also be vigilant for any potential false positives. It’s crucial to communicate these changes to users and provide them with guidance on how to manage their spam filters if legitimate emails are incorrectly flagged.

Conclusion:

While cPanel’s lack of built-in DMARC enforcement puts the onus on us to strengthen other email authentication checks, aggressively scoring SPF failures in SpamAssassin is a crucial step in mitigating the risks of email forgery. By taking a firmer stance on SPF compliance, we can significantly improve the security and trustworthiness of the email environment on our cPanel servers. Let’s implement these changes thoughtfully and continue to adapt our strategies to the ever-evolving landscape of email security.

Note that this isn’t solely related to cPanel, but could be applied on any other platform using Apache SpamAssasin.