Exim 4.97 Seems to Break MailScanner 5.4.5 due to Change in MessageID Length?

Tony Yates tony at canetoad.co.uk
Mon Nov 6 19:11:20 UTC 2023

Shawn, et al,

Thanks for the speedy response.

I've been digging and found the following in EximDiskStore.pm at around 
line 495 there is a Sub, that has a reference to the 'old' Message-ID 
structure at about line 509

# Writes the whole message to a handle.
# Need to be passed the message to find the headers path
# as it's not part of the DiskStore.
sub ReadMessageHandle {

code omitted

   # We have to strip the message-ID off the beginning of the file
   # using sysread since that is what File::Copy uses and it doesn't
   # play nicely with stdio operations such as $body->getline. The
   # magic number 19 is from the length of NNNNNN-NNNNNN-NN-D\n.

The magic number 19 is then used below that:

  sysseek($from_h, 19, 0);

I guess the new Message-ID structure would definitely break that.




On 06/11/2023 16:58, Shawn Iverson wrote:
> On 11/6/23 11:44, Tony Yates wrote:
>> Dear MailScanner,
>> I just tried an upgrade of Exim to the very recently released 
>> version, 4.97 and the mail system seemed to break.  Messages 
>> disappeared.   They wold show as a line entry in a Mailwatch recent 
>> messages list, but the actual message behind that entry would return 
>> Message ID '7h01hZ-000000004Pk-1fWj' not found!
>> I note from the release notes on 4.97 that the Exim internal 
>> MessageID format has changed,
>> as per:  "The internal (but exposed in logs, Received: headers and 
>> Message-ID: headers)
>>    identifier used for messages is longer than in the previous release"
>> From: 7h02TT-0001wI-1b
>> To: 7h01hZ-000000004Pk-1fWj
>> I'm wondering if this might be the cause, but not sure yet where to 
>> dig in to the code and see.  I'm hoping that you might know the 
>> answer without the need to dig too far?
> This is likely the culprit, but I'll need to dig into the code to find 
> out why.
> -- 
> Shawn

More information about the MailScanner mailing list