Re: New email address

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Larry Rosenman <ler(at)lerctr(dot)org>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers-owner(at)postgresql(dot)org
Subject: Re: New email address
Date: 2015-11-24 19:57:19
Message-ID: 28012.1448395039@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Larry Rosenman <ler(at)lerctr(dot)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. In particular, [RFC5321] explicitly permits
modification or removal of the Return-Path header field in transit.
Signers MAY 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 sign all existing, non-
repeatable header fields. An alternative strategy is to sign only
header fields that are likely to be displayed to or otherwise be
likely to affect the processing of the message at the receiver. A
third strategy 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 not cover 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stefan Kaltenbrunner 2015-11-24 20:22:01 Re: New email address
Previous Message Tom Lane 2015-11-24 19:50:09 Re: New email address