From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id d74dafe2 for ; Sun, 24 Jun 2018 00:18:06 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 16847A1843; Sun, 24 Jun 2018 10:18:05 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 7AF709EE0C; Sun, 24 Jun 2018 10:17:46 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=tnetconsulting.net header.i=@tnetconsulting.net header.b=WbXK5iRb; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id E3DF49EE0C; Sun, 24 Jun 2018 10:17:44 +1000 (AEST) Received: from tncsrv06.tnetconsulting.net (tncsrv06.tnetconsulting.net [45.33.28.24]) by minnie.tuhs.org (Postfix) with ESMTPS id 5E3CF9EDE9 for ; Sun, 24 Jun 2018 10:17:44 +1000 (AEST) Received: from REDACTED (drscriptt-2-pt.tunnel.tserv1.den1.ipv6.he.net [IPv6:2001:470:39:62a:0:0:0:2]) (authenticated bits=0) by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPSA id w5O0Hg38029892 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 23 Jun 2018 19:17:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tnetconsulting.net; s=2015; t=1529799463; bh=7cb1DHgIu7wtQOvHM84kAeMJOJp9aZu6DQU5FnWegrc=; h=Subject:To:References:From:Message-ID:Date:User-Agent: MIME-Version:In-Reply-To:Content-Type:Content-Language: Content-Transfer-Encoding:Cc:Content-Disposition:Content-Language: Content-Transfer-Encoding:Content-Type:Date:From:In-Reply-To: Message-ID:MIME-Version:References:Reply-To:Resent-Date: Resent-From:Resent-To:Resent-Cc:Sender:Subject:To:User-Agent; b=WbXK5iRbOGZK4+LoDbESk4pNdhFhjNNZiyIdVkAOyy2QE93j6ayCyNOpkktepdvh1 9b1N3Mu4TLYji7ugFbV1RUsWsiWcRqmixxZ5Yfkgr9b2lBokOB2WOivcDJypPkbNyd BAXZlRjnfrtHpTLW9f91NL/99ypaTDAi1MqqdfqQ= To: tuhs@minnie.tuhs.org References: <20180621234706.GA23316@minnie.tuhs.org> <20180622142846.GS21272@mcvoy.com> <20180622145402.GT21272@mcvoy.com> <20180622151751.BEK9i%steffen@sdaoden.eu> <20180622192505.mfig_%steffen@sdaoden.eu> <89e5ae21-ccc0-5c84-837b-120a1a7d9e26@spamtrap.tnetconsulting.net> <20180623144959.M9byU%steffen@sdaoden.eu> <20180623223851.LcBjy%steffen@sdaoden.eu> Organization: TNet Consulting Message-ID: <09ee8833-c8c0-8911-751c-906b737209b7@spamtrap.tnetconsulting.net> Date: Sat, 23 Jun 2018 18:18:42 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180623223851.LcBjy%steffen@sdaoden.eu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [TUHS] off-topic list X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Grant Taylor via TUHS Reply-To: Grant Taylor Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On 06/23/2018 04:38 PM, Steffen Nurpmeso wrote: > Absolutely true. And hoping that, different to web browsers, no let me > call it pseudo feature race is started that results in less diversity > instead of anything else. I'm not sure I follow. I feel like we do have the choice of MUAs or web browsers. Sadly some choices are lacking compared to other choices. IMHO the maturity of some choices and lack there of in other choices does not mean that we don't have choices. > If there is the freedom for a decision. That is how it goes, yes. For > example one may have renamed "The Ethiopian Jewish Exodus -- Narratives > of the Migration Journey to Israel 1977 - 1985" to "Falasha" in order to > use the book as an email attachment. Which would be pretty disappointing. I don't follow what you're getting at. > But it is also nice to see that there are standards which were not fully > thought through and required backward incompatible hacks to fill the gaps. Why is that a "nice" thing? > Others like DNS are pretty perfect and scale fantastic. Thus. Yet I frequently see DNS problems for various reasons. Not the least of which is that many clients do not gracefully fall back to the secondary DNS server when the primary is unavailable. > Ah, it has become a real pain. It is ever so astounding how much HTML5 > specifics, scripting and third party analytics can be involved for a page > that would have looked better twenty years ago, or say whenever CSS 2.0 > came around. I'm going to disagree with you there. IMHO the standard is completely separate with what people do with it. > Today almost each and every commercial site i visit is in practice > a denial of service attack. For me and my little box at least, and > without gaining any benefit from that! I believe those webmasters have made MANY TERRIBLE choices and have ended up with the bloat that they now have. - I do not blame the technology. I blame what the webmasters have done with the technology. Too many people do not know what they are doing and load "yet another module" to do something that they can already do with what's already loaded on their page. But they don't know that. They just glue things togehter until they work. Even if that means that they are loading the same thing multiple times because multiple of their 3rd party components loads a common module themselves. This is particularly pernicious with JavaScript. > The thing is, i do not want be lied to, but what those boxes you refer > to say are often plain lies. It has nothing to do with my security, > or performance boosts, or whatever ... maximally so in a juristically > unobjectionable way. Very disappointing. I don't understand what you're saying. Who is lying to you? How and where are they lying to you? What boxes are you saying I'm referring to? > It is just me and my desire to drive this old thing forward so that it > finally will be usable for something real. Or what i deem for that. I don't see any reason that you can't continue to use and improve what ever tool you want to. > I actually have no idea of nmh, but i for one think the sentence of > the old BSD Mail manual stating it is an "intelligent mail processing > system, which has a command syntax reminiscent of ed(1) with lines > replaced by messages" has always been a bit excessive. And the fork i > maintain additionally said it "is also usable as a mail batch language, > both for sending and receiving mail", adding onto that. What little I know about the MH type mail stores and associated utilities are indeed quite powerful. I think they operate under the premise that each message is it's own file and that you work in something akin to a shell if not your actual OS shell. I think the MH commands are quite literally unix command that can be called from the unix shell. I think this is in the spirit of simply enhancing the shell to seem as if it has email abilities via the MH commands. Use any traditional unix text processing utilities you want to manipulate email. MH has always been attractive to me, but I've never used it myself. > You say it. In the research Unix nupas mail (as i know it from Plan9) > all those things could have been done with a shell script and standard > tools like grep(1) and such. I do say that and I do use grep, sed, awk, formail, procmail, cp, mv, and any number of traditional unix file / text manipulation utilities on my email weekly. I do this both with the Maildir (which is quite similar to MH) on my mail server and to the Thumderbird message store that is itself a variant of Maildir with a file per message in a standard directory structure. > Even Thunderbird would simply be a maybe even little nice graphical > application for display purposes. The way that I use Thunderbird, that's exactly what it is. A friendly and convenient GUI front end to access my email. > The actual understanding of storage format and email standards would > lie solely within the provider of the file system. The emails are stored in discrete files that themselves are effectively mbox files with one message therein. > Now you use several programs which all ship with all the knowledge. I suppose if you count greping for a line in a text file as knowledge of the format, okay. egrep "^Subject: " message.txt There's nothing special about that. It's a text file with a line that looks like this: Subject: Re: [TUHS] off-topic list > I for one just want my thing to be easy and reliable controllable via > a shell script. That's a laudable goal. I think MH is very conducive to doing that. > You could replace procmail (which is i think perl and needs quite some > perl modules) with a monolithic possibly statically linked C program. I'm about 95% certain that procmail is it's own monolithic C program. I've never heard of any reference to Perl in association with procmail. Are you perhaps thinking of a different local delivery agent? > Then. With full error checking etc. This is a long road ahead, for > my thing. Good luck to you. > So ok, it does not, actually. It chooses your "Grant Taylor via TUHS" > which ships with the TUHS address, so one may even see this as an > improvement to DMARC-less list replies, which would go to TUHS, with or > without the "The Unix Heritage Society". Please understand, that's not how I send the emails. I send them with my name and my email address. The TUHS mailing list modifies them. Aside: I support the modification that it is making. > I am maybe irritated by the 'dkim=fail reason="signature verification > failed"' your messages produce. It would not be good to filter out > failing DKIMs, at least on TUHS. Okay. That is /an/ issue. But I believe it's not /my/ issue to solve. My server DKIM signs messages that it sends out. From everything that I've seen and tested (and I actively look for problems) the DKIM signatures are valid and perfectly fine. That being said, the TUHS mailing list modifies message in the following ways: 1) Modifies the From: when the sending domain uses DMARC. 2) Modifies the Subject to prepend "[TUHS] ". 3) Modifies the body to append a footer. All three of these actions modify the data that receiving DKIM filters calculate hashes based on. Since the data changed, obviously the hash will be different. I do not fault THUS for this. But I do wish that TUHS stripped DKIM and associated headers of messages going into the mailing list. By doing that, there would be no data to compare to that wouldn't match. I think it would be even better if TUHS would DKIM sign messages as they leave the mailing list's mail server. > Ach, it has been said without much thought. Maybe yes. There is a > Reply-To: of yours. I do see the Reply-To: header that you're referring to. I don't know where it's coming from. I am not sending it. I just confirmed that it's not in my MUA's config, nor is it in my sent Items. > My evil subconsciousness maybe does not like the MARC and DKIM standards. > That could be it. I do not know anything better, maybe the next > OpenPGP and S/MIME standards will include a checksum of some headers > in signed-only data, will specify that some headers have to be repeated > in the MIME part and extend the data to-be-verified to those, whatever. > I have not read the OpenPGP draft nor anyting S/MIMEish after RFC 5751. I don't know if PGP or S/MIME will ever mandate anything about headers which are structurally outside of their domain. I would like to see an option in MUAs that support encrypted email for something like the following: Subject: (Subject in encrypted body.) Where the encrypted body included a header like the following: Encrypted-Subject: Re: [TUHS] off-topic list I think that MUAs could then display the subject that was decrypted out of the encrypted body. > A nice sunday i wish. You too. -- Grant. . . . unix || die