Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality

Todd Herr <> Tue, 19 January 2021 19:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 095883A16F4 for <>; Tue, 19 Jan 2021 11:22:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, 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 cFjhJWuiwwIh for <>; Tue, 19 Jan 2021 11:22:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9FBAF3A16F1 for <>; Tue, 19 Jan 2021 11:22:20 -0800 (PST)
Received: by with SMTP id a1so9692607qvd.13 for <>; Tue, 19 Jan 2021 11:22:20 -0800 (PST)
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=RbHjtd694Q0NMR50bm+GNLE4emNDyDFx/3m5xYBb8XU=; b=LxzH0HvUHoleg2MpkOy1ORRfza9v9ynEhm/IbWUsIK1gRViUss7x271aXaO1fj8Tn4 WHDMGtpVAb2WFqZK8T3fbqc2qYcKjozTpwHX3B9DtFTPNvKdmDq+P5qg1EvYv+UiWOZv rEKZB5oAqBuS5HW5muDXmFTfT2qmbBeblZJMR47tFY2/YBnsXADaZriGG/4LKCmK7cT2 LPv2uKdkrsRI4HBptLdEustP5amnTC30Umh96D2Bz4NuYrnyr+KuIHRH9IjMMDvTlV3/ YN/4Hrpn7i5lSF18GjhKzS7uOIVAVCnhjtuUZeLKzDhaU9EEOHnr2LgspINgFRy7mVtT pR4A==
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=RbHjtd694Q0NMR50bm+GNLE4emNDyDFx/3m5xYBb8XU=; b=DaTuJtsN0DmW5iHlIQUR2PTdH1+h/pHdEMUtLaTPPcIo3+Ytnw6DC+j5/bBPL6J9Na Gm2Nj2MOTupnKElA8zxY6rrU1UozxGZj0eEnSEsM7iWSj/9Ky/Qqht7ooRA8Y1ojnf2s SVDoN65k9WiGktPtuPSgfuc/x/K0vJVG9pf476g0QvZZAMC1hDgAm5kFpFNCWq95W+ov 9u/V/Rs1A90Ymdvab/kIUac4cn67mxRfaFS/+qS9NC7RKHtOkls0iRdciDAe3F8D4j6R 8UEglQZ0478+eGZzMomNppa6yWYwg97K5xOByCsc4j62lZWWGw/iJpWeB++IcHrROcQL WyQg==
X-Gm-Message-State: AOAM532UGIF3vJfFeCnqHgQY8uCjCDHPa38cWSh6kjLjWypDpTdY18yE 8lO0CSeCySLXcZvwne9kLRas0It0N0U5BSUi18ztdErxSfrQHg==
X-Google-Smtp-Source: ABdhPJz9ZASYLFbIivEhg+jVSoHuinw8TROCgYiiDuaSyhoYO0NDMYG/cR6jOQBS9E90VOCgrX01uYh2S+EX4bPE3bc=
X-Received: by 2002:a05:6214:c27:: with SMTP id a7mr1830440qvd.54.1611084139175; Tue, 19 Jan 2021 11:22:19 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Todd Herr <>
Date: Tue, 19 Jan 2021 14:22:03 -0500
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000d1c25005b945c1e3"
Archived-At: <>
Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality
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, 19 Jan 2021 19:22:23 -0000

It seems that I was not successful in conveying my meaning in a few
statements, so allow me to try again...

On Tue, Jan 19, 2021 at 10:28 AM Hector Santos <hsantos=> wrote:

> On 1/19/2021 9:02 AM, Todd Herr wrote:>
> > Other concerns were raised about privacy and security issues that
> > might be inherent in and unique to adding this kind of functionality,
> > issues that may not have been fully discussed or understood by the
> > community over the years. There was also a question about whether or
> > not this is something that people are asking for.
> Reporting concepts were in the each DKIM Policy proposal (SSP, DSAP,
> ADSP) -- a "-r" tag option to send reports. The main concerns were
> unsolicited report abuse.   The DSAP proposal (my own) recognize it
> could be optional so it provided:

My mention of "other concerns ... about privacy and security" is in
reference to a post in this thread that Mike Hammer made in early December,
where he wrote:

"I don't recall a strong security and privacy concerns discussion around
HTTP(S) reporting. Presumably the report contents are protected in transit
but to what extent is access by arbitrary parties an issue. Notwithstanding
that things like GDPR are political issues, they are worth noting as a real
life operational consideration."

> > Hatless, it seems to me that the safest implementation of this
> > feature, presuming the security and privacy concerns can be addressed
> > to the satisfaction of those who raised them, would be to add a new
> > tag, as John has proposed, so as to minimize interoperability issues.
> > I say "minimize", rather than "avoid", simply because while RFC 7489
> > says "Unknown tags MUST be ignored.", I don't believe we can say with
> > 100% certainty that all implementations of DMARC policy record parsing
> > in the known world (both by report generators and third parties who
> > advise domains on how to publish DMARC records), implementations that
> > work now, won't "break" if a new tag is introduced. Of course, that'd
> > be their problem, not ours, because they weren't following the
> > existing rules.
> We can not continue to design Internet protocols without upward design
> considerations. This is part of the forward and backward compatibility
> design concepts.  Any problem would be a known tag with new
> functionality than originally expected. Sure, we can't say it will not
> happen, but its going to be a very low percentage, if any.  They have
> to fix it.
> > As editor, I seek guidance from the working group on how to proceed here.
> I am for a URI protocol method as part of the current tag rather than
> a new a separate tag.
> However, in principle, I don't see any issue with adding new tags,

I'm sorry, but I'm not clear on what position you're advocating here. You
assert that "any problem would be a known tag with new functionality than
originally expected" (which would seem to argue for using a new tag such as
ruap) but then you state that you're for a URI protocol method as part of
the current tag (which would seem to argue against using ruap, but instead
figuring out a way to add https: to rua), but then you state you don't see
any issue with adding new tags.

Can you help me understand your position better, please?


> My point is simple, extended tags MUST be part of the protocol's
> extendability. If there is evidence with 100% sureness there going to
> be a significant compatibility problem with legacy software that can
> not be corrected, then the only option is a new DMARC version 2
> resource record.
> I don't think we (I know I can't) can continue with DMARCbis without
> Extended Tag support and be hesitant to invent them because there is a
> compatibility problem.
I wasn't arguing against adding a new tag, merely being cautious, perhaps
overly so, in refusing to assert with 100% certainty that doing so won't
cause any problems.


*Todd Herr* | Sr. Technical Program Manager
*p:* 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.