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

[Tony Yates]

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.

HTH

Regards,

Tony..


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