Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec)

"Murray S. Kucherawy" <> Sun, 07 July 2013 07:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07CCB21F9E52 for <>; Sun, 7 Jul 2013 00:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CHk7afOKPGV3 for <>; Sun, 7 Jul 2013 00:20:39 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::229]) by (Postfix) with ESMTP id 440C121F9E50 for <>; Sun, 7 Jul 2013 00:20:39 -0700 (PDT)
Received: by with SMTP id y10so8144273wgg.0 for <>; Sun, 07 Jul 2013 00:20:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=83JeaCqbmg1unOTFqjIrbkHVnqeXRyYpkKCjtjA5i84=; b=e3qD8MvIXVXPxdNPFo2VqU8DgvoOxaT12Eu5S7+++gAgKwXIr3oQlagWcbXCyRnfxn ZW116c9e4Vac9pdnz6fKUsU0x3x8J2zyvPj7BWUC1RqQ10hhJuJA7u7hljADKDGStZcU AIHSDKIMBNCcJ2TOPGNrFnJwkDhPU3Ympz/xLaDlw+S6DbNCwQJy18yWUfvJroN1l5l8 2q23/NYvx5jdENPFYl0sdJe4Pj9MacKhBRHRXX3fg8TQjBRpAQpQMdYsZb1zct3Z6SOl UY23OIqA+LWecFR17gv/r0RqVjzAql8lkLoB7+1a+9vPDVx7Rs2RCeyVuf1R3y7RzlB9 JJeA==
MIME-Version: 1.0
X-Received: by with SMTP id fo17mr9082056wic.60.1373181638358; Sun, 07 Jul 2013 00:20:38 -0700 (PDT)
Received: by with HTTP; Sun, 7 Jul 2013 00:20:37 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Sun, 07 Jul 2013 00:20:37 -0700
Message-ID: <>
From: "Murray S. Kucherawy" <>
To: SM <>
Content-Type: multipart/alternative; boundary="001a11c26a5ec43d1e04e0e6c32c"
Cc: "" <>, Eliot Lear <>
Subject: Re: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00 (was:Fwd: Eliot's review of the DMARC spec)
X-Mailman-Version: 2.1.12
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, 07 Jul 2013 07:20:41 -0000

On Fri, Jul 5, 2013 at 11:05 AM, SM <> wrote:

>  The details are further down in the document.  Section 5 is setting the
> stage for what comes later.  It's more overview than substance.
> I suggest not putting requirements in a section which provides an
> overview.  Barry and Pete commented about yelling in a WG.  I suggest
> taking those comments into consideration.    As a meta-comment about
> setting the stage I suggest writing the proposal as a mechanism.  You could
> then drop text, reorganize it, etc. to come up with a leaner version which
> specifies the mechanism and avoids the usual headaches.

I think requirements, or perhaps they're better stated as "goals", explain
part of how we got here.  They're useful for providing background.

>>   "Mail Receivers MAY deviate from a Domain Owner's published policy
>>    during message processing and SHOULD make available the fact and
>>    reason of the deviation to the Domain Owner via feedback reporting."
>> I read the above as "if you do not do what I say you have to provide me
>> with a justification".  Let me rewrite the text:
>>   "Mail Receivers deviating from a Domain Owner's published policy
>>    during message processing and MUST make available the fact and
>>    reason of the deviation to the Domain Owner via feedback reporting."
>> If that text is not acceptable to mail receivers the RFC 2119 SHOULD will
>> have the same effect.
>> SHOULD is appropriate.  There can be local policy reasons for not
>> revealing such details via feedback.
> What I meant is that the proposal is telling mail receivers what to do.
>  The matter is entirely a local policy issue.
>  draft-kucherawy-dmarc-base-00 is intended as a Standards Track document.
>  The draft is doing policy stuff and trying to set conformance.  There has
> been previous similar efforts.  I would describe them as controversial and
> subject to interpretation.  I would scope the work to keep the
> implementation and policy parts separate so that you have a tightly-written
> specification.

I think your change of "MAY deviate" to "deviating" is fine, but changing
MUST to SHOULD won't work.  MUST is not appropriate because the protocol
doesn't completely break if you don't take the action described here, and
there are certain to be operators that won't do what's specified because of
a need to keep internal mechanisms private.  That fits SHOULD nicely.

Any standards track document "sets conformance" by spelling out those parts
that are mandatory to implement.  I don't understand the objection there.

>> In Section 7:
>>   "When this is done, the DNS domain name thus recorded MUST be encoded
>> as an
>>    A-label, as described in Section 2.3 of [IDNA]."
>> The above is under "policy enforcement considerations".  It should be in
>> a section discussing the DNS aspects of the specification.
>> Why?  The context is the construction of an RFC5451 header field, not
>> something about DNS.
> I guess that we are reading "policy enforcement considerations"
> differently.  The context is as what you wrote above.  What I was
> suggesting is to separate policy from how the DMARC code is supposed to
> work.  You could take the RFC 5451 approach to simplify the draft.
Every operational environment is different.  Some will be able to take the
RFC5451 approach and some will not.  Shouldn't we provide operational
advice for both cases?

>  Section 8.2 is about "Verifying External Destinations".  If I am not
>> mistaken, IETF specifications are not about imposing a specific method.
>>  Section 8.2 sounds like a tutorial for the implementer instead of a
>> definition of what the "DMARC policy string" means.
>> I disagree; a specification is indeed about describing a specific method.
>>  Tutorials for implementers appear throughout various documents we produce,
>> one of which you are working on in another working group right now.  :-)
> I disclaim any knowledge of any other working group. :-)
> I have been reading some specifications (not mail-related) and some
> reviews recently.  I don't think that the Internet Engineering Tooth Fairy
> will agree with the following; sometimes a proposal specifies a method and
> gets into details which turns the proposal into a guide about a specific
> implementation.  A Standards Track document is about interoperability and
> not about specifying how the implementor should do things.

This sort of protocol isn't completely deterministic.  At various
junctures, there are places where operational decisions get made.  It
strikes me that guidance when making those decisions is a good thing, and
its absence would be a bad thing.  We are asked to provide it more often
than not.

I think it all comes down to whether separating that sort of material out
into a separate document is a useful thing to do.  If doing so would mean
an implementer needs to hop back and forth between two documents just to
get the thing running, I'd say we've done the implementer a disservice.

I'm going to leave the rest for now and see what you think of the next
version.  I think a lot of this has been addressed, though I'm sure there
will be other things to discuss.