> On Nov 20, 2017, at 2:18 PM, Piotr Stefaniak <postgres@piotr-stefaniak.me> wrote:
>
> On 2017-11-20 21:03, Tom Lane wrote:
>> "Joshua D. Drake" <jd@commandprompt.com> writes:
>>> On 11/20/2017 11:40 AM, Magnus Hagander wrote:
>>> One thing I would note is that there is no longer a footer that
>>> tells people what to do if they want to unsubscribe. Perhaps one
>>> thing that could be done is a header (for a temporary time period)
>>> that says:
>>> The mailing list software of Postgresql.org has changed. Please see
>>> this page on instructions on how to manage your subscription and
>>> filters. And then after the temporary time period that becomes a
>>> footer?
>>
>> Unfortunately, the removal of the footer is a feature not a bug. In
>> order to be DKIM-compatible and thus help avoid becoming classified
>> as spammers, we can't mangle message content anymore, just like we
>> can't mangle the Subject: line.
> I don't miss the footers, but see RFC 6376, "5.3.1. Body Length Limits".
> Two fragments quoted are copied below:
That's poor practice, for several reasons - replay attacks with added content
and it being an extremely rare practice that's likely to trigger bugs in DKIM
validation are two. The latter is the much bigger deal.
It also doesn't help much for most MIME encoded mail (including base64
encoded plain text, like the mail I'm replying to).
Pretending those paragraphs aren't there is the right thing to do.
Cheers, Steve
>
>> A body length count MAY be specified to limit the signature
>> calculation to an initial prefix of the body text, measured in
>> octets. If the body length count is not specified, the entire message
>> body is signed.
>
>> INFORMATIVE RATIONALE: This capability is provided because it is very
>> common for mailing lists to add trailers to messages (e.g.,
>> instructions on how to get off the list). Until those messages are
>> also signed, the body length count is a useful tool for the Verifier
>> since it can, as a matter of policy, accept messages having valid
>> signatures with extraneous data.