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

[Sébastien Riccio]

>
>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.
>
>

Hello Emmanuel,

Yes, this sounds to me like a reasonable approach.

Kind regards