On 11/4/21 10:07 PM, Magnus Hagander wrote:
>
>
> On Thu, Nov 4, 2021 at 8:47 PM Alvaro Herrera <alvherre@alvh.no-ip.org
> <mailto:alvherre@alvh.no-ip.org>> wrote:
>
> 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.
as mentioned down-thread by Justin Clift we have been plain rejecting
mails without a message-id on the postgresql.org inbound relays since
March 27th 2012(!) according to our repo and the number of rejects due
to that rule is actually not-insignificant (approximately 200-400/day
with the majority being for a very small number of bounce generating
senders) but the number of complaints is also approaching (almost) zero.
Oh I forgot about that one. That clearly explains why I didn't find anything *after* 2012 in the archives -- but in my defence, we don't have any from before that either :)
I thought we actually manufactured a message-id on them rather than reject them, but I guess I was confusing it with how we handle email injected internally where I think we do that.