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