Re: [art] not an erratum in RFC 6376, was Argh!!!! onto https://www.rfc-editor.org/errata.php
Steffen Nurpmeso <steffen@sdaoden.eu> Thu, 21 March 2024 01:31 UTC
Return-Path: <steffen@sdaoden.eu>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF9EC14F5F9 for <art@ietfa.amsl.com>; Wed, 20 Mar 2024 18:31:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sdaoden.eu header.b="Sb7BM2U8"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=sdaoden.eu header.b="oulxIguL"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bEq_4X8ycgo for <art@ietfa.amsl.com>; Wed, 20 Mar 2024 18:31:10 -0700 (PDT)
Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7D0C14F61C for <art@ietf.org>; Wed, 20 Mar 2024 18:31:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=citron; t=1710984663; x=1711651329; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:mime-version:content-type:content-transfer-encoding:message-id: mail-followup-to:openpgp:blahblahblah; bh=siNCAFsnXe0HOV3glKMBViW8rzKU64xO3+qhyYH01tU=; b=Sb7BM2U8qrbOJb1Ro1PPn3glF9SZJMJaLUScvX63jZ8XmFQstfExlnXyXeLhoAEg98Yu8WQ2 dG7azY47UfVGMP26/YeCf2kDoOcc3KFbVqh54kIozaRgf/Q9TD+jlhHqqiPFcjaYzu/QM63SL/ XDps2C1kO0jT47Z0ORYX1Wn/+yUqSAUEA/I6Q+g/kZH9uVKblI7IlJcnaJ3LQTy61cd8KjSj50 ln8gkcFRmj7i41d5QQD+6iCBm+ewuoSkTH6z5A8ruy5vXZBjWUzNfVIqBSg0XXYKwXHAh8xnMp 4c+I6cAL02fjve0mzin9RWTSim0ZjXamyorC9cbyWO/N1Q6w==
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=sdaoden.eu; s=orange; t=1710984663; x=1711651329; h=date:author:from:to:cc:subject: message-id:in-reply-to:references:mail-followup-to:openpgp:blahblahblah: mime-version:content-type:content-transfer-encoding:author:from:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:mime-version:content-type:content-transfer-encoding:message-id: mail-followup-to:openpgp:blahblahblah; bh=siNCAFsnXe0HOV3glKMBViW8rzKU64xO3+qhyYH01tU=; b=oulxIguLevQE1UltL1HpSeBt6+rStEiF/aFy2oje/KxK1pJFE19HuhBCtjSIGVj5ZF7lQvU7 CJfiQCZ4qglABw==
Date: Thu, 21 Mar 2024 02:31:00 +0100
Author: Steffen Nurpmeso <steffen@sdaoden.eu>
From: Steffen Nurpmeso <steffen@sdaoden.eu>
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: art@ietf.org
Message-ID: <20240321013100.njaKjjEY@steffen%sdaoden.eu>
In-Reply-To: <CAL0qLwbR6P4WQUqT9jMNpRWvXbcg5Zow-rybKD3PKB+nsi_GUA@mail.gmail.com>
References: <20240320211242.57E4085CEF48@ary.qy> <20240320223000.GvPm_uV2@steffen%sdaoden.eu> <CAL0qLwbR6P4WQUqT9jMNpRWvXbcg5Zow-rybKD3PKB+nsi_GUA@mail.gmail.com>
Mail-Followup-To: "Murray S. Kucherawy" <superuser@gmail.com>, art@ietf.org
User-Agent: s-nail v14.9.24-612-g7e3bfac540
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
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/a8Dd_qO8H-4L0xaAmSY59UGB3JA>
Subject: Re: [art] not an erratum in RFC 6376, was Argh!!!! onto https://www.rfc-editor.org/errata.php
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2024 01:31:15 -0000
Murray S. Kucherawy wrote in <CAL0qLwbR6P4WQUqT9jMNpRWvXbcg5Zow-rybKD3PKB+nsi_GUA@mail.gmail.com>: |On Thu, Mar 21, 2024 at 8:30 AM Steffen Nurpmeso <steffen@sdaoden.eu> \ |wrote: |> But .. that is what happens in real life software? Maybe one |> should even add a paragraph stating that, and mention the Sendmail |> milter protocol, which possibly is the culprit of what happens. |> (Though _why_ that is, since the other possibilities would have |> worked out just equally well? Ie, literal bytes or simple |> stripping. I cannot tell, i was not around anything email around |> 2006-2011 when that seems to have been developed.) |> |> I did ask on -dkim@ and implemented as written and said, but DKIM |> verification fails for such multiline headers from milter |> communication if RFC 6376 is followed exactly. (Thankfully DKIM |> has a certificate test mode built-in, otherwise some reputation |> downgrade (if at all possible in my case) would surely have kicked |> in! It is a great standard!) |> | |milter provides multiline headers separated by LFs, not CRLFs. I don't |recall why it was done this way, but that's how it's been since the |beginning. This is in the milter API documentation, which is (or used to |be) packaged in the sendmail source tarball. You can find it online too; |for example: | |https://www.ibm.com/docs/en/aix/7.2?topic=functions-xxfi-header-callback\ |-function Well i actually had that around all the time, it is in the FreeBSD source code that i track. But i myself used the plain text document $Id: milter-protocol.txt,v 1.6 2004/08/04 16:27:50 tvierling Exp $ which does not mention this. But *regardless* of all that. If you do not treat LF as whitespace, you get failing signatures, unless i am now totally confused. Btw i posted OpenDKIM code of a canonicalization function which does *not* do what you say this very evening, but it uses isspace(3) on header field body content?!? Good night from Germany, --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)
- Re: [art] not an erratum in RFC 6376, was Argh!!!… John Levine
- Re: [art] not an erratum in RFC 6376, was Argh!!!… Steffen Nurpmeso
- Re: [art] not an erratum in RFC 6376, was Argh!!!… John Levine
- Re: [art] not an erratum in RFC 6376, was Argh!!!… Murray S. Kucherawy
- Re: [art] not an erratum in RFC 6376, was Argh!!!… Steffen Nurpmeso
- Re: [art] not an erratum in RFC 6376, was Argh!!!… John Levine
- Re: [art] not an erratum in RFC 6376, was Argh!!!… Steffen Nurpmeso
- Re: [art] not an erratum in RFC 6376, was Argh!!!… Rob Sayre
- Re: [art] not an erratum in RFC 6376, was Argh!!!… Steffen Nurpmeso
- Re: [art] not an erratum in RFC 6376, was Argh!!!… John C Klensin
- Re: [art] not an erratum in RFC 6376, was Argh!!!… Steffen Nurpmeso