24 Jun
2018
24 Jun
'18
6:18 a.m.
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