From mboxrd@z Thu Jan 1 00:00:00 1970 From: steffen@sdaoden.eu (Steffen Nurpmeso) Date: Wed, 04 Oct 2017 22:17:44 +0200 Subject: Mangled and non-mangled TUHS mail lists In-Reply-To: <9294cf0a-41bc-5f5a-7da9-ec9233c5848f@tnetconsulting.net> 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> <9294cf0a-41bc-5f5a-7da9-ec9233c5848f@tnetconsulting.net> Message-ID: <20171004201744.bRFv5%steffen@sdaoden.eu> Grant Taylor wrote: |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. Nonetheless it is notable that even the IETF uses subject prefixes for their own lists, for example [Spasm] (now dead). It is just too much politics and business interests and rooster, well, sometimes even pissings, wouldn't you agree there. I mean, it is a chain of trust: the user sends to the ML, the ML verifies DKIM, performs adjustments and applies DKIM on its own, including the stacked original data, but keeping From: intact. What to do with added MIME attachments? Into the great wide open: apply or use Content-ID, add a DKIM header which mentions all MIME parts of the original message in correct order, a DKIM verifier can use that to select the MIME parts of the original message and apply checksum verification on that very part only. Would work, huh? What is missing from that, Mr. Taylor? --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)