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
|
| 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: