Mangled and non-mangled TUHS mail lists

Mangled and non-mangled TUHS mail lists

[Warren Toomey]

All, there are now two variants of the TUHS mailing list. E-mail sent
to tuhs at tuhs.org will propagate to both of them.

The main TUHS list now:
  - doesn't strip incoming DKIM headers
  - doesn't alter the From: line
  - doesn't alter the Subject: line
and hopefully will keep most mail systems happy.

The alternative, "mangled", TUHS list:
  - strips incoming DKIM headers
  - alters the From: line
  - alters the Subject: line to say [TUHS]
  - puts in DKIM headers once this is done
and hopefully will keep most mail systems happy but in a different way.

You can choose to belong to either list, just send me an e-mail if
you want to be switched to the other one. But be patient to start with
as there will probably be quite a few wanting to change.

Cheers, Warren

Mangled and non-mangled TUHS mail lists

[Clem Cole]

Warren,

Thank you for your time and efforts.   We all know this does not just
happen and because of your dedication we all reap many rewards.   Our
thanks is not enough I know, but it was I can offer here.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171001/45b5d0b1/attachment.html>

Mangled and non-mangled TUHS mail lists

[Don Hopkins]

Here here! That DKIM stuff is a PITA. Thanks, Warren.

-Don

> On 1 Oct 2017, at 16:00, Clem Cole <clemc at ccc.com> wrote:
> 
> Warren,
> 
> Thank you for your time and efforts.   We all know this does not just happen and because of your dedication we all reap many rewards.   Our thanks is not enough I know, but it was I can offer here.
> 
> Clem

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171001/2e943c40/attachment-0001.html>

Mangled and non-mangled TUHS mail lists

[Dave Horsfall]

On Sun, 1 Oct 2017, Warren Toomey wrote:

> The main TUHS list now:
> - doesn't strip incoming DKIM headers
> - doesn't alter the From: line
> - doesn't alter the Subject: line
> and hopefully will keep most mail systems happy.

I was under the impression that the main list would remain as it was,
and those with fussy clients would use the new one.

> The alternative, "mangled", TUHS list:
> - strips incoming DKIM headers
> - alters the From: line
> - alters the Subject: line to say [TUHS]
> - puts in DKIM headers once this is done
> and hopefully will keep most mail systems happy but in a different way.

I really like seeing the "[TUHS]" tag (I can optically sort mailing lists) 
so I'll probably migrate, but I'll wait a bit for them to settle down.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

Mangled and non-mangled TUHS mail lists

[jason-tuhs]

>> The main TUHS list now:
>> [...]
>> - doesn't alter the Subject: line

> I was under the impression that the main list would remain as it was, 
> and those with fussy clients would use the new one.

+1

All else being equal, I would prefer the old list retain the old behaviour 
(i.e., to add the "[TUHS]" string to the Subject line) if possible.

But if there's a strong reason to prefer to change the behaviour of the 
old list (which, based on the Subject lines, still seems to have the 
majority of users), that's fine to.

I really appreciate all the contributions from everyone who participates 
on this list, and especially Warren for his onoing work to maintain the 
list and the related resources.

So thanks!

Cheers.


  -Jason

Mangled and non-mangled TUHS mail lists

[Steve Nickolas]

On Mon, 2 Oct 2017, jason-tuhs at shalott.net wrote:

> All else being equal, I would prefer the old list retain the old behaviour 
> (i.e., to add the "[TUHS]" string to the Subject line) if possible.

Same.  My mailbox gets a lot of input from a lot of places and I generally 
use the subject line to optically filter - the tag really helps.

-uso.

Mangled and non-mangled TUHS mail lists

[David Ryskalczyk]

Unfortunately if DKIM is to be preserved, and the DKIM signature covers the Subject line (which it usually does), changing the Subject would break the signature and cause the bouncing problem to start happening again.

Looking at Warren's message at the beginning of this thread, I see the following DKIM signature:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tuhs.org; s=dkim;
	t=1506828345; bh=JrrWTXe8/s8WUvyQhbjteoiXK8kMtqkyNHZyzoe+YwE=;
	h=Date:From:To:Subject:List-Id:List-Unsubscribe:List-Archive:
	 List-Post:List-Help:List-Subscribe:From;
	b=1bchv7u0p3glxS5aOdV2a2LcTPR/UNiVdxne762fZ8jTn8/PY6UDE0CEqfP1rS20G
	 t6uVy6iNk/xoDDKPeKGH4Tt8lSKqujoN682dKcAkHsM8/1ADamNo9ep/J7qiLUQIm7
	 62+lEKp7NZL8zsA2H+5iXtlcuKKIWJ3cTvhdhFLA=

This means that changing any of the headers listed under h= will break the signature (and cause bounces). This unfortunately includes the Subject.

For lists the alter the From: line, I prefer if they put the original From: address in the Cc: line as that means a reply-all goes both to the list and the originator. However I'm not sure whether this will cause DKIM issues as well (I haven't dug deep enough).

There's some discussion of this in RFC6377, unfortunately without a good solution given.

David

> On Oct 2, 2017, at 8:38 AM, Steve Nickolas <usotsuki at buric.co> wrote:
> 
> On Mon, 2 Oct 2017, jason-tuhs at shalott.net wrote:
> 
>> All else being equal, I would prefer the old list retain the old behaviour (i.e., to add the "[TUHS]" string to the Subject line) if possible.
> 
> Same.  My mailbox gets a lot of input from a lot of places and I generally use the subject line to optically filter - the tag really helps.
> 
> -uso.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171002/8b129567/attachment-0001.html>

Mangled and non-mangled TUHS mail lists

[Dave Horsfall]

On Mon, 2 Oct 2017, David Ryskalczyk wrote:

> For lists the alter the From: line, I prefer if they put the original 
> From: address in the Cc: line as that means a reply-all goes both to the 
> list and the originator. However I'm not sure whether this will cause 
> DKIM issues as well (I haven't dug deep enough).

I really hate it when people use reply-all and are too lazy to edit the 
recipient list; I get my copy via the list, thank you, and I don't need my 
own personal copy as well (there's a reason for the Reply-To: header).

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

Mangled and non-mangled TUHS mail lists

[Steve Nickolas]

On Tue, 3 Oct 2017, Dave Horsfall wrote:

> On Mon, 2 Oct 2017, David Ryskalczyk wrote:
>
>> For lists the alter the From: line, I prefer if they put the original From: 
>> address in the Cc: line as that means a reply-all goes both to the list and 
>> the originator. However I'm not sure whether this will cause DKIM issues as 
>> well (I haven't dug deep enough).
>
> I really hate it when people use reply-all and are too lazy to edit the 
> recipient list; I get my copy via the list, thank you, and I don't need my 
> own personal copy as well (there's a reason for the Reply-To: header).

For me at least, in such cases, I have never gotten duplicates.

-uso.

Mangled and non-mangled TUHS mail lists

[Grant Taylor]

On 10/02/2017 08:19 PM, Steve Nickolas wrote:
> For me at least, in such cases, I have never gotten duplicates.

Steve:

Do you receive the email from the list?  Or the person that hit 
Reply-to-All?

Mailman has a feature to not send you a copy from the list if you were a 
direct recipient (To or Cc.)

Dave:

You might consider a filter that will filter messages (to trash so it's 
recoverable?) to you and to the list.  That way you would rely on the 
list copy.  (But you could fetch the message out of trash if you needed to.)



-- 
Grant. . . .
unix || die

Mangled and non-mangled TUHS mail lists

[Dave Horsfall]

On Mon, 2 Oct 2017, Grant Taylor wrote:

> Dave:
>
> You might consider a filter that will filter messages (to trash so it's 
> recoverable?) to you and to the list.  That way you would rely on the list 
> copy.  (But you could fetch the message out of trash if you needed to.)

Yeah, I did use a Procmail filter for that, but Procmail is dead.  I must
take a closer look at Sieve.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

Mangled and non-mangled TUHS mail lists

[Grant Taylor]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

On 10/02/2017 09:33 PM, Dave Horsfall wrote:
> Yeah, I did use a Procmail filter for that, but Procmail is dead.  I must 
> take a closer look at Sieve.

Please don't tell my (zombie?) Procmail that.  I've got thousands 2300 
lines of Procmail that I'm still happily using every single day.

I keep bumping into Sieve.  I've not had a reason to migrate to it yet.



-- 
Grant. . . .
unix || die

Mangled and non-mangled TUHS mail lists

[Kurt H Maier]

On Tue, Oct 03, 2017 at 02:33:38PM +1100, Dave Horsfall wrote:
> 
> Yeah, I did use a Procmail filter for that, but Procmail is dead.  I must
> take a closer look at Sieve.
> 

Courier's maildrop MDA is also still developed, and has the advantage of
not being another network protocol to manage.

khm

Mangled and non-mangled TUHS mail lists

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

On Mon, 2 Oct 2017, Grant Taylor wrote:

>> Yeah, I did use a Procmail filter for that, but Procmail is dead.  I 
>> must take a closer look at Sieve.
>
> Please don't tell my (zombie?) Procmail that.  I've got thousands 2300 
> lines of Procmail that I'm still happily using every single day.
>
> I keep bumping into Sieve.  I've not had a reason to migrate to it yet.

Even the last maintainer advises against using it:

https://en.wikipedia.org/wiki/Procmail

``Procmail is stable, but no longer maintained.[1] Users who wish to use a
   maintained program are advised by procmail's author, Philip Guenther,[2]
   to use an alternative tool.''

``Procmail was an early example of a mail filtering tool and language.
   Procmail is no longer maintained and has unfixed security
   vulnerabilities. Procmail's last maintainers suggest using alternative
   tools.''

Given FreeBSD's philosophy re: dead ports, I guess it will be removed
soon.

With a mailserver facing the Internet, the last thing I need are security
vulnerabilities...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

Mangled and non-mangled TUHS mail lists

[Ian Zimmerman]

On 2017-10-02 21:12, Kurt H Maier wrote:

> Courier's maildrop MDA is also still developed, and has the advantage
> of not being another network protocol to manage.

Sieve doesn't necessarily imply another protocol.  Do not confuse Sieve
and ManageSieve.

For example exim's implementation is entirely local; it is just a
different syntax for .forward files.  exim also provides another syntax
which is specific to it but has more features than Sieve.  Gory details
are at [1].

dovecot provides ManageSieve but you don't have to enable it.  Again,
you can simply drop the rules file on the server via whatever file
transfer protocol you normally use - scp, rsync, etc.

[1]
http://exim.org/exim-html-current/doc/html/spec_html/filter.html

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Mangled and non-mangled TUHS mail lists

[Steve Nickolas]

On Mon, 2 Oct 2017, Grant Taylor wrote:

> On 10/02/2017 08:19 PM, Steve Nickolas wrote:
>> For me at least, in such cases, I have never gotten duplicates.
>
> Steve:
>
> Do you receive the email from the list?  Or the person that hit Reply-to-All?
>
> Mailman has a feature to not send you a copy from the list if you were a 
> direct recipient (To or Cc.)

That's as it should be. ;)

-uso.

Mangled and non-mangled TUHS mail lists

[Steffen Nurpmeso]

Dave Horsfall <dave at horsfall.org> wrote:
 |On Mon, 2 Oct 2017, Grant Taylor wrote:
 |> You might consider a filter that will filter messages (to trash so it's 
 |> recoverable?) to you and to the list.  That way you would rely on \
 |> the list 
 |> copy.  (But you could fetch the message out of trash if you needed to.)
 |
 |Yeah, I did use a Procmail filter for that, but Procmail is dead.  I must
 |take a closer look at Sieve.

The BSD Mail clone i maintain can perform simple filtering, too.
Gunnar Ritter implemented IMAP-style search expressions.  We are
far from being so powerful as mutt regarding filtering, but
i think automatization should work a bit better already today.

Because TUHS changed its policy i have added :Ll colon modifiers
to search for mailing-lists which are known (`mlist') or
subscribed (`mlsubscribe') just yesterday.  This is not on
[master] yet but just works (true for the [next] branch as of
today as such).  E.g.,

  $ printf 'File+download\nmove :Ll +lists\nxit' | s-nail -#

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).  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???  DKIM should
have been designed to create DKIM envelopes, so that lists could
simply create an encapsulating DKIM layer, and all would be fine.
But it has not, evil to him who evil thinks, the future is bright,
isn't it.  I for one admire those old standards which worked for
a few dozen boxes and still scale further on.

--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)

Mangled and non-mangled TUHS mail lists

[Grant Taylor]

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.

> 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.

This also means that mailing lists could support things like subject 
modification / SPF / DKIM / DMARC / ARC / S/MIME / PGP, etc. directly.

But ... that's just me and my opinion.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171003/54480702/attachment.bin>

Mangled and non-mangled TUHS mail lists

[Ian Zimmerman]

On 2017-10-03 12:20, Grant Taylor wrote:

> 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.

It's a valid viewpoint, but one of its consequences is that there is no
straight way of relating multiple copies of the original message.  Not
only in the somewhat shady case of personal reply+list followup, but
also in the quite legitimate case of posting the same message to
multiple lists.

A related situation is list managers that act as 2-way gateways from/to
Usenet groups.  Mailman can do that, and when it does it rewrites the
Message-ID.  The result is that all threads with mixed participants
(posting both via Unsenet and via email) are broken.

This is why I stopped reading the core GNU lists (help-gnu-emacs et al.)
when they adopted Mailman.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

Mangled and non-mangled TUHS mail lists

[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)

Mangled and non-mangled TUHS mail lists

[Bakul Shah]

> On Oct 3, 2017, at 3:12 AM, Steve Nickolas <usotsuki at buric.co> wrote:
> 
> On Mon, 2 Oct 2017, Grant Taylor wrote:
> 
>> On 10/02/2017 08:19 PM, Steve Nickolas wrote:
>>> For me at least, in such cases, I have never gotten duplicates.
>> 
>> Steve:
>> 
>> Do you receive the email from the list?  Or the person that hit Reply-to-All?
>> 
>> Mailman has a feature to not send you a copy from the list if you were a direct recipient (To or Cc.)
> 
> That's as it should be. ;)

I prioritize mail directly addressed to me; while reading most
mailing lists is an idle time process. For this reason I move
list messages to list specific folders via mail filters.  I
dispose of my own copy after responding to it (if also posted
to a mailing list). Given this style, I prefer receiving a
directly addressed copy as well as one re-sent via the list
manager and most lists do do this.  For groups like TUHS I have
to remember to manually move a message from inbox after I deal
with it. Not a big deal but....

Mangled and non-mangled TUHS mail lists

[Grant Taylor]

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.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171003/cadb709a/attachment-0001.bin>

Mangled and non-mangled TUHS mail lists

[Grant Taylor]

On 10/03/2017 12:43 PM, Ian Zimmerman wrote:
> It's a valid viewpoint, but one of its consequences is that there is no
> straight way of relating multiple copies of the original message.  Not
> only in the somewhat shady case of personal reply+list followup, but
> also in the quite legitimate case of posting the same message to
> multiple lists.

You bring up a valid point.  Something I've not specifically thought 
about before, mainly because I've not wanted to maintain a MLM.

> A related situation is list managers that act as 2-way gateways from/to
> Usenet groups.  Mailman can do that, and when it does it rewrites the
> Message-ID.  The result is that all threads with mixed participants
> (posting both via Unsenet and via email) are broken.

I see no reason that the hypothetical MLM that I'm alluding to couldn't 
re-use the message ID or at least cite it in the References: header 
rather than making something arbitrary up.

I think that would help with the problem that you're describing.

> This is why I stopped reading the core GNU lists (help-gnu-emacs et al.)
> when they adopted Mailman.

I'm sorry.  That makes me believe that the list has failed in it's 
purpose of enabling communications.  :-(



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3717 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20171003/78736c5f/attachment.bin>

Mangled and non-mangled TUHS mail lists [ enough already? ]

[Jon Steinhart]

While I haven't been on this list for very long I've seen several discussions
shut down.  Can we shut this one down?  Seen more messages on mailing lists,
DKIM, headers, procmail, and so on than anything else.  Not really UNIX stuff.

Jon

Mangled and non-mangled TUHS mail lists

[Dave Horsfall]

On Tue, 3 Oct 2017, Steffen Nurpmeso wrote:

> |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.

Except Warren did it backwards; he should've left the original list as it 
was, and migrated those with fussy clients to the new list.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

Mangled and non-mangled TUHS mail lists

[Steffen Nurpmeso]

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)

Mangled and non-mangled TUHS mail lists

[Steffen Nurpmeso]

Dave Horsfall <dave at horsfall.org> wrote:
 |On Tue, 3 Oct 2017, Steffen Nurpmeso wrote:
 |>|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.
 |
 |Except Warren did it backwards; he should've left the original list as it 
 |was, and migrated those with fussy clients to the new list.

Waves and material of various nature pervades us, for example
100 billion Neutrinos per second per fingertip i have learned
a few days ago.  To let it be consciously can thus not only be
seen as waving a red flag, but also as an indication of maturity,
as could have been teached by a ML guru.  Is that exaggerated.

I have turned on DKIM stripping for these tiny lists of mine.
That is not polite to people who use DKIM to say the least, shall
there be any, but i am not (experienced as) an administrator,
i have a very restricted (ridiculous to most of you for sure)
working environment and all i want is that this mess works
smoothly, so that i can spend time on things i have interest in.
And whereas i avoid a footer that would introduce a MIME multipart
where otherwise there would be none, i do prepend something to the
subject, because i like to see this.  It is a small project, and
people should have the possibility to visually degrade it and come
back when they have time for it.  Or something like this.  You
know, small projects of little interest cannot act as if they were
giants.  Of course you can pre-select on headers as in 'from
@<@tuhs\.org', but i never used this style of inbox stuff, i am
reading top-down, some mails keep lingering for later, but they
will be read and then dispatched, not vice versa, and this way of
doing things requires some easy visual thread methody.  Hm.

--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)