Hundreds of emails stuck in progress
After yesterday's update, which upgraded bundled Exim to 4.100, we are experiencing issues with outgoing deliveries from various servers.
All of these mail servers have MailScanner Front-End v10.00 installed and MailScanner v5.4.4.
Our investigation resulted in finding, through Exim's mainlog, that the spool file for all the messages is missing, and more specifically, the file messageid-D.
We have already checked the spool and Exim folders' ownership and permissions, and they are set properly.
-
We are experiencing a similar situation on WHM 138.0.6.
2 -
As I see it, the possibility of such an issue occurring has already been described here: https://support.cpanel.net/hc/en-us/community/posts/43187553265943-Exim-configuration-rebuild-fails-when-Mailscanner-is-installed
However, cPanel has not provided any response for 8 days.1 -
Exact same symptoms. Disabeling Mailscanner resumes exim queue albeit with standard spamassasin setup One of our other servers on 136.0.39 is still functioning so somthing changed on 138.0.6 for us atleast or there is a specific package conflict. We are monitoring if 136.0.39 stays operational.
But seeing as MSFE is no longer maintained I guess its finally farewell to it as I am not seeing any new maintainer picking it up and I doubt WebPros wants to burn there hands on that. I am going to contact my Datacenter reps and source alternatives.1 -
I'm having the same issue and it looks like Cpanel has responded ...
But I have no idea how to update Mail Scanner yet - also it looks like someone is developing a Open-source version of MSFE called MSFE-NG ... https://github.com/inalto/msfe-ng/tree/main
1 -
Thanks for sharing.
As much as we love MSFE I feel this is the moment for us personaly to retire it.
I see MSFE-NG is now using Claude for code dev or maintaining it as it is listed as contributor.
I have nothing against A.I we operate our own company with it but I am not confident that we are at the level that integrating Claude in the development process of security focused assets on production is a choice I can deem safe from a risk management standpoint.
We are moving ahead with Immunify:Email addon as we sadly already had to replace CXS in the past with Immunify360. I am probably not going to enjoy it but I will live with it.If WebPros ever decides to takeover MSFE I will jump back in a heartbeat.
Not how I planned to end my week for sure.1 -
Same here without solution yet
have to disable MSFE and activate the built in spamassassin for now
0 -
I've done the same, but rather than disable, I've remove MSFE totally as it's no longer support where Spamassassin is.
0 -
MSFE is no longer supported software, so if that's what's causing the issue it would be best to disable that.
-1 -
The most serious issue is that all emails sent or received before disabling MFE are lost and cannot be recovered.
Furthermore, the people who sent the emails do not receive any notification that the email was not delivered.0 -
This is not an Exim or spool format change — it's a Perl version-comparison bug in MailScanner's startup code. MailScanner detects the Exim version to decide whether Exim uses the long message-ID format (introduced in Exim 4.97):if ($ver >= 4.97) {
>= is a numeric comparison, and Perl numifies the string "4.100" to 4.1, which is less than 4.97. So MailScanner falls back to the old short-ID spool handling, files every scanned message into the wrong split-spool subdirectory (input/0/), and Exim never finds it. You can verify the Perl behavior yourself:
$ perl -e 'print "4.100" >= 4.97 ? "new format\n" : "old format (bug)\n"'
old format (bug)Fix: edit /usr/mailscanner/usr/sbin/MailScanner (ConfigServer install; for a stock MailScanner install the file is /usr/sbin/MailScanner) and replace the line
if ($ver >= 4.97) {
with
my ($vmaj, $vmin) = $ver =~ /^(\d+)\.(\d+)/;
if (defined $vmaj && ($vmaj > 4 || ($vmaj == 4 && $vmin >=
Or a quick one with backupperl -i.bak-exim4100 -pe 's/^(\s*)if \(\$ver >= 4\.97\) \{/$1my (\$vmaj, \$vmin) = \$ver =~ \/^(\\d+)\\.(\\d+)\/;\n$1if (defined \$vmaj && (\$vmaj > 4 || (\$vmaj == 4 && \$vmin >= 97))) {/' /usr/mailscanner/usr/sbin/MailScanner
Then restart MailScanner (systemctl restart MailScanner — a Messages already misfiled can be requeued with/usr/msfe/msreq.pl (ConfigServer) or by moving the -H/-D pairs back to the proper spool subdirectory and running exim -qff.
Tested on a standby server and works fine, a few dozends more to go
Upstream MailScanner 5.5.3 has the same bug — tracked as MailScanner/v5 issue #717.
5 -
Thank you so much!!! It worked perfectly.
0 -
Thank you!
0 -
Nickgr thank you very very much!!
0 -
Thank you, nickgr! This was very helpful.
0 -
Thank you!!
0 -
nickgr thank you very much!
0 -
nickgr thank you!
0 -
this worked on my servers
perl -i.bak-exim4100 -pe 's#^([ \t]*)if \(\$ver >= 4\.97\) \{#${1}my (\$vmaj, \$vmin) = \$ver =~ /^(\\d+)\\.(\\d+)/;\n${1}if (defined \$vmaj && (\$vmaj > 4 || (\$vmaj == 4 && \$vmin >= 97))) {#' /usr/mailscanner/usr/sbin/MailScanner
0 -
FAO: Cpanel support...
The code you provided on this article:
https://support.cpanel.net/hc/en-us/articles/43420413359639-Messages-stuck-in-Exim-queue-after-update-to-cpanel-exim-4-100-when-MailScanner-is-enabled... has unescaped some of the characters in the fix from nickgr, so it doesn't work.
Perhaps worth linking back to this discussion so that viewers can find the original code fix and apply it in cases like this?nickgr Thanks for supplying the fix. Saved the day...
0 -
Martin Smallridge - use nickgr's perl line, it has the complete thing for you!
Here's the full line:
my ($vmaj, $vmin) = $ver =~ /^(\d+)\.(\d+)/;
if (defined $vmaj && ($vmaj > 4 || ($vmaj == 4 && $vmin >= 97))) {0 -
Thanks NikGR, life saver. What's the consensus on my beloved Mailscanner FE then, find something to replace it with moving on? The MailControl and seeing that things go through and get spam marked etc is sooo helpful!
0
Please sign in to leave a comment.
Comments
21 comments