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