Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum

John Levine <> Sun, 22 March 2020 01:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F6353A08AD for <>; Sat, 21 Mar 2020 18:04:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.851
X-Spam-Status: No, score=-1.851 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1536-bit key) header.b=Nmk+PsLf; dkim=pass (1536-bit key) header.b=dwePkSo3
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id drQvGFeTS9lj for <>; Sat, 21 Mar 2020 18:04:07 -0700 (PDT)
Received: from ( [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B939D3A08AC for <>; Sat, 21 Mar 2020 18:04:06 -0700 (PDT)
Received: (qmail 32307 invoked from network); 22 Mar 2020 01:04:04 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; =?utf-8?q?h=3Ddate?= =?utf-8?q?=3Amessage-id=3Afrom=3Ato=3Acc=3Asubject=3Ain-reply-to=3Amime-ver?= =?utf-8?q?sion=3Acontent-type=3Acontent-transfer-encoding=3B?= =?utf-8?q?s=3D7e31=2E5e76b984=2Ek2003=3B_bh=3DqJp4yIbxTspOwTe1JqrwBgCk22dpE?= =?utf-8?q?OcsSLau3Nil7Lw=3D=3B_b=3DNmk+PsLf7x6uvz+TZLSPaTuRDsKcsOIhUUU8Akca?= =?utf-8?q?L2y2jEt5Keah5W642C7T/v29AoEXXEERkEu1smtUBv94aec7CF6WVEgUfwYGCBcJM?= =?utf-8?q?9/bdRWsdX2iNyPL/rl327m/905N6fgmkiAdCc0lj8qP3RG43mXCCarIoXWP0HJ5f4?= =?utf-8?q?QoElW9nKLY6tyZIl/etj8rzNhqmOqxc2U0c1kZdziQxZB03Fj67k41GyC6CSeIAGW?= =?utf-8?q?4aln58YSVzHDnPhWVqg41?=
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; =?utf-8?q?h=3Ddate?= =?utf-8?q?=3Amessage-id=3Afrom=3Ato=3Acc=3Asubject=3Ain-reply-to=3Amime-ver?= =?utf-8?q?sion=3Acontent-type=3Acontent-transfer-encoding=3B?= =?utf-8?q?s=3D7e31=2E5e76b984=2Ek2003=3B_bh=3DqJp4yIbxTspOwTe1JqrwBgCk22dpE?= =?utf-8?q?OcsSLau3Nil7Lw=3D=3B_b=3DdwePkSo387qL2DSAlr2Z3dS6F7TJSnOOez4+/rK7?= =?utf-8?q?yWK0RdoIIrt7rbSLQBbrkpwxzVIVaCko2yzjT7TzsRLAcMsyRpXBy1hAMOruV62HF?= =?utf-8?q?jO6WjNISjBEgEzCM11UE2B78E7+HDufiA7dOcyGcCS0mGB2NtFILdSRrsXY9asTmS?= =?utf-8?q?CjIytRfRT1A8+OSKqRqrkmYFnf8GEI8BW2UifS++grfeekIJbObTmCzvyJp6SDOAM?= =?utf-8?q?BI4wCaAfUnx1rjd+A8w+B?=
Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTP via TCP6; 22 Mar 2020 01:04:04 -0000
Received: by ary.qy (Postfix, from userid 501) id 7053C165D622; Sat, 21 Mar 2020 21:04:04 -0400 (EDT)
Date: 21 Mar 2020 21:04:04 -0400
Message-Id: <20200322010404.7053C165D622@ary.qy>
From: "John Levine" <>
In-Reply-To: <>
Organization: Taughannock Networks
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 8bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Errors in RFC 8601, was Question about changes introduced by erratum
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 22 Mar 2020 01:04:08 -0000

In article <> you write:
>Hello DMARC working group,
>I am going through the changes between RFC7601 and RFC8601 and try to
>understand the implication of the change introduced by erratum 5435.
>The new resinfo definition uses 1*propspec, that is, by my understanding
>of [1] and [2], potentially multiple consecutive propspecs without
>obvious delimiters. ...

It says:

resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
            [ CFWS 1*propspec ]

I think both the erratum and RFC 8601 are wrong, and it should say:

resinfo = [CFWS] ";" methodspec [ CFWS reasonspec ]
            1*( CFWS propspec )

Every implementation I know puts space between multiple propspec's
which the current syntax wouldn't allow

>The spf method defines smtp.helo and smtp.mailfrom. RFC8601, RFC7601 and
>RFC7001 have only examples of the form smtp.mailfrom=domain-name.
>However, RFC7208 shows a local-part@domain-name form in [3], so I must
>assume a parser for an RFC8601 resinfo needs to recognize both forms. So

That's a mistake in the examples in Appendix B.  The example at the
bottom of page 21 is correct -- the value for smtp.mailfrom is a
mailbox, not a domain name.