Skip to main content

Hundreds of emails stuck in progress

Ioannis Savvopoulos

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.

Comments

18 comments

Date Votes
  • Sergey Starovoitov

    We are experiencing a similar situation on WHM 138.0.6.

    2
  • Sergey Starovoitov

    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
  • ITHKBO

    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
  • Equiphase Limited

    I'm having the same issue and it looks like Cpanel has responded ...

    https://support.cpanel.net/hc/en-us/articles/23176466587415-MailScanner-issues-after-cPanel-update-to-versions-110-and-120-or-higher

    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
  • ITHKBO
    • Edited

    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
  • Kim

    Same here without solution yet

    have to disable MSFE and activate the built in spamassassin for now

    0
  • Equiphase Limited

    I've done the same, but rather than disable, I've remove MSFE totally as it's no longer support where Spamassassin is.

    0
  • cPRex Jurassic Moderator

    MSFE is no longer supported software, so if that's what's causing the issue it would be best to disable that.

    0
  • david rive

    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
  • nickgr


    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 backup

    perl -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.

    4
  • abw

    Thank you so much!!! It worked perfectly.

    0
  • bloatedstoat

    Thank you!

    0
  • Randy Henderson

    Nickgr thank you very very much!!

    0
  • Jason - Unlimited Net

    Thank you, nickgr!  This was very helpful.  

    0
  • sondroyo

    Thank you!!

    0
  • Metro2

    nickgr thank you very much!

    0
  • Kim

    nickgr thank you!

    0
  • Rob Russell

    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

Please sign in to leave a comment.

Didn't find what you were looking for?

New post