>
>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 "s...@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 "st...@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.
