public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] pgarchives: parser: handle messages in which Message-ID is missing
15+ messages / 7 participants
[nested] [flat]
* [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-03 17:02 Célestin Matte <[email protected]>
0 siblings, 2 replies; 15+ messages in thread
From: Célestin Matte @ 2021-11-03 17:02 UTC (permalink / raw)
To: [email protected]
Hello,
As surprising as it may seem, Message-ID is actually not a mandatory email field [1]. While most MTAs do add this field, some might not, and this will cause load_message.py to crash.
As a solution to this, when this field is missing, this patch:
- attempts to find a "Sent-Message-ID" header and use it as the Message-ID (a case I encountered when trying to import an old mbox)
- generates a new Message-ID if none exists, following (a simpler version of) [2].
[1] https://www.rfc-editor.org/rfc/rfc2822#section-3.6.4
[2] https://datatracker.ietf.org/doc/html/draft-ietf-usefor-message-id-00#section-3
Cheers,
--
Célestin Matte
Attachments:
[text/x-patch] 0001-parser-handler-messages-in-which-Message-ID-is-missi.patch (3.0K, 2-0001-parser-handler-messages-in-which-Message-ID-is-missi.patch)
download | inline diff:
From 36e6a6b67c7f64f524770a852587f8db072604a4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?C=C3=A9lestin=20Matte?= <[email protected]>
Date: Wed, 3 Nov 2021 17:09:01 +0100
Subject: [PATCH] parser: handle messages in which Message-ID is missing
Message-ID is not mandatory in emails. When such a message is imported,
attempt to use Resent-Message-ID instead if it exists, or generate a new
one.
---
loader/lib/parser.py | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/loader/lib/parser.py b/loader/lib/parser.py
index 171f197..21e1e48 100644
--- a/loader/lib/parser.py
+++ b/loader/lib/parser.py
@@ -1,6 +1,7 @@
import re
import datetime
import dateutil.parser
+import random
from email.parser import BytesParser
from email.header import decode_header, Header
@@ -28,13 +29,13 @@ class ArchivesParser(object):
# Look for a specific messageid. This means we might parse it twice,
# but so be it. Any exception means we know it's not this one...
try:
- if self.clean_messageid(self.decode_mime_header(self.get_mandatory('Message-ID'))) == msgid:
+ if self.clean_messageid(self.decode_mime_header(self.get_or_generate_messageid())) == msgid:
return True
except Exception:
return False
def analyze(self, date_override=None):
- self.msgid = self.clean_messageid(self.decode_mime_header(self.get_mandatory('Message-ID')))
+ self.msgid = self.clean_messageid(self.decode_mime_header(self.get_or_generate_messageid()))
self._from = self.decode_mime_header(self.get_mandatory('From'), True)
self.to = self.decode_mime_header(self.get_optional('To'), True)
self.cc = self.decode_mime_header(self.get_optional('CC'), True)
@@ -547,6 +548,25 @@ class ArchivesParser(object):
except ValueError as ve:
raise IgnorableException("Failed to decode header value '%s': %s" % (hdr, ve))
+ def get_or_generate_messageid(self):
+ x = self.msg["Message-ID"]
+ if x is None:
+ # If Message-ID is message, try using Resent-Message-ID instead
+ x = self.msg["Resent-Message-ID"]
+ if x is None:
+ # If Resent-Message-ID is missing too, forge a new Message-ID
+ # following a simpler version of
+ # https://datatracker.ietf.org/doc/html/draft-ietf-usefor-message-id-00#section-3
+ date_part = re.sub('[^A-Z0-9]', '', str(self.forgiving_date_decode(self.decode_mime_header(self.get_mandatory('Date')))))
+ random_part = random.getrandbits(64)
+ from_fqdn = self.decode_mime_header(self.get_mandatory('From'), True).split('@')
+ if len(from_fqdn) > 1:
+ fqdn = from_fqdn[1]
+ else:
+ fqdn = ""
+ x = "<" + str(date_part) + "." + str(random_part) + "@" + fqdn + ">"
+ return x
+
def get_mandatory(self, fieldname):
try:
x = self.msg[fieldname]
--
2.33.1
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-03 17:05 Célestin Matte <[email protected]>
parent: Célestin Matte <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Célestin Matte @ 2021-11-03 17:05 UTC (permalink / raw)
To: [email protected]
By the way, loader/load_message.py has a double crash issue, when importing a message raising an IgnorableException:
[...]
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/srv/pgarchives/local//loader/load_message.py", line 155, in <module>
log_failed_message(listid, "mbox", opt.mbox, ap, e)
File "/srv/pgarchives/local//loader/load_message.py", line 36, in log_failed_message
'err': str(str(err), 'us-ascii', 'replace'),
TypeError: decoding str is not supported
I don't understand what this line is supposed to do (removing non-ascii characters?), but a simple str(err) fixes the issue.
Cheers,
--
Célestin Matte
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-04 10:31 Magnus Hagander <[email protected]>
parent: Célestin Matte <[email protected]>
1 sibling, 2 replies; 15+ messages in thread
From: Magnus Hagander @ 2021-11-04 10:31 UTC (permalink / raw)
To: Célestin Matte <[email protected]>; +Cc: [email protected]
On Wed, Nov 3, 2021 at 6:02 PM Célestin Matte <[email protected]>
wrote:
> Hello,
>
> As surprising as it may seem, Message-ID is actually not a mandatory email
> field [1]. While most MTAs do add this field, some might not, and this will
> cause load_message.py to crash.
> As a solution to this, when this field is missing, this patch:
> - attempts to find a "Sent-Message-ID" header and use it as the Message-ID
> (a case I encountered when trying to import an old mbox)
> - generates a new Message-ID if none exists, following (a simpler version
> of) [2].
>
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.
It may be something that should get documented somewhere as a requirement.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-04 10:32 Magnus Hagander <[email protected]>
parent: Magnus Hagander <[email protected]>
1 sibling, 0 replies; 15+ messages in thread
From: Magnus Hagander @ 2021-11-04 10:32 UTC (permalink / raw)
To: Célestin Matte <[email protected]>; +Cc: [email protected]
On Thu, Nov 4, 2021 at 11:31 AM Magnus Hagander <[email protected]> wrote:
>
>
> On Wed, Nov 3, 2021 at 6:02 PM Célestin Matte <[email protected]>
> wrote:
>
>> Hello,
>>
>> As surprising as it may seem, Message-ID is actually not a mandatory
>> email field [1]. While most MTAs do add this field, some might not, and
>> this will cause load_message.py to crash.
>> As a solution to this, when this field is missing, this patch:
>> - attempts to find a "Sent-Message-ID" header and use it as the
>> Message-ID (a case I encountered when trying to import an old mbox)
>> - generates a new Message-ID if none exists, following (a simpler version
>> of) [2].
>>
>
> 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.
>
Sorry, I mean pgarchives here of course, not pglister :)
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-04 10:35 Magnus Hagander <[email protected]>
parent: Célestin Matte <[email protected]>
0 siblings, 1 reply; 15+ messages in thread
From: Magnus Hagander @ 2021-11-04 10:35 UTC (permalink / raw)
To: Célestin Matte <[email protected]>; +Cc: [email protected]
On Wed, Nov 3, 2021 at 6:05 PM Célestin Matte <[email protected]>
wrote:
> By the way, loader/load_message.py has a double crash issue, when
> importing a message raising an IgnorableException:
>
> [...]
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
> File "/srv/pgarchives/local//loader/load_message.py", line 155, in
> <module>
> log_failed_message(listid, "mbox", opt.mbox, ap, e)
> File "/srv/pgarchives/local//loader/load_message.py", line 36, in
> log_failed_message
> 'err': str(str(err), 'us-ascii', 'replace'),
> TypeError: decoding str is not supported
>
> I don't understand what this line is supposed to do (removing non-ascii
> characters?), but a simple str(err) fixes the issue.
>
It's supposed to remove non-ascii characters.
I think this is a leftover from the py2->py3 conversion. It looks like an
overenthusiastic regexp replacement in the 2to3 tool. See bb5775ef where it
came from. I'll go change it to jut str(err).
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-04 15:34 Célestin Matte <[email protected]>
parent: Magnus Hagander <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Célestin Matte @ 2021-11-04 15:34 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; +Cc: [email protected]
> 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?
> It may be something that should get documented somewhere as a requirement.
I'll write a small readme for pgarchives
--
Célestin Matte
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-04 15:46 Célestin Matte <[email protected]>
parent: Magnus Hagander <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Célestin Matte @ 2021-11-04 15:46 UTC (permalink / raw)
To: [email protected]
> It's supposed to remove non-ascii characters.
>
> I think this is a leftover from the py2->py3 conversion. It looks like an overenthusiastic regexp replacement in the 2to3 tool. See bb5775ef where it came from. I'll go change it to jut str(err).
Right. Beware that there are other similar failing conversions in the same commit on lines in loader/lib/parser.py that should be addressed as well
--
Célestin Matte
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-04 19:47 Alvaro Herrera <[email protected]>
parent: Célestin Matte <[email protected]>
0 siblings, 2 replies; 15+ messages in thread
From: Alvaro Herrera @ 2021-11-04 19:47 UTC (permalink / raw)
To: Célestin Matte <[email protected]>; +Cc: Magnus Hagander <[email protected]>; [email protected]
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?
Maybe pglister should refuse to deliver messages that don't contain
a Message-Id.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
"Ninguna manada de bestias tiene una voz tan horrible como la humana" (Orual)
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-04 19:56 Christophe Pettus <[email protected]>
parent: Alvaro Herrera <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Christophe Pettus @ 2021-11-04 19:56 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Célestin Matte <[email protected]>; Magnus Hagander <[email protected]>; [email protected]
> On Nov 4, 2021, at 12:47, Alvaro Herrera <[email protected]> wrote:
> Maybe pglister should refuse to deliver messages that don't contain
> a Message-Id.
That seems reasonable. If there's no message ID by the time pglister gets it, something is pretty broken along the path from the sender to us.
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-04 20:28 Tom Lane <[email protected]>
parent: Christophe Pettus <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Tom Lane @ 2021-11-04 20:28 UTC (permalink / raw)
To: Christophe Pettus <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Célestin Matte <[email protected]>; Magnus Hagander <[email protected]>; [email protected]
Christophe Pettus <[email protected]> writes:
>> On Nov 4, 2021, at 12:47, Alvaro Herrera <[email protected]> wrote:
>> Maybe pglister should refuse to deliver messages that don't contain
>> a Message-Id.
> That seems reasonable. If there's no message ID by the time pglister gets it, something is pretty broken along the path from the sender to us.
FWIW, I've long used a spam filtering rule that sends anything without
a message ID, or with a forged local message ID, straight to /dev/null.
It's quite effective, and I've not seen it eat any valid traffic.
regards, tom lane
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-04 21:07 Magnus Hagander <[email protected]>
parent: Alvaro Herrera <[email protected]>
1 sibling, 2 replies; 15+ messages in thread
From: Magnus Hagander @ 2021-11-04 21:07 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Célestin Matte <[email protected]>; [email protected]
On Thu, Nov 4, 2021 at 8:47 PM Alvaro Herrera <[email protected]>
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.
--
Magnus Hagander
Me: https://www.hagander.net/ <http://www.hagander.net/;
Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/;
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-05 11:31 Célestin Matte <[email protected]>
parent: Magnus Hagander <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Célestin Matte @ 2021-11-05 11:31 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; Alvaro Herrera <[email protected]>; +Cc: [email protected]
> 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.
After some tests, I do have a very few number of non-spam examples (3 emails from 2 different people in a postfix+mailman mbox of 5k emails), but they date from 2003-2007.
Exim already handles empty Message-IDs by default by generating them [1], although it will let a message with Resent-Message-ID pass through as-if. I tested such a case, and pglister seems to actually drop the message (or fail silently).
[1]: https://www.exim.org/exim-html-current/doc/html/spec_html/ch-message_processing.html#SECID226
--
Célestin Matte
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-05 13:00 Justin Clift <[email protected]>
parent: Célestin Matte <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Justin Clift @ 2021-11-05 13:00 UTC (permalink / raw)
To: Célestin Matte <[email protected]>; +Cc: Magnus Hagander <[email protected]>; Alvaro Herrera <[email protected]>; [email protected]
On 2021-11-05 22:31, Célestin Matte wrote:
>> 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?
As a data point, I'm pretty sure it was the message-id field
being missing from emails sent by scan.co.uk (a UK computer
retailer) a while back, which caused their non-delivery to
the mail servers here (@postgresql.org).
So, being that we bounce them, it wouldn't at all surprise me
that there's not much presence in our archives. :)
+ Justin
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-05 20:44 Stefan Kaltenbrunner <[email protected]>
parent: Magnus Hagander <[email protected]>
1 sibling, 1 reply; 15+ messages in thread
From: Stefan Kaltenbrunner @ 2021-11-05 20:44 UTC (permalink / raw)
To: Magnus Hagander <[email protected]>; Alvaro Herrera <[email protected]>; +Cc: Célestin Matte <[email protected]>; [email protected]
On 11/4/21 10:07 PM, Magnus Hagander wrote:
>
>
> On Thu, Nov 4, 2021 at 8:47 PM Alvaro Herrera <[email protected]
> <mailto:[email protected]>> 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.
So the reason why pglister is not seeing them a lot is because we dont
accept them upstream, not that they dont exist in the wild...
Though the ones in the wild seem to be "not very useful"...
Stefan
Stefan
^ permalink raw reply [nested|flat] 15+ messages in thread
* Re: [PATCH] pgarchives: parser: handle messages in which Message-ID is missing
@ 2021-11-06 17:02 Magnus Hagander <[email protected]>
parent: Stefan Kaltenbrunner <[email protected]>
0 siblings, 0 replies; 15+ messages in thread
From: Magnus Hagander @ 2021-11-06 17:02 UTC (permalink / raw)
To: Stefan Kaltenbrunner <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Célestin Matte <[email protected]>; [email protected]
On Fri, Nov 5, 2021 at 9:44 PM Stefan Kaltenbrunner <[email protected]>
wrote:
> On 11/4/21 10:07 PM, Magnus Hagander wrote:
> >
> >
> > On Thu, Nov 4, 2021 at 8:47 PM Alvaro Herrera <[email protected]
> > <mailto:[email protected]>> 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/;
^ permalink raw reply [nested|flat] 15+ messages in thread
end of thread, other threads:[~2021-11-06 17:02 UTC | newest]
Thread overview: 15+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-11-03 17:02 [PATCH] pgarchives: parser: handle messages in which Message-ID is missing Célestin Matte <[email protected]>
2021-11-03 17:05 ` Célestin Matte <[email protected]>
2021-11-04 10:35 ` Magnus Hagander <[email protected]>
2021-11-04 15:46 ` Célestin Matte <[email protected]>
2021-11-04 10:31 ` Magnus Hagander <[email protected]>
2021-11-04 10:32 ` Magnus Hagander <[email protected]>
2021-11-04 15:34 ` Célestin Matte <[email protected]>
2021-11-04 19:47 ` Alvaro Herrera <[email protected]>
2021-11-04 19:56 ` Christophe Pettus <[email protected]>
2021-11-04 20:28 ` Tom Lane <[email protected]>
2021-11-04 21:07 ` Magnus Hagander <[email protected]>
2021-11-05 11:31 ` Célestin Matte <[email protected]>
2021-11-05 13:00 ` Justin Clift <[email protected]>
2021-11-05 20:44 ` Stefan Kaltenbrunner <[email protected]>
2021-11-06 17:02 ` Magnus Hagander <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox