Pigeonhole redirect is adding a message-id header when it already exists

[Emmanuel Fusté]

Le 02/10/2022 à 06:35, Sébastien Riccio a écrit :
> Hi,
>
> After reading a bit the code and trying to understand it, here is what 
> I think happens here:
>
> Given a bogus Message-ID, for example (notice it's missing angle 
> brackets < >:
>
> Message-ID: 
> 1883biz_pay_after_purchase:0:0_572392900$ae7ed6e4d53b424c84aaf83b30c507e7
>
> Dovecot is parsing Message-ID headers and is looking for the angle 
> bracket as the begining of the Message-ID:
> https://github.com/dovecot/core/blob/d2ff32792ac052610cea7d65f30de1ee139cb55c/src/lib-mail/message-id.c#L75
>
> As none is found it will act as if there was no Message-ID header in 
> the mail (even that the header is present).
>
> Then, pigeonhole's redirect function  is told to generate a new 
> Message-ID if none was previously detected:
> https://github.com/dovecot/pigeonhole/blob/5a3f4bd672cc2fb9e755a4b09c4753ac86e15f99/src/lib-sieve/cmd-redirect.c#L569
>
> The result is the mail being forwarded, in this case, is now having 
> dual Message-ID and is not RFC 5322 compliant anymore and can be 
> rejected for this reason (hi, gmail?)
> https://www.spamresource.com/2022/08/gmail-weird-rfc-5322-bounces-and-what.html
>
> Some thoughts:
>
> - First, to be honest, I'm not sure gmail would accept the original 
> mail with the bogus Message-ID sent directly to their servers, but if 
> it was refused, I would assume that these senders would have fixed the 
> issue on their side so their message are delivered (unless there is 
> some whitelisting going on?)
>
> - What options could we have to resolve this?
>
> a) Having dovecot core to remove the Message-ID header line from the 
> mail if it is not going to consider it valid ? (So there is no dupe 
> headers when pigeonhole adds one?)
> b) Having pigeonhole check, when adding a new valid Message-ID, if 
> there is already one existing, and remove the bogus one ?

Hello,
In my opinion, an option c) should be considered.
Bogus or not, if a Message-ID is present in the header you should not 
touch it.
For it own use, dovecot should continue to not use it as it is bogus.The 
only thing to do is to warn in logs in the dovecot core.
In a forwarding scenario, you should not alter the existing Message-ID, 
you should not take the responsibility to fix someone else problem.
The bogus message ID key is ok for duplicate detection. The only risk is 
false trigger by another equal bogus Message-ID header. Bogus messages 
are bogus so ...
For the present case, it means that the check for the header presence 
should be done by pigeonhole directly, not relying on the dovecot core 
Message-ID validity check.
In the missing/not implemented/not drafted redirect-as-new (inline or 
attached) case which exiting in some systems, you will generate a 
completely new message with a fresh/compliant Message-ID.

Emmanuel.