3 Oct
2017
3 Oct
'17
8:49 p.m.
Grant Taylor <gtaylor(a)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)