Re: [TUHS] off-topic list

Michael Kjörling wrote in &lt;20180624100438.GY10129(a)h-174-65.A328.priv.ba\ hnhof.se>: |On 23 Jun 2018 18:18 -0600, from tuhs(a)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 &lt;20180624100438.GY10129(a)h-174-65.A328.priv.bahnhof.se&gt; --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)