Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested

Dotzero <> Fri, 04 June 2021 18:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E07113A1CF5 for <>; Fri, 4 Jun 2021 11:53:38 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 qN-65Udye250 for <>; Fri, 4 Jun 2021 11:53:34 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C2693A1CED for <>; Fri, 4 Jun 2021 11:53:34 -0700 (PDT)
Received: by with SMTP id h20so10310729qko.11 for <>; Fri, 04 Jun 2021 11:53:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8PEC893M9Pb8X29ndShp+sit3F7/g+OGRv5wToBSvxE=; b=M+pZFqO37Z18gVp0HvB1MOGX9y22w7bO2xOMWC0Rs0tw1hg5/0BGbyh1bmj1Vxs2mD MfZ+VnmfUDqtKxp391OTSaAaI4NoYvjI5I16AQDvsulvNQx2aGFxEfKlceB9cfX1bOCa YsnUNUhqnoPYj7ZUq3CReCX3WOpP7J56iirgt/ScRT4/1h3hftkphVe4UvD2cZdZ75XV JG0l5qmhJI8PNQtnC+lpOsuJxkhIiLPJGrlXiv00/RdLb/K4Het4BCW5ASJrpuMukXvo Nlk8wtqX65OO0WypBRWyYmTLPux2oGWWZIUT83x3t0UH1Yxz5ZqW31i4sdTraopT5UkN oqJA==
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:cc; bh=8PEC893M9Pb8X29ndShp+sit3F7/g+OGRv5wToBSvxE=; b=VRSbm83PCXNJ+sAm9Zf8dym90m/8FkL+B67amwK0nqb4rl7SfA6HTNKC0t/OADMn5D pRnRZbXQLfUZI6oqB7iBmrqUZYKB4QDK9b7CSyyk7R8QKfYY1kA6GZ0nmmJljNTUIogO tCglJbxddX71jqoWvLtd31bE34fYS8im5/FLwz756AQXJReJ1pKP4NTpEOXH1VPdDOwC 7IQLut2nxaSwjJMRCcVbi4m4ddBJLGtA8RocWWd3Tt6+tCCl7v45Is1+H38vh1oD2WJv HBZb7/QOsJR8IAUCmZT5w8sSJlspTaNxcxxFvxdjG7ep6mBMag1pNqzXi6qZi8Tagp9q RPJw==
X-Gm-Message-State: AOAM533qlFyZQtqFDKiacjsohZazfF30UymSAZo2++lIGADRlpg12Kki 2+1M9pcdouFU66RFjaFp1ixCDSNwTMI4lI+ZWGSRAXMyEX0=
X-Google-Smtp-Source: ABdhPJyathpA1Q5R4ShnG4xZXPF8asefE/FaydNu85efKKIsEguWOe+MF1i/BNMzfP79jE4TyfOHpJg7w/270tuIo2E=
X-Received: by 2002:a05:620a:704:: with SMTP id 4mr5715754qkc.66.1622832811923; Fri, 04 Jun 2021 11:53:31 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Dotzero <>
Date: Fri, 4 Jun 2021 14:53:20 -0400
Message-ID: <>
To: "" <>
Cc: "Brotman, Alex" <>
Content-Type: multipart/alternative; boundary="00000000000048dde905c3f53567"
Archived-At: <>
Subject: Re: [dmarc-ietf] Extensions in Aggregate Reporting - Feedback Requested
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: Fri, 04 Jun 2021 18:53:39 -0000

On Thu, Jun 3, 2021 at 8:48 AM Brotman, Alex <Alex_Brotman=> wrote:

> Hello folks,
> During our interim call last week the topic of extensions within the DMARC
> aggregate report came up.  There was a discussion about how to best
> introduce these, but also how they might be best used.  I noted three cases
> that I could see today; ARC, PSD, and BIMI.   And indeed we have tickets
> relating to the first two.  The original thought was that the aggregate
> draft would allow a place for extensions, and then additional drafts would
> define those within the IETF.  When -02 was originally being worked on,
> there was a thread about how we might like to see this, though not many
> responses.  The result is in section 4 of the -02 draft [1]. and I thought
> we'd enhance that as we progressed.  At the time, I didn't intend to limit
> the extensions to IETF-approved extensions, though wasn't sure how else
> this might be used by reporting entities (I mentioned domain reputation-ish
> things during the call).  I'd consider that if we don't enforce
> IETF-registered extensions, the receivers could still
>   ignore extensions they don't want to handle.  I'm also aware this could
> bloat a report in terms of size, though we've already indicated we don't
> seem overly concerned with the size of the XML body.  A few things I'd like
> to see the group reach consensus on are:
> 1) Extensions in their own section (as it is now) or within each <row>
> element
> 2) Must extensions be IETF-approved
> 3) If (2) is true, do we want to define any during the DMARCbis process
> (essentially a demonstration of how it is to be done)
> Thank you for your continued feedback
> 1:
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse & Messaging Policy
> Comcast

1) Extensions should be in their own extension and seperate from the core
reporting. There is a reason we call them "extensions".
2) Extensions used in reporting under the standard should be IETF-approved.
This is a standards body. Anyone can leverage standards for private use but
our focus as an IETF working group is interoperability. By requiring IETF
approval/registration it puts the extensions under IETF "Note Well" and
makes the extension public.

Michael Hammer