Re: [TUHS] off-topic list

Grant Taylor via TUHS wrote in <ce6f617c-cf8e-63c6-8186-27e09c78020c@spa\ mtrap.tnetconsulting.net>: |On 06/23/2018 08:49 AM, Steffen Nurpmeso wrote: |> Oh, I do not know: i have never used a graphical MUA, only pine, then |> mutt, and now, while anytime before now and then anyway, BSD Mail. | |I agree that text mode MUAs from before the turn of the century do have |a LOT more functionality than most GUI MUAs that came after that point |in time. | |Thankfully we are free to use what ever MUA we want to. :-) 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. |> they i think misinterpreted RFC 2231 to only allow MIME paramaters to be |> split in ten sections. | |I've frequently found things that MUAs (and other applications) don't do |properly. That's when it becomes a learning game to see what subset of |the defined standard was implemented incorrectly and deciding if I want |to work around it or not. 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. 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. Others like DNS are pretty perfect and scale fantastic. Thus. |> Graphical user interfaces are a difficult abstraction, or tedious \ |> to use. |> I have to use a graphical browser, and it is always terrible to enable |> Cookies for a site. | |Cookies are their own problem as of late. All the "We use |cookies...<bla>...<bla>...<bla>...." warnings that we now seem to have |to accept get really annoying. I want a cookie, or more likely a |header, that says "I accept (first party) cookies." as a signal to not |pester me. 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. 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! 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. |> For my thing i hope we will at some future day be so resilient that |> users can let go the nmh mailer without loosing any freedom. | |Why do you have to let go of one tool? Why can't you use a suite of |tools that collectively do what you want? 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 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. |> I mean, user interfaces are really a pain, and i think this will not |> go away until we come to that brain implant which i have no doubt will |> arrive some day, and then things may happen with a think. Things like |> emacs or Acme i can understand, and the latter is even Unix like in the |> way it works. | |You can keep the brain implant. I have a desire to not have one. Me too, me too. Oh, me too. Unforgotten those american black and white films with all those sneaky alien attacks, and i was a teenager when i saw them. Yeah, but in respect to that i am afraid the real rabble behind the real implants will be even worse, and drive General Motors or something. ^.^ I have no idea.. No, but.. i really do not think future humans will get around that, just imagine automatic 911 / 112, biologic anomaly detection, and then you do not need to learn latin vocabulary but can buy the entire set for 99.95$, and have time for learning something real important. For example. It is all right, just be careful and ensure that not all police men go to the tourist agency to book a holiday in Texas at the very same time. I think this is manageable. |> Interesting that most old a.k.a. established Unix people give up that |> Unix freedom of everything-is-a-file, that was there for email access \ |> via |> nupas -- the way i have seen it in Plan9 (i never ran a research Unix), |> at least -- in favour of a restrictive graphical user interface! | |Why do you have to give up one tool to start using a different tool? | |I personally use Thunderbird as my primary MUA but weekly use mutt |against the same mailbox w/ data going back 10+ years. I extensively |use Procmail to file messages into the proper folders. I recently wrote |a script that checks (copies of) messages that are being written to |folders to move a message with that Message-ID from the Inbox to the |Trash. (The point being to remove copies that I got via To: or CC: when |I get a copy from the mailing list.) | |It seems to be like I'm doing things that are far beyond what |Thunderbird can do by leveraging other tools to do things for me. I |also have a handful devices checking the same mailbox. 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. Even Thunderbird would simply be a maybe even little nice graphical application for display purposes. The actual understanding of storage format and email standards would lie solely within the provider of the file system. Now you use several programs which all ship with all the knowledge. I for one just want my thing to be easy and reliable controllable via a shell script. You could replace procmail (which is i think perl and needs quite some perl modules) with a monolithic possibly statically linked C program. Then. With full error checking etc. This is a long road ahead, for my thing. |> No, we use the same threading algorithm that Zawinski described ([1], |> "the threading algorithm that was used in Netscape Mail and News 2.0 |> and 3.0"). I meant, in a threaded display, successive follow-up \ |> messages |> which belong to the same thread will not reiterate the Subject:, because |> it is the same one as before, and that is irritating. |> |> [1] http://www.jwz.org/doc/threading.html | |I *LOVE* threaded views. I've been using threaded view for longer than |I can remember. I can't fathom not using threaded view. | |I believe I mistook your statement to mean that you wanted to thread |based on Subject: header, not the In-Reply-To: or References: header. It seems you did not have a chance not do. My fault, sorry. |>>> And you seem to be using DMARC, which irritates the list-reply \ |>>> mechanism |>>> of at least my MUA. |>> |>> Yes I do use DMARC as well as DKIM and SPF (w/ -all). I don't see how |>> me using that causes problems with "list-reply". |>> |>> My working understanding is that "list-reply" should reply to the list's |>> posting address in the List-Post: header. |>> |>> List-Post: <mailto:tuhs@minnie.tuhs.org> |>> |>> What am I missing or not understanding? |> |> That is not how it works for the MUAs i know. It is an interesting \ |> idea. |> And in fact it is used during the "mailing-list address-massage" |> if possible. But one must or should differentiate in between a |> subscribed list and a non-subscribed list, for example. This does |> not work without additional configuration (e.g., we have `mlist' and |> `mlsubscribe' commands to make known mailing-lists to the machine), |> though List-Post: we use for automatic configuration (as via `mlist'). |> |> And all in all this is a complicated topic (there are Mail-Followup-To: |> and Reply-To:, for example), and before you say "But what i want is a |> list reply!", yes, of course you are right. But. For my thing i hope |> i have found a sensible way through this, and initially also one that |> does not deter users of console MUA number one (mutt). | |How does my use of DMARC irritate the list-reply mechanism of your MUA? 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". 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. |DMARC is completely transparent to message contents. Sure, DKIM adds |headers with a signature. But I don't see anything about DKIM's use |that has any impact on how any MUA handles a message. | |Or are you referring to the fact that some mailing lists modify the |From: header to be DMARC compliant? Ach, it has been said without much thought. Maybe yes. There is a Reply-To: of yours. |Please elaborate on what you mean by "DMARC irritate the list-reply |mechanism of your MUA". 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. A nice sunday i wish. --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)