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

Alessandro Vesely <> Wed, 20 January 2021 18:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7A403A11FB for <>; Wed, 20 Jan 2021 10:58:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Status: No, score=-2.382 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Z_8AGPw7vLPt for <>; Wed, 20 Jan 2021 10:58:27 -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 0F9903A11F9 for <>; Wed, 20 Jan 2021 10:58:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1611169103; bh=F3N1CtVrqHWSRwcjJxpGC4OSJtLDZeROO1h4h6BGXF8=; l=3826; h=To:References:From:Date:In-Reply-To; b=AcipXkMcPSKvcq2SsUGETCkzbCFUYyCZDkdU/6g0qxOVQxiPPn9oj0avS54BlD6Sr 71JRtm5dMnO5CZfQWBdb8R0Ziv0/t9lnk/XnxwI2OJIzGkbAxOqPaRbE6MfdEEwMkB avKdDopapgUQnzOVh92HOXSED23o9g6Dt1LAiQBTZXWawI2imtwoNsmge/gRq
Authentication-Results:; auth=pass (details omitted)
Original-From: Alessandro Vesely <>
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by with ESMTPSA id 00000000005DC0D1.0000000060087D4F.00005C45; Wed, 20 Jan 2021 19:58:23 +0100
To: John Levine <>,,
References: <20210120023151.3C86A6B7C86C@ary.qy>
From: Alessandro Vesely <>
Message-ID: <>
Date: Wed, 20 Jan 2021 19:58:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <20210120023151.3C86A6B7C86C@ary.qy>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
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 18:58:29 -0000

On Wed 20/Jan/2021 03:31:51 +0100 John Levine wrote:
> In article <> you write:
>> Can you provide more details, please?
>> Are you receiving reports by HTTPS, or have you not seen any reduction in
>> reports, or both, or other?

No, I didn't put a real server's URL.  Just this:
"v=DMARC1; p=none;, OR-https://service.example/report/;;"

> I didn't try Ale's OR- thing but I did add an https URL to my rua= tag and set up
> a web server to catch any POST or PUT traffic.

John's record looks more workable, but it's still fluffy:

"v=DMARC1; p=none; rf=afrf;,;"

> I suppose the good news is that nobody implemented the underspecified
> report URL in one of the earlier DMARC drafts.

It is not underspecified.  It specifies the /mailto:/ scheme.  With forward-looking shrewdness, it further specifies:  Other Methods

    The specification as written allows for the addition of other
    registered URI schemes to be supported in later versions.

However, one cannot make guesses about what a receiver would do with, say, rua=fax:+13165550321.  For mailto: they know to send a gzip attachment.  Nothing is specified for https:, even if the scheme is known.  OR-https: is an unknown pseudo-scheme which, as far as parsing is concerned, can be discarded just like https: and fax:.

Likewise, the spec provides for a registry of tags and says that unknown tags must be ignored.  Therefore it is possible to safely add a new tag.  Let's see two cases:

"v=DMARC1; p=none;, https://service.example/report/;, mailto:report@service.example;"
"v=DMARC1; p=none; ruap=, https://service.example/report/;, mailto:report@service.example;"

Using my OR- syntax, they would be, respectively:

"v=DMARC1; p=none;, mailto:report@service.example, OR-https://service.example/report/;"
"v=DMARC1; p=none;, OR-, mailto:report@service.example, OR-https://service.example/report/;"

One last case.  The user has an oldish mailto:-only record, the service introduces https: for those who can support.  The service can override the rua= thanks to step 8 of Section 7.1, Verifying External Destinations:

    8.  If a "rua" or "ruf" tag is thus discovered, replace the
        corresponding value extracted from the domain's DMARC policy
        record with the one found in this record.  This permits the
        Report Receiver to override the report destination.  However, to
        prevent loops or indirect abuse, the overriding URI MUST use the
        same destination host from the first step.

So we have:

"v=DMARC1; p=none;, mailto:report@service.example;"

at the verification record can specify a preferred reporting address:

"v=DMARC1; ruap=https://service.example/report/; rua=mailto:report@service.example;"

(Question: is it necessary to also specify rua= if it is unchanged?)

or it can use OR- syntax:

"v=DMARC1; rua=mailto:report@service.example, OR-https://service.example/report/;"

IMHO, both methods are valid and equally well interoperable.  We should choose the one that can be more easily and clearly specified.

For OR-, it is an advantage to be able to keep step 8 above unchanged.  OTOH, the concept of pseudo-scheme requires a new paragraph to be explained.  Perhaps we should provide tentative text, rather than examples?