Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing

On Fri, Nov 5, 2021 at 9:44 PM Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
wrote:

> On 11/4/21 10:07 PM, Magnus Hagander wrote:
> >
> >
> > On Thu, Nov 4, 2021 at 8:47 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org
> > <mailto:alvherre(at)alvh(dot)no-ip(dot)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.

--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/>
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>