[TUHS] off-topic list

[Grant Taylor]

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