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

Dave Crocker <> Thu, 17 January 2019 17:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B9B012426E for <>; Thu, 17 Jan 2019 09:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XhKOOEFfLQ5L for <>; Thu, 17 Jan 2019 09:54:53 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F2DC5130EB5 for <>; Thu, 17 Jan 2019 09:54:52 -0800 (PST)
Received: by with SMTP id u16so11898924otk.8 for <>; Thu, 17 Jan 2019 09:54:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LJRfeZn6lp4Tyg6JVowiyeoP9TouTnA35/avLWEXCBI=; b=ou1RKz/3eXUkLKEhQ3DAgW6E4W+eaa98S7W7x2G3X8M3YfzTfp4FGCctukTpbxacC8 Cv6jT9g53P4o5TqGI9XdM+rjuM2ePQG4gHe+c+Zxmdxcljg5ceqnxs56svOZyat1FR1Q pHAxWnDnRj7hZJL6seoH5dp9ZyFKvcaKvvR3Jn0ywE7in64HFlB8Wuuyy0COGnRY+xJN fh9q9gfc5mzHTt5nBvU2aVi+M8MjdWE3lNmuiFoyUkKueVynQqmP0dW3bJ4TYLwd/RPM Se+5vjty9rS/SZxFODPWlPUFGU2xc7zEJa3LwJzuyQ4WIMDZlOfNHfMDAfBpb7HHnOyR rQXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LJRfeZn6lp4Tyg6JVowiyeoP9TouTnA35/avLWEXCBI=; b=b4c4wWFlCa9Y3Aef5s+yW1fQFS/9ELZtMBdaWuO4F9mmOMPxoPoreh1sIMy7+B0SDl c+Joln4Xz0EyAX4DWy82O1X+iToTcWByLZy6dCR67XW895l/ACnnt7BvfnyCrR/Bz869 0mQZKQO+LbRQsCJf0Owmr7QPOULm4COHpFUNeRQ1X4PmcHrXYbhCsO5vh5qtjEu4znes IQfx/OEdApyETlHpwN/rlCkUVtUpq5UyzvQcQPTBa7rVg1cceNcpz3JUIRH7dP6C7wbe srhRlu5NBHWFmA9KMiOxxnNq/M7fEkW5FRKqJryQ61+B+71tR8aPKxJpMhAbVqKndrpm DYnQ==
X-Gm-Message-State: AJcUukfU4xYT34eUkz213fO+FUYaCQNs8G2Q8D/hmGwkmeuJrJsG9luW xwJzWDFyDi2MUKd6CFnCX7YRqX7g
X-Google-Smtp-Source: ALg8bN7BIVB3zqoL7vbMdY/88eGRZDN0fyEW9qNAV8aO6PBhUvTvwJx9iWeFhBKAmAI0M2UvtQa/8Q==
X-Received: by 2002:a9d:3e4a:: with SMTP id h10mr9999191otg.74.1547747692073; Thu, 17 Jan 2019 09:54:52 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id h24sm914322otm.72.2019. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 17 Jan 2019 09:54:51 -0800 (PST)
To: John Levine <>,
References: <20190117165317.E79D7200CD8A31@ary.qy>
From: Dave Crocker <>
Message-ID: <>
Date: Thu, 17 Jan 2019 09:54:48 -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: <20190117165317.E79D7200CD8A31@ary.qy>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
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: Thu, 17 Jan 2019 17:54:56 -0000

On 1/17/2019 8:53 AM, John Levine wrote:
> In article<
>  you write:
>> However I still feel like/requiring/  exact case is contrary to the idea
>> of "Be liberal in what you accept and conservative in what you send.".
> Yup.  See
> a/k/a "Postel was wrong".

The common interpretation of Postel's dictum is to use it as an excuse 
to ignore specification details.

That was not what he intended.  Rather, he intended its use in the way 
that Ned invoked:

> On 1/17/2019 5:00 AM, wrote:
>> Sorry, I meant to mention this in my previous response. It's one thing
>> when there's wiggle-room or lack of clarity in the standard. It's quite
>> another when things are clear, as is the case here.

Be liberal when the specification leaves room for doubt.  Not when it 


ps. I don't know why the spec, here, demands case sensitivity but it is 
quite clear that it does.

Dave Crocker
Brandenburg InternetWorking