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

> 
> 
> We are using sieve filter to redirect incoming mails to an external
> mailbox (gmail) an we are seeing some forwarded e-mails being rejected
> by gmail because of duplicate headers.
> 
How are you redirecting, like this[1]? I tested this ages ago. I am mostly
testing with own gmail account, so  can't imagine this not working. It was
an older 2.2 server I was testing this on.


[1]
if false # true
{
     redirect :copy "shit at gmail.com";
}

>
>How are you redirecting, like this[1]? I tested this ages ago. I am mostly
testing with own gmail account, so  can't imagine this not working. It was
an older 2.2 server I was testing this on.
>
>
>[1]
>if false # true
>{
>     redirect :copy "shit at gmail.com";
>}
>
Hello Marc,

It's redirected using the rule added by SOGo when you enable mail 
forwarding for the mailbox.
Basically it's only this line:

redirect "stuff at gmail.com";

The redirect works, the problem is gmail changed their anti spam 
policies and are since a few months rejecting messages that have 
duplicate mail headers and in this particular case, Message-ID.

So all the incoming mails that have a non-RFC compliant Message-ID are 
being added a secondary Message-ID by pigeonhole, before it is relayed 
to the target mailbox.

To reproduce the issue you need to have:

1) An incoming message with a non-RFC compliant Message-ID to your 
mailbox
2) A forward of your mailbox to a gmail account

I guess the double Message-ID thing in pigeonhole has always been there, 
but now it is more visible since gmail check for duplcate headers..


I would say the culprit is around here:
https://github.com/dovecot/pigeonhole/blob/1cb177cc2329cd565023c8f7a19872403b225793/src/lib-sieve/cmd-redirect.c#L390

and more precisely here:
https://github.com/dovecot/pigeonhole/blob/1cb177cc2329cd565023c8f7a19872403b225793/src/lib-sieve/cmd-redirect.c#L569

Even though the original message has a Message-ID, somehow msgdata->id 
seems to be empty so it adds one.
Maybe the function populating msgdata->id (whch TBH i wan't able to 
locate) is using some pattern to validate the Message-ID against the 
format specified in RFC and it doesn't match, so variable is then null.
But that's only my assumptions.

Kind regards.