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

Am 01-Oct-2022 14:00:45 +0200 schrieb sriccio@swisscenter.com:

>You wrote in the original email the message was rejected. Sorry I don't have login access to my gmail test account anymore since the google @#$%@#$% wanted to have me add a phone number.

In my original post I said that gmail was rejecting the forwards because
of duplicate headers, and that the duplicate header seems to be a
Message-ID added by pigeonhole when it's "not happy" with the original
mail Message-ID.

I probably failed to explain the issue clearly and sorry for that.

Thank you anyway for trying to help :)