Re: New email address

Greg Stark <stark(at)mit(dot)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
3 Resent-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-Version
19075 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