Re: New email address - Mailing list pgsql-hackers

From Tom Lane
Subject Re: New email address
Date
Msg-id 8163.1448477704@sss.pgh.pa.us
Whole thread Raw
In response to Re: New email address  (Greg Stark <stark@mit.edu>)
Responses Re: New email address  (Greg Stark <stark@mit.edu>)
List pgsql-hackers
Greg Stark <stark@mit.edu> writes:
> It's a reasonable idea for mailing list software to put the list in
> Sender given that it's the "agent responsible for the actual
> transmission of the message" as RFC2822 specifies.

Right.

> But my point was that while the RFC says what to put there there's
> absolutely no reference anywhere for when the information should cause
> any MUA or MTA to behave differently.

Agreed.  To my mind that's a reason why Sender should not be DKIM-signed.
Unfortunately, RFC 6376 explicitly suggests doing so ... and it looks like
some people are taking that advice.

I did a bit of grepping in my PG-lists inbox, and what I find is that
about 19000 messages out of the 55000 I have saved since 2012 have
DKIM-Signature lines (a lot more than I would have guessed, actually),
and about 1400 of those list Sender as one of the lines to be signed.
So if we override Sender we'll be breaking signatures on those.  On the
other hand, it looks like a nontrivial fraction of these things are broken
anyway.  I counted header field mentions in these lines:
     1 DKIM-Signature        <- explicitly forbidden by DKIM RFC     1 X-QQ-BUSINESS-ORIGIN     1 X-QQ-FEAT     1
X-QQ-MIME    1 X-QQ-Mailer     1 X-QQ-SENDSIZE     1 X-QQ-SSF     1 X-QQ-STYLE     1 X-QQ-WAPMAIL     1 X-QQ-mid     1
in-response-to    1 newsgroups     2 Content-Description     2 List-Archive        <- guaranteed to break any mailing
list    2 List-Help     2 List-Id     2 List-Owner     2 List-Post     2 List-Subscribe     2 List-Unsubscribe     2
Resent-Cc    2 Resent-Date     2 Resent-Message-ID     2 Resent-Sender     2 Resent-To     2 x-forwarded-message-id
3Resent-From     3 importance     4 Content-ID     5 X-Originating-IP     6 X-Yahoo-Newman-Id     7 thread-topic     8
Disposition-Notification-To    9 mail-followup-to    11 X-Yahoo-Newman-Property    11 X-Yahoo-SMTP    12 organization
13 x-enigmail-version    20 Thread-Index    26 x-mimeole    26 x-msmail-priority    27 X-Priority    51 accept-language
  68 Content-Language   230 x-google-sender-auth   278 X-Rocket-MIMEInfo   300 X-YMail-OSG   401 X-Mailer   433
Received   <- guaranteed to fail validation at recipient   546 x-received    <- guaranteed to fail validation at
recipient       (there is no overlap in the above two groups)   598 content-disposition  1313 Reply-To  1432 User-Agent
1444 Sender  1466 x-sasl-enc  3159 Content-Transfer-Encoding 16405 CC 17530 In-Reply-To 17532 References 19070
MIME-Version19075 Message-ID 19090 Content-Type 19234 To 19419 Date 19635 Subject 19651 From
 

So the number of people signing Sender is only marginally more than the
number of people who are clueless enough to sign Received lines.
Maybe we can write off the Sender signers as people who might get a clue
eventually.  I don't have an easy way to identify which sources are
sending that, though.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bug in numeric multiplication
Next
From: Peter Geoghegan
Date:
Subject: Re: Using quicksort for every external sort run