Larry Rosenman <ler@lerctr.org> writes:
> On 2015-11-24 13:43, Alvaro Herrera wrote:
>> Of course, removing all the "List-" headers *and* our custom footers is
>> a huge step backwards in terms of mailing list functionality :-( Also,
>> removing the [HACKERS] etc tags will annoy some people, for sure.
> You don't have to remove the List- headers. DKIM says what headers it's
> using.
Yeah. RFC 6376 is worth a quick look if you want to opine knowledgeably
about this. Basically, the DKIM crypto hash covers the message body plus
those header fields enumerated in the DKIM-Signature header, and 6376
gives this advice:
The From header field MUST be signed (that is, included in the "h=" tag of the resulting DKIM-Signature header
field). Signers SHOULD NOT sign an existing header field likely to be legitimately modified or removed in transit.
Inparticular, [RFC5321] explicitly permits modification or removal of the Return-Path header field in transit.
SignersMAY include any other header fields present at the time of signing at the discretion of the Signer.
INFORMATIVE OPERATIONS NOTE: The choice of which header fields to sign is non-obvious. One strategy is to
signall existing, non- repeatable header fields. An alternative strategy is to sign only header fields that
arelikely to be displayed to or otherwise be likely to affect the processing of the message at the receiver. A
thirdstrategy is to sign only "well-known" headers. Note that Verifiers may treat unsigned header fields with
extreme skepticism, including refusing to display them to the end user or even ignoring the signature if it does
notcover certain header fields. For this reason, signing fields present in the message such as Date, Subject,
Reply-To,Sender, and all MIME header fields are highly advised.
I think the advice to sign Reply-To and Sender is rather ill-advised,
particularly the latter, as signing that absolutely would break mailing
list forwarding.
regards, tom lane
