[TUHS] off-topic list

[Steffen Nurpmeso]

Michael Kjörling wrote in <20180624100438.GY10129 at h-174-65.A328.priv.ba\
hnhof.se>:
 |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
 |and
 |    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.

DKIM reuses the *SSL key infrastructure, which is good.  (Many eyes
see the code in question.)  It places records in DNS, which is
also good, now that we have DNS over TCP/TLS and (likely) DTLS.
In practice however things may differ and to me DNS security is
all in all not given as long as we get to the transport layer
security.

I personally do not like DKIM still, i have opendkim around and
thought about it, but i do not use it, i would rather wish that
public TLS certificates could also be used in the same way as
public S/MIME certificates or OpenPGP public keys work, then only
by going to a TLS endpoint securely once, there could be
end-to-end security.  I am not a cryptographer, however.  (I also
have not read the TLS v1.3 standard which is about to become
reality.)  The thing however is that for DKIM a lonesome user
cannot do anything -- you either need to have your own SMTP
server, or you need to trust your provider.  But our own user
interface is completely detached.  (I mean, at least if no MTA is
used one could do the DKIM stuff, too.)

 |FWIW, SPF presents a similar problem with message forwarding without
 |address rewriting... so it's definitely not just DKIM.
 --End of <20180624100438.GY10129 at h-174-65.A328.priv.bahnhof.se>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)