Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

Todd Herr <> Thu, 06 May 2021 12:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 079AF3A2031 for <>; Thu, 6 May 2021 05:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2G3gR-awqQeB for <>; Thu, 6 May 2021 05:22:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 021FA3A2033 for <>; Thu, 6 May 2021 05:22:03 -0700 (PDT)
Received: by with SMTP id 76so4620593qkn.13 for <>; Thu, 06 May 2021 05:22:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=l+I2xcEsayeoN7Q9iiQbln66BnJIDteMBQlYJHurUu4=; b=GfKWbzJLD4cPGWH+iB++pHINI05maqZ145nv5Nb3BWH5B/lW1u0ehTj1rSsi9H6Y16 /f3N0vnUN/D2pWVwBx+Nmnp/ZGQTEglfHYDPJO8rgWAY6kLnDjfgt0tr/QsGj7ejzdYi i0R3dwQW42mXaQ0KZeE2R0ud85ZoaMxTz5KPOyxbxrZ/iMmDttinlaYuFwmVh154T3/J Bs6+pbQ0rFKNSLn1+jGiCxLlk63z7wa+/Xn+4nEMwKv/8m0AJUvs0bEhVMlBSoJjT16M DFtxyzcPHjMjABgXyJeNgpVGMHs4TCwHRsy2Xq83Sbxfxq+oyIsu7yBl5e7iHV1r7UNn nT0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=l+I2xcEsayeoN7Q9iiQbln66BnJIDteMBQlYJHurUu4=; b=eSuTA/0ss1s4zL4tCEGTcfAjiwvr9Xdwh/J/s5q9ABauGHBWvGZZzNgIz7zPDxNKSl d6fs1SxZ/FCFchOsyfXYQHJCZjTS6L5wB/mufgprVu+dpFMTxEKTilspPGW5ic64YA7d q0MgRw8yDATJhPNeAlKlqpF0k/AWNdXXtvgTzBi8qEY8zvs6ibhopQn7OOjvmnWAqATh orp07pmmk7Ppnm7JYHd3K6PRTQoTFy0Z891TIw1HoUKPkRS32k/uksKVCElBxZr/8jPZ 1Inx2Cm+8nqX+oKpLWjPBvaii7aP/vrZkIRs8Zy65XeftBe5ZCKCkf+D1WoPGJZ+bWRe CYgg==
X-Gm-Message-State: AOAM531Iv1oF48Q0oEf6Ei5c6aJ1Q18dfCRQ5Brm9T2qnV81IKTC+ODU 5ytySA0wbTFIg/YbxmcFoYDIQFuMTYpjpahNEFMQAMfI7FUcVA==
X-Google-Smtp-Source: ABdhPJy+ouvxs59OqaIMMkJLOr7lnMq6+JKUJ37vjevziBlY/m1vSfIn2sCw/TRbVpqXZKMxgH/tvTpOTQ2CJNBenpY=
X-Received: by 2002:a37:a988:: with SMTP id s130mr3751957qke.325.1620303722142; Thu, 06 May 2021 05:22:02 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Todd Herr <>
Date: Thu, 6 May 2021 08:21:46 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000c9760f05c1a85b8a"
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section
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, 06 May 2021 12:22:09 -0000

On Thu, May 6, 2021 at 5:47 AM Alessandro Vesely <> wrote:

> Todd,
> does your message assume that the relevant tickets are all accepted as
> valid
> indications to alter the spec?  In particular, tickets #52 and #75 have
> never
> been discussed on list. I'd guess they'll have to be discussed in their
> own
> threads.

I don't know if each of those individual tickets has to be discussed in
their own threads or not, and I think it's more a decision for the chairs
to make than for the editors or the working group, but I could be very
wrong about that.

What I will say is this:

   - The design team went off and effectively created a new version of
   draft-ietf-dmarc-dmarcbis, specifically draft-ietf-dmarc-dmarcbis-01. It is
   proposed text, nothing more, nothing less.
   - The design team's work was influenced by those tickets which
   currently show a status of 'infoneeded'.
   - Due to the nature of the text, both of the following are true:
      - Most, but perhaps not all, of the 'infoneeded' tickets had impacts
      on multiple sections of draft-ietf-dmarc-dmarcbis-01
      - Most of the changes to sections of draft-ietf-dmarc-dmarcbis-00
      that were made in producing draft-ietf-dmarc-dmarcbis-01 were
influenced by
      multiple tickets

Back on April 23, when I posted here about setting expectations, I thought
at the time that adjudicating each of the infoneeded tickets might be the
way to go, but upon further reflection I'm not sure that's the case, since
it can be argued that those tickets were created against a work product
that no longer exists. It's also true that because those tickets affect the
wording in multiple sections of the document, adjudicating the -00 tickets
can theoretically result in a morass of edits made across multiple sections
of -01 and subsequent revisions, and everyone eventually losing the plot.

Chairs, your thoughts?

> Discussing the resulting text before those tickets entails, for example,
> noting
> the cumbersomeness of the locution "severity of concern" where something
> like
> "desired disposition" might seem more immediate.  In fact, ticket #85 was
> only
> discussed as a side effect of ticket #39, where the consensus, IIRC, was
> to
> keep the existing policy names while wavering about how to describe them.
> The term RFC5322.From is consistently used, notwithstanding ticket #96.
> For an
> alternative, let me attempt to define DMARC in terms of its acronym:
>     The Domain-based Message Authentication, Reporting, and Conformance
>     protocol recognizes the prevailing importance of the domain appearing
> in the
>     From: header field of email messages.  That domain name will be called
> the
>     Main Identifier in this document.  DMARC leverages the Sender Policy
>     Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376])
> protocols
>     by focusing the authentication mechanisms they provide toward the Main
>     Identifier.  The Domain Owners corresponding to the Main Identifier are
>     endowed with the possibility to receive feedback reports about
>     authentication results at receivers.  Finally, receivers are provided
> with
>     the Domain Owners' desiderata about messages that fail authentication,
> which
>     receivers may or may not decide to conform to.
As I stated above, I believe the better path for the working group is to
adjudicate draft-ietf-dmarc-dmarcbis-01. That revision contains a section
labeled "Introduction", you have proposed alternate text for that section,
let's discuss that section on the list, come to a consensus, and do it all
under the auspices of ticket 113.

But that's just my opinion...


*Todd Herr* | Sr. Technical Program Manager
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.