From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: tuhs-bounces@minnie.tuhs.org X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.1 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 28b7212a for ; Mon, 25 Jun 2018 16:10:55 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 281E7A1854; Tue, 26 Jun 2018 02:10:55 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 8AE9F9EDE8; Tue, 26 Jun 2018 02:10:49 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 7BFB79EDE8; Tue, 26 Jun 2018 02:10:48 +1000 (AEST) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) by minnie.tuhs.org (Postfix) with ESMTPS id CDBDC9EDFC for ; Tue, 26 Jun 2018 02:10:45 +1000 (AEST) Received: by sdaoden.eu (Postfix, from userid 1000) id 8CEBE1604A; Mon, 25 Jun 2018 18:10:44 +0200 (CEST) Date: Mon, 25 Jun 2018 18:10:52 +0200 From: Steffen Nurpmeso To: tuhs@minnie.tuhs.org Message-ID: <20180625161052.6PXXL%steffen@sdaoden.eu> In-Reply-To: <20180624100438.GY10129@h-174-65.A328.priv.bahnhof.se> References: <20180622145402.GT21272@mcvoy.com> <20180622151751.BEK9i%steffen@sdaoden.eu> <20180622192505.mfig_%steffen@sdaoden.eu> <89e5ae21-ccc0-5c84-837b-120a1a7d9e26@spamtrap.tnetconsulting.net> <20180623144959.M9byU%steffen@sdaoden.eu> <20180623223851.LcBjy%steffen@sdaoden.eu> <09ee8833-c8c0-8911-751c-906b737209b7@spamtrap.tnetconsulting.net> <20180624100438.GY10129@h-174-65.A328.priv.bahnhof.se> Mail-Followup-To: tuhs@minnie.tuhs.org User-Agent: s-nail v14.9.10-138-gbb01f2b9-dirty OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [TUHS] off-topic list X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Michael Kj=C3=B6rling wrote in <20180624100438.GY10129@h-174-65.A328.priv.b= a\ hnhof.se>: |On 23 Jun 2018 18:18 -0600, from tuhs@minnie.tuhs.org (Grant Taylor \ |via TUHS): |>> Now you use several programs which all ship with all the knowledge. |>=20 |> I suppose if you count greping for a line in a text file as |> knowledge of the format, okay. |>=20 |> egrep "^Subject: " message.txt |>=20 |> There's nothing special about that. It's a text file with a line |> that looks like this: |>=20 |> 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. |>=20 |> 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@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)