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

Todd Herr <> Tue, 08 June 2021 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 253AF3A339D for <>; Tue, 8 Jun 2021 08:10:28 -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 pcLnoJ22M1XC for <>; Tue, 8 Jun 2021 08:10:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C1993A3397 for <>; Tue, 8 Jun 2021 08:10:20 -0700 (PDT)
Received: by with SMTP id l17so11371135qtq.12 for <>; Tue, 08 Jun 2021 08:10:20 -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=I2I89pnyAJM5HHJWwz+h/HGO2RIc4lfpoyc/m2Tm6mA=; b=TpsD0uqIMwm0t9p7YcCf5OSJQOscf+YiJVwZa3JIXxDlBMwJsBW/aMHky1FTFQlfuD FC1Yc4avpmS/EzqHq4TLO6Qf5kxgzwq/vS/OfOfY/jbjt/r6POWFQykQLbUyzMJq7v60 52X8pDZ0ZjOAFn/TdT6mHNQo3sAq0KWlg+ny1DOQ5RDAgd4cHMzwCSiQMlbeoHXzb0Mm SMY0piRgdKUSIhWFgzmRKrQBOuqt2TLA6qXaIlhUfbsHbsraLIp9x8CDqe/j297nL9pa INnOmqXqKuQgRsD0bRnSSAhls5w3M+VXOj5pUSENmASyzeoC87qWYPxhb230Zt8aGGmS Zy+Q==
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=I2I89pnyAJM5HHJWwz+h/HGO2RIc4lfpoyc/m2Tm6mA=; b=egs+D/WX1+zFgVDFUe6u0Slqa1Lq+cvO8fj+UI0ymTb87pY9Tl7A0WyF7LS73EFkJY H9w61jRbWaszIJYa5L1rZEY3DHrTbQyPc+DAy1qVXWFnhZm3ufX9OcvS9CfcLWK1ycCI KzGdIRsAgRlmMVJHQE+3bgwpmbBHQq4jzvhAbac+fefxiFOsnOL6dBPR4eFPqMO83WUh P67fE2v+ds1wokVpNajy9E2FPhY2WjuHyfoo2DNfoPSygBqAYBEgqQLeNvo13VjFcarp 30W3s/bbqLJaGqgyURq/D/p1ifi3p2kD5oPqaYMW/leyo0w37upWUxaslzvMvuYIezBl ZEJg==
X-Gm-Message-State: AOAM5316zWSALArRxnS7txbadBRHLkgFXPljHUr+ROfvLpl1YyABMdeL aKdSBlHyt/SUOvAUTqdHGMCCyDER3DAygURGXhcok1o6EgkXag==
X-Google-Smtp-Source: ABdhPJyxmD0sLi2NV1bcnCfujGktlKewPSq/7M7jbJzJ9B9tdzTae2nfqwKLx/PKRoxT3AZYq4cF/XUr+OMApnezgsk=
X-Received: by 2002:a05:622a:104b:: with SMTP id f11mr5314136qte.220.1623165019279; Tue, 08 Jun 2021 08:10:19 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Todd Herr <>
Date: Tue, 8 Jun 2021 11:10:03 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000062e6bd05c4428e7a"
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: Tue, 08 Jun 2021 15:10:28 -0000

On Thu, Jun 3, 2021 at 8:27 PM Dave Crocker <> wrote:

> On 5/5/2021 11:48 AM, Todd Herr wrote:
> We would like to achieve rough consensus on this section of text by
> Friday, May 21.
> Apologies.  I've only just been able to review this text.  Attached are
> suggested changes, done as a Word document with revision tracking turned on.
> It might appear that the edits effect major substance changes to the
> Introduction, but I believe they do not; the intent was to retain the same
> goals for the Introduction.
> Changes were driven by:
>    - Providing better lead-in for readers with less background on the
>    document's topic
>    - Eliminating detail that is not need in an introduction
>    - Minimizing PSO text, since I belive the covered domains have Domain
>    Owners whether they are PSOs or not; hence the fact of being a PSO has
>    minimal import in the Introduction
>    - General wordsmithing, to tighten things up
> Taking most of Dave's input into account results in an Introduction
section that will read as follows:

------------------------------------begin current proposed text
1. Introduction

   Abusive email often includes unauthorized and deceptive use of a

   domain name in the RFC5322.From header field.  The domain typically

   belongs to an organization expected to be known to - and presumably

   trusted by - the recipient.  The Sender Policy Framework ([RFC7208])

   and DomainKeys Identified Mail ([RFC6376]) protocols provide domain-

   level authentication but are not directly associated with the

   RFC5322.From domain.  DMARC leverages them, so that Domain Owners

   publish a DNS record indicating their RFC5322.From field:

   *  Email authentication policies

   *  Level of concern for mail that fails authentication checks

   *  Desire for reports about email use of the domain name

   DMARC can cover non-existent sub-domains, below the "Organizational

   Domain", as well as domains at the top of the name hierarchy,

   controlled by Public Suffix Operators (PSOs).

   As with SPF and DKIM, DMARC classes results as "pass" or "fail".  A

   pass from either SPF or DKIM is required.  Also the passed domain

   must be "aligned" with the RFC5322.From domain.  Domains are said to

   be "in alignment" if they have the same Organizational Domain, which

   is at the top of the domain hierarchy, while having the same

   administrative authority as the RFC5322.From domain.

   A DMARC pass indicates only that the RFC5322.From domain has been

   authenticated for that message.  Of course, authentication does not

   carry an explicit or implicit value assertion about that message or

   about the Domain Owner.  Indeed, a mail-receiving organization that

   performing DMARC validation can choose to follow the Domain Owner's

   requested disposition for authentication failures, and to inform the

   Domain Owner of the mail handling decision for that message.  It also

   might choose different actions.

   For a mail-receiving organization supporting DMARC, a message that

   passes validation is part of a message stream that is reliably

   associated with the RFC5322.From field Domain Owner.  Therefore,

   reputation assessment of that stream by the mail-receiving

   organization is not encumbered by accounting for unauthorized use of

   that domain in the RFC5322.From field.  A message that fails this

   validation is not necessarily associated with the Domain Owner's

   domain and its reputation.

   DMARC, in the associated [DMARC-Aggregate-Reporting] and

   [DMARC-Failure-Reporting] documents, also specifies a reporting

   framework.  Using it, a mail-receiving domain can generate regular

   reports about messages that claim to be from a domain publishing

   DMARC policies, sending those reports to the addresses specified by

   the Domain Owner.

   Use of DMARC creates some interoperability challenges that require

   due consideration before deployment, particularly with configurations

   that can cause mail to be rejected.  These are discussed in
   Section 9.
-------------------------------------end current proposed text

I expect that discussion of this topic will continue for some time.


*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.