Hi there,
I can confirm this behavior. A few months ago I introduced a milter which is checking for multiple headers when the RFC says that there just should be one of them For example "Message-Id".
I found the described problem in an email coming from Alibaba, which had an invalid "Message-Id" header. It didn't contain an "@" sign or similar. It was RFC-invalid.
This email was sent from Alibaba to a German email provider. There was a redirect at that email provider, pointing to my mailserver.
My server rejected the email because there were 2 "Message-Id" headers: The original invalid "Message-Id" header from Alibaba, and a new "Message-Id" header from the German provider, which seems to have been added during the redirect. There were "Dovecot-sieve"
headers in that mail, so my guess was that it happened because of Dovecot-sieve/pigeonhole implementation.
I contacted the email provider, asking for help. Asking if it really is a bug in pigeonhole (or maybe some other system at that provider, who knows). And I contacted Alibaba, so they fix the invalid "Message-Id". I got responses from both, but until now, as
far as I can see, it has not been fixed.
The best fix would be (if it really is a bug in pigeonhole), if pigeonhole fixes the problem, then it's fixed for all users of Dovecot. I guess Alibaba is not the only sender with an invalid "Message-ID" header, but that's the only one I saw.
Michael
Thanks a lot for your feedback. It comfort me that I'm maybe on the right track about this issue.
The mail I used to troubleshoot the issue was a mail from aliexpress containing a funky Message-ID. Probably the same people behind Aliexpress/Alibaba.
But for sure there are probably other mail senders that generate RFC-invalide Message-ID.
If Pigeonhole consider the Message-ID is bad and add it's own, it should maybe at least remove the original one... ?