[TUHS] off-topic list
michael at kjorling.se
Sun Jun 24 20:04:38 AEST 2018
On 23 Jun 2018 18:18 -0600, from tuhs at minnie.tuhs.org (Grant Taylor via TUHS):
>> 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
The problem, of course (and I hope this is keeping this Unixy enough),
with that approach is that it won't handle headers split across
multiple lines (I'm looking at you, Received:, but you aren't alone),
and that it'll match lines in the body of the message as well (such as
the "Subject: " line in the body of your message), unless the body
happens to be e.g. Base64 encoded which instead complicates searching
for non-header material.
For sure neither is insurmountable even with standard tools, but it
does require a bit more complexity than a simple egrep to properly
parse even a single message, let alone a combination of multiple ones
(as seen in mbox mailboxes, for example). At that point having
specific tools, such as formail, that understand the specific file
format does start to make sense...
There isn't really much conceptual difference between writing, say,
formail -X Subject: < message.txt
egrep "^Subject: " message.txt
but the way the former handles certain edge cases is definitely better
than that of the latter.
Make everything as simple as possible, but not simpler. (That goes for
web pages, too, by the way.)
> 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.
I believe the correct way would indeed be to validate, strip and
possibly re-sign. That way, everyone would (should) be making correct
claims about a message's origin.
FWIW, SPF presents a similar problem with message forwarding without
address rewriting... so it's definitely not just DKIM.
Michael Kjörling • https://michael.kjorling.se • michael at kjorling.se
“The most dangerous thought that you can have as a creative person
is to think you know what you’re doing.” (Bret Victor)
More information about the TUHS