From mboxrd@z Thu Jan 1 00:00:00 1970 From: gtaylor@tnetconsulting.net (Grant Taylor) Date: Tue, 3 Oct 2017 15:54:44 -0600 Subject: Mangled and non-mangled TUHS mail lists In-Reply-To: <20171003184919.1QJzu%steffen@sdaoden.eu> References: <20171001032536.GB31930@minnie.tuhs.org> <209ed252-49ff-aff4-dd0a-614397907418@tnetconsulting.net> <20171003140853.IrkS4%steffen@sdaoden.eu> <472d5571-8093-e02c-4478-a97accc8e632@tnetconsulting.net> <20171003184919.1QJzu%steffen@sdaoden.eu> Message-ID: <9294cf0a-41bc-5f5a-7da9-ec9233c5848f@tnetconsulting.net> On 10/03/2017 12:49 PM, Steffen Nurpmeso wrote: > But mailing-lists are a, possibly the most vivid part of email > since a very long time, and designing a standard that does not > play nice with mailing-lists is grotesque. I was not thinking > about enwrapping the message, but rather of a mechanism like the > stacking of Received: headers which also follows standard. > Something like renaming all DKIM headers stackwise (DKIM -> > DKIM-LVL1, DKIM-LVL1 -> DKIM-LVL2 etc.) and creating new DKIM > headers for the updated message, also covering the DKIM stack. > Something like that. Like this the existence of a stack that > would need to become unrolled would be known to verifying parties, > which were all newly created for this then new standard. A stack > level could even be used to save-away tracked headers, like > Subject:, too. But SHOULD not. ^.^ Anyway. I recently became aware that DKIM does have an option (l= length parameter) to specify how much of the body is covered by the DKIM signature. I wonder if this would help in what you're describing. It's my understanding that the motivation behind it is to allow things to append content to the body without breaking the DKIM signature. Granted, it would still protect other headers. -- Grant. . . . unix || die -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3717 bytes Desc: S/MIME Cryptographic Signature URL: