* Mangled and non-mangled TUHS mail lists @ 2017-10-01 3:25 Warren Toomey 2017-10-01 14:00 ` Clem Cole 2017-10-02 1:01 ` Dave Horsfall 0 siblings, 2 replies; 27+ messages in thread From: Warren Toomey @ 2017-10-01 3:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-01 3:25 Mangled and non-mangled TUHS mail lists Warren Toomey @ 2017-10-01 14:00 ` Clem Cole 2017-10-01 14:08 ` Don Hopkins 2017-10-02 1:01 ` Dave Horsfall 1 sibling, 1 reply; 27+ messages in thread From: Clem Cole @ 2017-10-01 14:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-01 14:00 ` Clem Cole @ 2017-10-01 14:08 ` Don Hopkins 0 siblings, 0 replies; 27+ messages in thread From: Don Hopkins @ 2017-10-01 14:08 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-01 3:25 Mangled and non-mangled TUHS mail lists Warren Toomey 2017-10-01 14:00 ` Clem Cole @ 2017-10-02 1:01 ` Dave Horsfall 2017-10-02 8:22 ` jason-tuhs 1 sibling, 1 reply; 27+ messages in thread From: Dave Horsfall @ 2017-10-02 1:01 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-02 1:01 ` Dave Horsfall @ 2017-10-02 8:22 ` jason-tuhs 2017-10-02 12:38 ` Steve Nickolas 0 siblings, 1 reply; 27+ messages in thread From: jason-tuhs @ 2017-10-02 8:22 UTC (permalink / raw) >> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-02 8:22 ` jason-tuhs @ 2017-10-02 12:38 ` Steve Nickolas 2017-10-02 13:34 ` David Ryskalczyk 0 siblings, 1 reply; 27+ messages in thread From: Steve Nickolas @ 2017-10-02 12:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-02 12:38 ` Steve Nickolas @ 2017-10-02 13:34 ` David Ryskalczyk 2017-10-03 0:51 ` Dave Horsfall 0 siblings, 1 reply; 27+ messages in thread From: David Ryskalczyk @ 2017-10-02 13:34 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-02 13:34 ` David Ryskalczyk @ 2017-10-03 0:51 ` Dave Horsfall 2017-10-03 2:19 ` Steve Nickolas 0 siblings, 1 reply; 27+ messages in thread From: Dave Horsfall @ 2017-10-03 0:51 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 0:51 ` Dave Horsfall @ 2017-10-03 2:19 ` Steve Nickolas 2017-10-03 3:25 ` Grant Taylor 0 siblings, 1 reply; 27+ messages in thread From: Steve Nickolas @ 2017-10-03 2:19 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 2:19 ` Steve Nickolas @ 2017-10-03 3:25 ` Grant Taylor 2017-10-03 3:33 ` Dave Horsfall 2017-10-03 10:12 ` Steve Nickolas 0 siblings, 2 replies; 27+ messages in thread From: Grant Taylor @ 2017-10-03 3:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 3:25 ` Grant Taylor @ 2017-10-03 3:33 ` Dave Horsfall 2017-10-03 3:55 ` Grant Taylor ` (2 more replies) 2017-10-03 10:12 ` Steve Nickolas 1 sibling, 3 replies; 27+ messages in thread From: Dave Horsfall @ 2017-10-03 3:33 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 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 14:08 ` Steffen Nurpmeso 2 siblings, 1 reply; 27+ messages in thread From: Grant Taylor @ 2017-10-03 3:55 UTC (permalink / raw) [-- 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 3:55 ` Grant Taylor @ 2017-10-03 4:17 ` Dave Horsfall 0 siblings, 0 replies; 27+ messages in thread From: Dave Horsfall @ 2017-10-03 4:17 UTC (permalink / raw) [-- 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." ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 3:33 ` Dave Horsfall 2017-10-03 3:55 ` Grant Taylor @ 2017-10-03 4:12 ` Kurt H Maier 2017-10-03 7:40 ` Ian Zimmerman 2017-10-03 14:08 ` Steffen Nurpmeso 2 siblings, 1 reply; 27+ messages in thread From: Kurt H Maier @ 2017-10-03 4:12 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 4:12 ` Kurt H Maier @ 2017-10-03 7:40 ` Ian Zimmerman 0 siblings, 0 replies; 27+ messages in thread From: Ian Zimmerman @ 2017-10-03 7:40 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 3:33 ` Dave Horsfall 2017-10-03 3:55 ` Grant Taylor 2017-10-03 4:12 ` Kurt H Maier @ 2017-10-03 14:08 ` Steffen Nurpmeso 2017-10-03 18:20 ` Grant Taylor 2 siblings, 1 reply; 27+ messages in thread From: Steffen Nurpmeso @ 2017-10-03 14:08 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 14:08 ` Steffen Nurpmeso @ 2017-10-03 18:20 ` Grant Taylor 2017-10-03 18:43 ` Ian Zimmerman 2017-10-03 18:49 ` Steffen Nurpmeso 0 siblings, 2 replies; 27+ messages in thread From: Grant Taylor @ 2017-10-03 18:20 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 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 1 sibling, 1 reply; 27+ messages in thread From: Ian Zimmerman @ 2017-10-03 18:43 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 18:43 ` Ian Zimmerman @ 2017-10-03 21:59 ` Grant Taylor 0 siblings, 0 replies; 27+ messages in thread From: Grant Taylor @ 2017-10-03 21:59 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 18:20 ` Grant Taylor 2017-10-03 18:43 ` Ian Zimmerman @ 2017-10-03 18:49 ` Steffen Nurpmeso 2017-10-03 21:54 ` Grant Taylor 2017-10-04 2:28 ` Dave Horsfall 1 sibling, 2 replies; 27+ messages in thread From: Steffen Nurpmeso @ 2017-10-03 18:49 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 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 ` Mangled and non-mangled TUHS mail lists Steffen Nurpmeso 2017-10-04 2:28 ` Dave Horsfall 1 sibling, 2 replies; 27+ messages in thread From: Grant Taylor @ 2017-10-03 21:54 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists [ enough already? ] 2017-10-03 21:54 ` Grant Taylor @ 2017-10-03 22:00 ` Jon Steinhart 2017-10-04 20:17 ` Mangled and non-mangled TUHS mail lists Steffen Nurpmeso 1 sibling, 0 replies; 27+ messages in thread From: Jon Steinhart @ 2017-10-03 22:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 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 1 sibling, 0 replies; 27+ messages in thread From: Steffen Nurpmeso @ 2017-10-04 20:17 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 18:49 ` Steffen Nurpmeso 2017-10-03 21:54 ` Grant Taylor @ 2017-10-04 2:28 ` Dave Horsfall 2017-10-04 20:59 ` Steffen Nurpmeso 1 sibling, 1 reply; 27+ messages in thread From: Dave Horsfall @ 2017-10-04 2:28 UTC (permalink / raw) 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." ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-04 2:28 ` Dave Horsfall @ 2017-10-04 20:59 ` Steffen Nurpmeso 0 siblings, 0 replies; 27+ messages in thread From: Steffen Nurpmeso @ 2017-10-04 20:59 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 3:25 ` Grant Taylor 2017-10-03 3:33 ` Dave Horsfall @ 2017-10-03 10:12 ` Steve Nickolas 2017-10-03 19:21 ` Bakul Shah 1 sibling, 1 reply; 27+ messages in thread From: Steve Nickolas @ 2017-10-03 10:12 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Mangled and non-mangled TUHS mail lists 2017-10-03 10:12 ` Steve Nickolas @ 2017-10-03 19:21 ` Bakul Shah 0 siblings, 0 replies; 27+ messages in thread From: Bakul Shah @ 2017-10-03 19:21 UTC (permalink / raw) > 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.... ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2017-10-04 20:59 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-10-01 3:25 Mangled and non-mangled TUHS mail lists 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 ` Mangled and non-mangled TUHS mail lists Steffen Nurpmeso 2017-10-04 2:28 ` Dave Horsfall 2017-10-04 20:59 ` Steffen Nurpmeso 2017-10-03 10:12 ` Steve Nickolas 2017-10-03 19:21 ` Bakul Shah
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).