[TUHS] off-topic list
gtaylor at tnetconsulting.net
Sun Jun 24 10:18:42 AEST 2018
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
> 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
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.
Grant. . . .
unix || die
More information about the TUHS