The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: steffen@sdaoden.eu (Steffen Nurpmeso)
Subject: Mangled and non-mangled TUHS mail lists
Date: Wed, 04 Oct 2017 22:17:44 +0200	[thread overview]
Message-ID: <20171004201744.bRFv5%steffen@sdaoden.eu> (raw)
In-Reply-To: <9294cf0a-41bc-5f5a-7da9-ec9233c5848f@tnetconsulting.net>

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


  parent reply	other threads:[~2017-10-04 20:17 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-01  3:25 Warren Toomey
2017-10-01 14:00 ` Clem Cole
2017-10-01 14:08   ` Don Hopkins
2017-10-02  1:01 ` Dave Horsfall
2017-10-02  8:22   ` jason-tuhs
2017-10-02 12:38     ` Steve Nickolas
2017-10-02 13:34       ` David Ryskalczyk
2017-10-03  0:51         ` Dave Horsfall
2017-10-03  2:19           ` Steve Nickolas
2017-10-03  3:25             ` Grant Taylor
2017-10-03  3:33               ` Dave Horsfall
2017-10-03  3:55                 ` Grant Taylor
2017-10-03  4:17                   ` Dave Horsfall
2017-10-03  4:12                 ` Kurt H Maier
2017-10-03  7:40                   ` Ian Zimmerman
2017-10-03 14:08                 ` Steffen Nurpmeso
2017-10-03 18:20                   ` Grant Taylor
2017-10-03 18:43                     ` Ian Zimmerman
2017-10-03 21:59                       ` Grant Taylor
2017-10-03 18:49                     ` Steffen Nurpmeso
2017-10-03 21:54                       ` Grant Taylor
2017-10-03 22:00                         ` Mangled and non-mangled TUHS mail lists [ enough already? ] Jon Steinhart
2017-10-04 20:17                         ` Steffen Nurpmeso [this message]
2017-10-04  2:28                       ` Mangled and non-mangled TUHS mail lists Dave Horsfall
2017-10-04 20:59                         ` Steffen Nurpmeso
2017-10-03 10:12               ` Steve Nickolas
2017-10-03 19:21                 ` Bakul Shah

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171004201744.bRFv5%steffen@sdaoden.eu \
    --to=steffen@sdaoden.eu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).