Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax

Dave Crocker <> Wed, 16 January 2019 18:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFE66130E85 for <>; Wed, 16 Jan 2019 10:41:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1oRR6YzoM568 for <>; Wed, 16 Jan 2019 10:41:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A513130E83 for <>; Wed, 16 Jan 2019 10:41:43 -0800 (PST)
Received: by with SMTP id a11so8642988otr.10 for <>; Wed, 16 Jan 2019 10:41:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=EPDOKHpjvgFHGaBi8EC8l5YSJ7IHDSpRnpJz3Yqct3Y=; b=eBqasULsCPO2rsbShR9LVkACMD3CwzFu7UCwpBauTp4qQFlghtHG0s3E2CVTPlSIzm eM4HXw9o1Vcac23SL6TwQ5FVt5pjLA/KEpWG90qW94vll+0Z535k+z4t6ZO7/vuJ899n ddtM1BlctN0Ir6U0a46r7aGpO9AoeQXMHBB4rZwxuRi5QRTJNX4hK0Rfthr0wfHIrAF6 9PZwIBWLlnByn7Ziqj0bGbsLzLYg8AAUK3KFc4TEaCKnTNW0M2QbZrMK+ECtQHvtND7M 5wkxRG+YqGYc6FfsTUNZOjP3xtxOJEwMMD7kshXKvnt4Rl5laP3R44fdGVVQ5A8sx6vq 0Rgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EPDOKHpjvgFHGaBi8EC8l5YSJ7IHDSpRnpJz3Yqct3Y=; b=uUNOOo/oJRQiRijOmhQGdB+ayc83IMXKMFZchotmYzUIco3ddHv0/CCfVf4E0KqntN 3eXRMX2PdthBGmwXRgeH3JnJB0E9eRLGBatYExa8LMHg13Uw8oTeH3IiAAOL2qt1VzJm /6PU7ewHFbB2ZCjhUk2flewXMH1Dm3+zjV45TYj7nOISrBioHBteZGXwj4swmFESD/zV Xf5CBfZ0B1/T7RbFcVsO9K90p2oeiJ66zZwfk1we8bfK7N59let4kWLbgp5KEWvmUCO1 RvjlGcjI659wh3nc1ITtP2jXNmnm3vBQeW/TGG8GVxzFT0IUXahY9LfE9s4NQ+K6j/XC 2ndA==
X-Gm-Message-State: AJcUukeXCgbKmmALQwhxrZ44HC+OsGuiSEwvAvWh4XSPtHKrKNO9VL5O dOqYGVadnIk2nQwjrSz6/uaaEz1s
X-Google-Smtp-Source: ALg8bN4agrmFw6A0V1knRF2EBLOjl5+2Gj7hEatYBetT/z8z94hgFo9NF34vfMITKTc50zh+P811Ng==
X-Received: by 2002:a9d:7749:: with SMTP id t9mr6780432otl.342.1547664102071; Wed, 16 Jan 2019 10:41:42 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id v68sm3214017oie.16.2019. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 16 Jan 2019 10:41:41 -0800 (PST)
To: Grant Taylor <>,
References: <20190116005804.A0A80200CACDA9@ary.qy> <> <alpine.OSX.2.21.1901161029520.36401@ary.qy> <> <alpine.OSX.2.21.1901161050550.36401@ary.qy> <> <alpine.OSX.2.21.1901161222030.38502@ary.qy> <>
From: Dave Crocker <>
Message-ID: <>
Date: Wed, 16 Jan 2019 10:41:38 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dmarc-ietf] Nitpicky questions about DMARC record syntax
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: Wed, 16 Jan 2019 18:41:45 -0000

> However I feel like rejecting things because of additional white space 
> (in front of v=...) or the wrong case is being a little bit pedantic.
> Rather, I think that if removing a spurious / leading space or folding 
> case causes the DMARC record to be valid, it behooves us to tolerate 
> such minor errors.
> I don't want to be so pedantic that people push back on adopting what I 
> (and I assume others) think is a good technology.
> Is doing so against the letter of the specification, absolutely.  Is it 
> within the spirit of the specification, I think so.

There is quite a bit of dynamic tension in this topic.

There is pressure to be tolerant, best captured in Jon Postel's 
robustness directive, and there is a slippery slope of having no firm, 
clear and precise standard.

If more flexibility is viewed by the community as desirable, then the 
community should enhance the specification to allow it.  This improves 
robustness while retaining a firm, clear and precise standard.

Dave Crocker
Brandenburg InternetWorking