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

Steven M Jones <> Wed, 20 January 2021 23:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DF323A15C0 for <>; Wed, 20 Jan 2021 15:10:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.362
X-Spam-Status: No, score=-2.362 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, NICE_REPLY_A=-0.262, 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 H2rtK2Ygn8YG for <>; Wed, 20 Jan 2021 15:10:28 -0800 (PST)
Received: from ( [IPv6:2001:470:1:1e9::4415]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F3DD3A15BF for <>; Wed, 20 Jan 2021 15:10:28 -0800 (PST)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.15.2/cci-colo-1.7) with ESMTPSA id 10KNAFn5047395 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Jan 2021 23:10:23 GMT (envelope-from
DKIM-Filter: OpenDKIM Filter v2.10.3 10KNAFn5047395
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201506-2k; t=1611184225; bh=OAxRfli3owxOBBzgBC8kh/n/sEKwYJqLPhiXmV0STHw=; h=Subject:To:References:From:Date:In-Reply-To; b=lBx4CAC4p5gPQ1gtmN9QNdhNocCZ2g5eBzlmsjWES0VTshZDBIhXgKDAjCARs8UJf AfmKXk1m3ESwzjl1QbTVeb+BPrVqF/rI7LmwcILEJVf5CRBNKsT1/h1vamhcr8eoCx o4GseR6dJBXahf2fewkn23VorknzQq9xaErOLzV/sUn8TKtZkN6grj9rZ4zRnDiecU CajQohI5ADUz9Qc0SPyerH8K7myFA3bhDteuKSsdDib1bNsPRrA7EAXg6u6hF1lng0 jAkhq6PJgJIyjLR9RO4ujuRRw6T2COPi/A4t3bHA2cYWSofp8q4Fk8APW8mthnlOSb D+L1tL8tYkp2Q==
X-Authentication-Warning: Host [] claimed to be
References: <20210120023151.3C86A6B7C86C@ary.qy> <> <>
From: Steven M Jones <>
Message-ID: <>
Date: Wed, 20 Jan 2021 15:10:14 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 ( []); Wed, 20 Jan 2021 23:10:23 +0000 (UTC)
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: Wed, 20 Jan 2021 23:10:31 -0000

On 1/19/21 06:02, Todd Herr wrote:
> Picking up the thread on a ticket that was brought before the group
> pre-holidays and has lain fallow since the end of 2020...

Prompted me to read from the start of the thread through:

On 1/20/21 11:19, John R Levine wrote:
> On Wed, 20 Jan 2021, Alessandro Vesely wrote:
>> John's record looks more workable, but it's still fluffy:
>> "v=DMARC1; p=none; rf=afrf;
> Whaddaya mean fluffy?  Try a PUT or POST to that URI and it'll work.

I think we should specify HTTPS URIs, and following 7489 section 12.6
"Secure Protocols" and current practices, HTTP should not be

However I don't yet see a compelling case for the OR- syntax or a
separate "ruap" tag. Duplicate reports to the same destination are not
the base case, and the bandwidth for unintended duplicates will likely
be much smaller than, say, per-message DNS tree walks being discussed
elsewhere. Report processors annoyed by receiving duplicates can work
with the domain owners in question, and if that doesn't work they can
withdraw their report authorization record.