Mangled and non-mangled TUHS mail lists

[steffen@sdaoden.eu (Steffen Nurpmeso)]

Grant Taylor <gtaylor at tnetconsulting.net> 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)