On 2021-Nov-04, Célestin Matte wrote:
> > I don't think this should be the responsibility of pglister. As you
> > say, "most MTAs do add this field" -- and the solution is to
> > configure the MTA to do this. We already rely on the MTA to get a
> > lot of other important things right.
>
> But then these messages will get delivered by pglister but pgarchives
> will fail to archive them, although they do not actually break
> requirements. Shouldn't we follow the RFC here?
I agree that the scenario is a problem, per below. I don't agree that making up an id is a solution to that problem.
Maybe pglister should refuse to deliver messages that don't contain
a Message-Id.
It should. I actually thought it did already, but apparently it does not. I guess we've only ever used it under properly configured MTAs :)
Have you actually come across any case where a *proper* non-spam message is sent without a message-id and passes through actual mailservers on the way?
Looking through the approximately 1.4 million mails in the postgres list archives, not a single one has a message-id generated by the archives server MTA (which is configured to generate it). Not a single one by our inbound relay servers. And exactly one by the pglister server -- which turns out to be a bounce that ended up in the archives because of a misconfiguration back in 2018 that's not visible in the public archives.