Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07

Damian Lukowski <rfc@arcsin.de> Fri, 22 April 2022 06:40 UTC

Return-Path: <rfc@arcsin.de>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 484023A085B for <dmarc@ietfa.amsl.com>; Thu, 21 Apr 2022 23:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 (1024-bit key) header.d=arcsin.de
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOQdr3GrOj5Y for <dmarc@ietfa.amsl.com>; Thu, 21 Apr 2022 23:40:43 -0700 (PDT)
Received: from sigil.arcsin.de (sigil.arcsin.de [46.38.233.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0432A3A0819 for <dmarc@ietf.org>; Thu, 21 Apr 2022 23:40:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=arcsin.de; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject :mime-version:date:date:message-id:x-amavis-category; s=dkim01; t=1650609634; x=1652424035; bh=GflTJ268kpmiPVnwqv6io+NoGHVy27Lf yYl/A012jBo=; b=lIrgCK09chCQl53uI6ESfA/c8X0a1QTnXsefIBNV11N3wVrt vTdxw/EDtJIyQHCASAUKn2s8kgbiIy10HU1iFAt3T385+DEf8kwfUUEXFa3dwiAB CLbgw9PtfPbPkeYAR6HQKJLhh8J4/d5dvWQMrvykhuGe9sdcbCB8bReUhJs=
X-Amavis-Category: sigil.arcsin.de; category=Clean
Message-ID: <dc0210cb-5241-bce7-609d-352faf2b5132@arcsin.de>
Date: Fri, 22 Apr 2022 08:40:34 +0200
MIME-Version: 1.0
Content-Language: en-US
To: dmarc@ietf.org
References: <20220421165506.A8F1C3E43764@ary.qy>
From: Damian Lukowski <rfc@arcsin.de>
In-Reply-To: <20220421165506.A8F1C3E43764@ary.qy>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/dyX62SnGxnZsAcxO3-ganAhxyg8>
Subject: Re: [dmarc-ietf] ABNF errors on RFC7489 and dmarcbis-07
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2022 06:40:48 -0000

> In practice, the code that parses DMARC just splits the input into
> xxx=yyy pairs of tag and value strings and checks the values
> semantically.

For those, who do not work at the IETF, the spec comes before the implementation. If the spec defines a grammar that looks as 
authoritative [1] as the one in section 5.4, then an implementation might just solve a decision problem whether a string matches 
the grammar or not. This is a yes or no question. But as you have pointed out, the authors have an implementation in mind that 
leaks back into the spec:

> Unknown tags MUST be ignored.  Syntax errors in the remainder
> of the record SHOULD be discarded in favor of default values (if any)
> or ignored outright.

 From the perspective of a decision problem, there are no unknown DMARC tags. If there are syntax errors, then the whole thing is 
not a DMARC record, in particular it does not consist of valid tag-value pairs and invalid tag-value pairs. The record

> v=DMARC1; rua=mailto:report@example.com; garbage=101; more-garbage

should not yield DMARC reports at all, as there is no DMARC record.

In my opinion, the spec should either stick to the grammar, or explicitly and unambiguously define the parsing procedure.

[1] "A DMARC policy record MUST comply with the formal specification found in Section 5.4"