From mboxrd@z Thu Jan 1 00:00:00 1970 From: steffen@sdaoden.eu (Steffen Nurpmeso) Date: Tue, 03 Oct 2017 20:49:19 +0200 Subject: Mangled and non-mangled TUHS mail lists In-Reply-To: <472d5571-8093-e02c-4478-a97accc8e632@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> Message-ID: <20171003184919.1QJzu%steffen@sdaoden.eu> Grant Taylor wrote: |On 10/03/2017 08:08 AM, Steffen Nurpmeso wrote: |> It is a bit of a pity, since almost all MLs really worth reading |> use this tagging (e.g., ih, leapsecs, tz, the security lists, |> groff, as well as pcc and tinycc-devel, to name a few). | |I think that modifying the subject to add a tag is a perfectly valid |thing. As such, provisions should make such modifications /possible/. |Then leave the choice of doing so or not up to each list's administrator. As has happened recently. Sure. |> And DKIM |> is no problem at all if you use G....e groups over HTTPS and give |> the business some opportunities to actually make some of the money |> necessary to drive the environment you use, HEH??? | |I think that GG is an option. Just an option that I choose not to use. | |I also vehemently in the option to host things yourself. - Email is |not too complex that people can't successfully run their own server if |they want to do so. | |> DKIM should |> have been designed to create DKIM envelopes, so that lists could |> simply create an encapsulating DKIM layer, and all would be fine. | |I believe that Mailman has an option to attach the DKIM signed message |much like I (mis?)understand the wrapper that you're talking about. | |In such case, DKIM has no say. DKIM is designed to validate that a |message has not been modified in source. - The wrapper message is a |new message that happens to have an attachment. Since DKIM filters are |looking for a DKIM-Signature header in the outer most message, it does |not matter what's in the inner / attached message. | |I also staunchly believe that Mailing lists are an entity unto |themselves. Said entity is what sends the emails, not me. As such, my |opinion is that said entity should draft completely new messages using |textual content from source material that I provided. Thus there is |nothing about the original message envelope to be a problem. I was not involved in the process of creating that standard, nor have i yet really thought about the problem, and especially not did i have to manage real-world problems originating in that. |This also means that mailing lists could support things like subject |modification / SPF / DKIM / DMARC / ARC / S/MIME / PGP, etc. directly. 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. |But ... that's just me and my opinion. Yep. Let's just stop draggin' my heart around. --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)