Latest cPanel doesn't show the helpful "Content analysis details" section in the X-Spam-Report or X-Ham-Report anymore. Can't see what rule names were hit so I can adjust scores accordingly (truncation issue) (exim) (headerwrap) (headerwrap_130:)
Edit: See big answer comment below. The use of Exim's ${headerwrap in cPanel's default_spam_scam template was truncating the header preventing it from showing me these critical rule hits.
As per title we've migrated our account to a new cPanel server (With WHM/ssh access).
Things seem to have changed because we used to be able to look at the headers of spam we receive and adjust our spam scores accordingly for all sorts of different spamassassin rules, helping prevent similar spam from making it through to our inboxes in the future. That tuning option is still present in cPanel and is not the problem.
Our CEO got a blatant phishing email today and forwarded the .eml to me as requested. But this new `X-Ham-Report` header thing (after being decoded) doesn't seem to contain the usual summary anymore? So I can't see what rules scored points on this phishing email to adjust them in the cPanel web interface.
Running `grep -R 'Content analysis details' /var/lib/spamassassin/` I can see that this reporting option is still part of spamassassin:
`# grep -R 'Content analysis details' /var/lib/spamassassin/`
`/var/lib/spamassassin/4.000001/updates_spamassassin_org/10_default_prefs.cf:report Content analysis details: (_SCORE_ points, _REQD_ required)`
In that file it's a template named `clear_report_template`.
I was looking around in the `Exim Configuration Manager > Advanced Editor` portion of the cPanel interface and I can see a `default_spam_scan` where I could simply add that line so we can track what rules are firing and adjust accordingly, but it doesn't seem to be editable.
Where in cPanel can I tell it to use this clear_report_template instead of the the new default it has shipped with - which contains no helpful information for fine tuning rule scores?
-
Hey there! I'm not sure you can adjust the template being used from my research. However, we do have a guide at https://support.cpanel.net/hc/en-us/articles/4402534965655-How-to-find-the-descriptions-of-SpamAssassin-rules-to-help-understand-why-a-message-was-marked-as-spam that explains how you can find the rules used to flag messages, so that may be helpful here.
Can you try that option and we can go from there?
0 -
[Anyone else in this situation scroll down to the [Solution] section of this comment]
Ok. Ugh. What a nightmare. I figured out how to get the useful spamassassin rule-hit headers back.
It turns out they're actually supposed to be present but this more recent cPanel change to the rfc2047-compliant X-Spam headers includes the use of Exim's `${headerwrap_130` operator (I learned that from Exim's very own huge 1.8MB spec.txt file) because they decide to not put it into a man page or any kind of modern documentation online, or at all.
Anyway. That headerwrap operator of Exim's takes up to three arguments in the format of `${headerwrap_<cols>_<limit>:<string>}` and cPanel only set the <cols> part of that operator before giving it the :string on the end meaning the <limit> of the text is a default value of 998 (??!?!).
With some online searching this seems to be a compliance with rfc5322 (2008) which dictates a single header line shouldn't go over 998 characters in length for compatibility reasons, but the <cols> value used by cPanel's Exim template for that headerwrap operator is already wrapping it every 130 characters anyway? preventing it from being a long single line?
Even then that 998 length rule hardly matters when we're talking about emails being delivered to my clients Maildir's for their modern mail clients to open/forward to me.
Anyway yes the default max line length of `${headerwrap` is 998, which is what has been causing the useful headers from spamassassin to get truncated off the end abruptly. Turns out they're actually supposed to be present by default. headers to get truncated off the end of the encoded X-Spam-Report header string. It turns out they're actually still supposed to be there!
[Solution]
Here's what I ended up doing as it seemed like the best possible approach:
- Copy `/usr/local/cpanel/etc/exim/acls/ACL_SPAM_SCAN_BLOCK/default_spam_scan`
to something like
`/usr/local/cpanel/etc/exim/acls/ACL_SPAM_SCAN_BLOCK/default_spam_scan_spamassassin_custom` - Edit your new copy of that _custom-or-something file in the same subdirectory `default_spam_scan_custom` and find the two lines containing `${headerwrap_130:` each for X-Spam-Report and X-Ham-Report and change it to a sensible character limit such as `{headerwrap_20000:20000:`
(I used this copy and sed command to do it for me automatically instead)cp -nv /usr/local/cpanel/etc/exim/acls/ACL_SPAM_SCAN_BLOCK/default_spam_scan ~/default_spam_scan.bak.$(date +%s) # Just in case
sed -i 's/${headerwrap_130:/${headerwrap_130_20000:/g' /usr/local/cpanel/etc/exim/acls/ACL_SPAM_SCAN_BLOCK/default_spam_scan_spamassassin_custom - Then I rebuilt the exim config and restarted it with the two below commands
`/scripts/buildeximconf && /scripts/restartsrv_exim` (Formatting on this site is very troublesome...) - Go to Exim Configuration Manager's `Advanced Editor` section, uncheck the `default_spam_scan` box and check the `default_spam_scan_spamassassin_custom` one instead, then save.
With that done this afternoon I crafted a fake spam email and sent it to myself via a docker container on this cPanel server (It wont put it through spamassassin if the connection is from localhost). That fake spam email managed to generate a X-Spam-Report line that was 4145 bytes in length (!) triggering 23 spamassassin rules scoring 34.4 out of 10 points to be marked as spam.
And to think the cPanel server was truncating these reports to a maximum of 998 characters :( There's so much text I don't know how that was ever going to work as a default template.
That's how I fixed this for me. Now when my clients forward me spam to block as .eml attachments I can finally see the "Content analysis details" section from spamassassin's X-Spam-Report header which shows which rules were triggered (Which is the MOST important part of the spam email so I can adjust the rule scores accordingly!). This section is what started getting cut off by cPanel at some point. Because of the `130` in `${headerwrap_130` some of the decoded output randomly newlines mid sentence still. I might set that to a large number too, or somehow just stop using this headerwrap feature of Exim's all together because it's just a pain.
That's today's adventure done and now spam reports from my clients are useful again.
I also followed these instructions this afternoon to stop using this rfc2047 header change all together: https://support.cpanel.net/hc/en-us/articles/36160643334807-Email-message-headers-X-Ham-Reports-and-X-Spam-Reports-output-is-not-readable
_ because it's a bit of a pain to copy-paste the encoded spam headers into decoding tools such as https://github.com/mgeeky/decode-spam-headers (Though this has been a super helpful tool since this unterminated `${headerwrap_130` + rfc2047 X-Spam-Headers template change by cPanel)
It's so much better, I can see the entire Content analysis details just like they used to be. In an easily readable text table with padding so it's easy to read. Right in the .eml. As it used to be.
------------------
I was originally going to do all of this via the Exim Configuration Manager's `Advanced Editor` section, but for SOME reason the configuration it shows you is post processing. There are variables in the default_spam_scam file like `[% ACL_SPAM_HEADER %]` which are already resolved to the variable (usually `***SPAM***` by default) in the Exim Configuration Manger's Advanced Editor section.Further, there's no facility to edit the `default_spam_scam` entry in the Advanced Editor, you have to highlight and copy it all, uncheck it, then check the option above it (`custom_begin_spam_scan`) and paste it there. And then the ACL_SPAM_HEADER would be hardcoded at that point.
And FURTHER (!) for some silly reason, cPanel renders that entire page template (/scripts2/advanced_exim_editor) with a stupidly restrictive 100 columns. That's not a big deal, but it literally breaks the configurations displayed if they go over 100 characters in length. It splits them with a newline to "fit" on the page. Meaning if you copy the `default_spam_scam` entry in the Advanced Editor and paste it into `custom_begin_spam_scan` it doesn't validate until you manually undo the newlines cPanel's advanced_exim_editor page has mangled the configs with.
The cause of that is in the `advanced_exim_editor.tmpl` template file where it explicitly sets `cols = 100` on line 268 for `cPanel version 130.0 (build 16)` and references it in multiple spots while building the page. Including the configuration files.
That has annoyed me in the past so just in case it's annoying anyone else you can fix the mangling of long-lined Exim config files in the Advanced Editor "semi-permanently" by editing `advanced_exim_editor.tmpl` and changing:GET txtline.textbreak( cols, "\n" ).cpanel_safe_html_encode_str() _ "\n";
to:
GET txtline.cpanel_safe_html_encode_str() _ "\n";
And saving the file then reloading the page.
Or (as a note for future me) just run these two commands (Backup the template file and only then change it:
/usr/bin/cp -nv /usr/local/cpanel/whostmgr/docroot/templates/advanced_exim_editor.tmpl ~/advanced_exim_editor.tmpl.bak.$(date +%s) && \
sed -i 's/txtline\.textbreak( cols, "\\n" )/txtline/g' /usr/local/cpanel/whostmgr/docroot/templates/advanced_exim_editor.tmplI say it's only semi-permanent because a major cPanel update some day might replace this file causing the change to become undone. I don't know if it gets the same UI treatment as the Exim Configuration Manager somewhere, allowing a custom template. I suspect not.
I'm working with the raw configuration text files a LOT these past few months with some customer migrations so I really need to be able to modify these advanced configuration texts without silly problems like cPanel rendering them with a newline every 100 characters (Why is that even a thing? Format line wrapping html5, don't mangle the config file's raw output directly!).
2 - Copy `/usr/local/cpanel/etc/exim/acls/ACL_SPAM_SCAN_BLOCK/default_spam_scan`
-
Looks like around September 25th 2025 a client's cPanel server started seeing X-Ham-Report/X-Spam-Report headers which were a true single line of 5000-7000 characters.
It seems to have been on the 7th of November that their cPanel started multi-line wrapping the X-Spam/X-Ham-Header lines. That night there was a security advisory to reboot so that must have been when cPanel updated itself.
But the topic of this post, the customers we migrated, we made that cPanel instance in late October and they were already seeing this problem - I assume cPanel updates are either on a timer for the machine to check, or rolled out in a staggered rollout fashion.
0 -
We have case CPANEL-50170 open on this, and you can follow along using the link here: https://support.cpanel.net/hc/en-us/articles/36160643334807-Email-message-headers-X-Ham-Reports-and-X-Spam-Reports-output-is-not-readable
0 -
Yeah. That's the one I've linked and self solved the missing pieces of.
0 -
I'm the one who has been implementing these changes. Apologies for needing to iterate so many times. And I'm usually such a stickler for RFC compliance...
Ideally, email clients would all be able to show non-standard headers after RFC 2047 decoding, but that ship sailed a long time ago.
Part of the issue up to now has been that I've been trying to implement all of these changes in Exim string expansions directly, which really limits what can be done without resorting to completely unmaintainable monstrosities. Starting with CPANEL-50170, presuming that I end up handling the case, I'm planning to switch to doing the encoding using an embedded Perl function call to something in /etc/exim.pl.local, so that we can do much more flexible and precise RFC 2047 encoding of only the non-ASCII characters, which should largely maintain the readability of the header's original formatting.
As for the limitations in the Advanced Editor, the inability to edit stock ACL statements permanently is unfortunately baked deeply into the design, at least as I understand the system, so that's probably not going anywhere for a while. The best way to work with that is to disable the stock ACL statements and use the custom ones provided to present modified copies. As for the column wrap, I suspect that the number 100 might be a compromise between large and small screen editing, but in any case, I have opened CPANEL-50251 to get someone better versed with user interfaces to look into improving this particular experience, or at least increasing that column count.
EDIT: After re-reading your comments and looking at other reports, I see what the problem is with ${headerwrap} truncating things: my reading of how Exim describes that string expansion obviously isn't congruent with what it actually does. I fail to see the utility in automatically truncating a text string which one wants to wrap into a multi-line header at the single line limit, which to me defeats the whole purpose of line wrapping, but someone probably depends on this presumably long-standing behavior of ${headerwrap}, so this won't be worth filing another Exim bug over — yes, there's already been an Exim bug filed as a result of this odyssey.
The discussion with the involved parties internally have shifted the proposed fix away from precise yet RFC-legal representation of the "Content preview" inside of the Spam Report and towards just collapsing anything outside of the ISO-8859-1 code points using the ${from_utf8} string expansion instead, since the body of the message should remain unchanged.
1 -
Thanks, Sloane!
0 -
Hi Sloane,
Thanks for your reply. I can understand the drive to stick to RFC - I just missed my beautiful content analysis headers that make tweaking spam scores super easy by seeing which ones fired plus their weight and had to fix it with so many forwarded spam emails that I couldn't see the current weights for.
> the inability to edit stock ACL statements permanently is unfortunately baked deeply into the design
Not fatal, in this exercise I ultimately learned you can just duplicate the default conf, modify that and disable the default in that UI which is great. When that's possible its probably a good thing that people can't accidentally botch their default configs with no "reset to defaults" type button.
0 -
I'm an email end-user (through CPanel/InMotion hosting) and I'm wondering when the workaround to eliminate the truncation is going to be making into the standard CPanel release. I think you folks drop a cPanel release around the 5th to 7th of every month and I don't see any changes percolating through to my ISP side. Is this always going to need to be a "hack" if someone needs to get the full X-Ham-Report? Is this still being considered an Exim bug? Can anyone direct me to that bug report if so?
0 -
I can confirm that case CPANEL-50170 has been released to all versions as of 132.0.9, which is just now in Release.
0
Please sign in to leave a comment.
Comments
10 comments