On 06/23/2018 08:49 AM, Steffen Nurpmeso wrote:
Hello.
Hi,
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. :-)
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.
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.
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?
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.
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.
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.
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?
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?
Please elaborate on what you mean by "DMARC irritate the list-reply
mechanism of your MUA".
--
Grant. . . .
unix || die