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

Hector Santos <> Wed, 20 January 2021 13:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 367633A11FF for <>; Wed, 20 Jan 2021 05:08:43 -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 (1024-bit key) header.b=eS0uCxp3; dkim=pass (1024-bit key) header.b=UQPHAoSZ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KKe1wkojAP3E for <>; Wed, 20 Jan 2021 05:08:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A8A83A11FE for <>; Wed, 20 Jan 2021 05:08:38 -0800 (PST)
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2062; t=1611148114;; atpsh=sha1; h=Received:Received:Received:Received:Message-ID:Date:From: Organization:To:Subject:List-ID; bh=5Hi0HPddWdAbOMBHhb2kCABjSodu gusJh6pVtJtwbpQ=; b=eS0uCxp3xfQ58ulNnQ7kv1DM2NIumG0dJSch87ZC2yzb DQy31v6/IWbLyJbX5+0z3GYuGXwARi6CW/WPlDvicQl/+gNXN1k8rUTFzb+khFAe KxGkOD72ILWiIIHqLyUAf+mKdnOH1Tse5JNGA0bUBTFgrq/+f2XUv8bLIQe3wi8=
Received: by (Wildcat! SMTP Router v8.0.454.10) for; Wed, 20 Jan 2021 08:08:34 -0500
Authentication-Results:; dkim=pass header.s=tms1; dmarc=pass policy=reject (atps signer);
Received: from ([]) by (Wildcat! SMTP v8.0.454.10) with ESMTP id 293189516.1.3592; Wed, 20 Jan 2021 08:08:33 -0500
DKIM-Signature: v=1;; s=tms1; a=rsa-sha256; c=simple/relaxed; l=2062; t=1611147700; h=Received:Received: Message-ID:Date:From:Organization:To:Subject:List-ID; bh=5Hi0HPd dWdAbOMBHhb2kCABjSodugusJh6pVtJtwbpQ=; b=UQPHAoSZFziaKtrhrt0H9W4 dPg54yH4HwWuIj/IUUd10QENfsHRUG3HjQQk5LxGdbJUbZz60b/ZZ+AE+jgYkmUf AlYqhkgOb72mO0NVm1jdzI6B+Pb5o0HNhTMjUVP1Qn4Jeg1buxQtTTiDGC4BoA+w kpMi1p4iJ7keyp2z2lZw=
Received: by (Wildcat! SMTP Router v8.0.454.10) for; Wed, 20 Jan 2021 08:01:40 -0500
Received: from [] ([]) by (Wildcat! SMTP v8.0.454.10) with ESMTP id 160037799.1.59648; Wed, 20 Jan 2021 08:01:39 -0500
Message-ID: <>
Date: Wed, 20 Jan 2021 08:08:30 -0500
From: Hector Santos <>
Organization: Santronics Software, Inc.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.8.1
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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 13:08:43 -0000

On 1/19/2021 2:22 PM, Todd Herr wrote:
> 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?

Yes, I saw. Allow me to clarify. Diffs in tags vs diffs in tag values.

Overall, I think we should not be "afraid" to invent use new tags. 
This is the main consideration I was pointing out.  Implementation 
MUST not fail with unknown tags.

However, with a known tag, in this case the reporting mechanism, I can 
see now the only delivery protocol defined was "mailto:"

I don't think we can add a "https:" here without probably causing some 
issue with some existing implementations, i.e. report generated by the 
assumed email address will fail (no delivery).  But we don't know for 
sure.  An implementation may not fail if its checking for the 
"mailto:" prefix. Reports would be skipped if HTTPS is not supported 
by the verifier.

I think we should add/defined the "https:" for the exist reporting tag 
ABNFs. The only one who will understand it are implementations with 
HTTPS delivery support only. Others will simply not be able to send a 
report to a domain that desires HTTPS delivery.

I think the worst that will happen is a non-https implementation will 
have one of the following:

1 - check for the prefix "mailto:" and extract the address at 6 position
2 - not check, assume plus 6 has the a valid address.

In each case, it will fail (no https delivery supported), #2 may be an 
a wasted delivery attempt to an invalid email address.

Hector Santos,