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

Todd Herr <todd.herr@valimail.com> Tue, 19 January 2021 14:02 UTC

Return-Path: <todd.herr@valimail.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB0F3A150C for <dmarc@ietfa.amsl.com>; Tue, 19 Jan 2021 06:02:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=valimail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHp4CPQhBqkV for <dmarc@ietfa.amsl.com>; Tue, 19 Jan 2021 06:02:56 -0800 (PST)
Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9832A3A150A for <dmarc@ietf.org>; Tue, 19 Jan 2021 06:02:56 -0800 (PST)
Received: by mail-qv1-xf30.google.com with SMTP id h13so9156228qvo.1 for <dmarc@ietf.org>; Tue, 19 Jan 2021 06:02:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=valimail.com; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=d/FxCOi56OO/ryxKDzvslpsbpM1CGsMG3RPwxcKw9D8=; b=RnJx6LjS1+FT80HavIhymHaJvl8Ir7y+gU27oDysI4ROoETIRgNCEHGcPnVahB6J1L yOVdRlyNs3kGiztWByVQfF3rpSSC+aQmGmQJUp3kQMFA0ShAKjnRGi7Iv58oV93yvZOo zgmMv+oB66noorW4KnoUtDco0qgSiZULtC+WsL4qbj9hZHzdi0cn1d71BGkFy1SzYJw8 MT7ZtJrHho00nd0xK0rQj5mliYl2CjtiepVKo6Bu44PTxHAcitIYhKEKsl4DqJPj9kEv cJiyUiDtPzauKrW4hMJ2sID6Ak5vA4dd58IO/79eORWuNCwm8EQjvdX4GoFor2y5fs1H j0VA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=d/FxCOi56OO/ryxKDzvslpsbpM1CGsMG3RPwxcKw9D8=; b=Mk4lh5rSaC1Haya+AAZg/TcNpZyxt3xUq1WzhgvUrSPZyAG9jJA8Ac4YpAwnpu3Z0O PGCdEYOd7/e5zMwwfy2QvpauQ0h8r2onHTYy4eXcK0X+iAauSzMsATDqLi5c51q6slLZ OXxtZqygCndcl8eEm2xDPwAyzbE8m0JVaFzhiDPAxTB9jzf3DfqsevGk8ylARdc70aCn V4tXYODmjnAoGjOt1MX5YAphda6SJWVWcU+2fiM+xTReKzhCmwLcVJIG3ZeXvrUibLNu SFd2r8kyPVGQlRk2Kkf6uVBbznvgtbRPdDQtJDhlCXKbIF7OYWf1ZfHS7CfAyqqTnBbv 9WUw==
X-Gm-Message-State: AOAM530PBIsKDNbG3HAAU/PlpXV3NQwwpZ/qgm9xzW+q2+BDz69XGjoK sY9Im+KHiSnbhjn5kR9hxn3FnSX8D2t/RkoYVyp9TnxEswMDqA==
X-Google-Smtp-Source: ABdhPJz3cghtO+TUI0QoJgFqMEGi1i0GCZUXOqBrIqBTGfApZkfdTgMJijQIb96oXJxk83fTn7jpKJXEGBHSE0DLqi4=
X-Received: by 2002:a05:6214:c27:: with SMTP id a7mr367320qvd.54.1611064975305; Tue, 19 Jan 2021 06:02:55 -0800 (PST)
MIME-Version: 1.0
References: <eb3d06f-c89f-2511-3528-d421473e4d42@taugh.com> <a67a4e98-2be0-e2e2-2595-c12d9b87c4df@taugh.com> <7d3be6c4-aa17-3c34-d8f0-4df51e46ccc1@tana.it> <f12991fe-fded-6c0-528c-3b879b4a670@taugh.com> <8b6605de-ca01-904c-de78-deae254e0891@tana.it>
In-Reply-To: <8b6605de-ca01-904c-de78-deae254e0891@tana.it>
From: Todd Herr <todd.herr@valimail.com>
Date: Tue, 19 Jan 2021 09:02:39 -0500
Message-ID: <CAHej_8nwEh8SXN1_WJ-QRFCZ1bUEDb1H3w-5WoB=wRcL_NzYcw@mail.gmail.com>
To: IETF DMARC WG <dmarc@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000904d8f05b9414bb5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/gH745Jr2hriRD0xiuWd7f85fVNw>
Subject: Re: [dmarc-ietf] Ticket #42 - Expand DMARC reporting URI functionality
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2021 14:02:59 -0000

Picking up the thread on a ticket that was brought before the group
pre-holidays and has lain fallow since the end of 2020...

In reviewing the discussion, I don't believe a consensus has emerged on how
to implement this feature, or even whether to do it.

John proposed a new tag, ruap, for specifying HTTPS URIs (along with mailto:
and supposedly others that may be implemented in the future), while Ale
proposed different ways to express it in the existing rua tag.

Concerns were voiced about interoperability impacts for Ale's suggestions,
and Ale committed to running an experiment to see if there were changes to
his inbound report flows when he implemented one variant for expressing the
URI in the rua tag (     v=DMARC1; p=none; rua=mailto:local@example.com,
mailto:report@service.example, OR-https://service.example/report/;), but
there have been no subsequent posts by him to the list to report on results.

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.

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.

As editor, I seek guidance from the working group on how to proceed here.

On Thu, Dec 31, 2020 at 11:35 AM Alessandro Vesely <vesely@tana.it> wrote:

> On Thu 31/Dec/2020 16:37:38 +0100 John R Levine wrote:
> > On Thu, 31 Dec 2020, Alessandro Vesely wrote:
> >
> >> On Wed 30/Dec/2020 22:23:20 +0100 John R Levine wrote:
> >>> [ add ruap= to allow https in preference to mailto ]
> >>
> >> I still like better sticking to a unique tag (rua=) and applying
> OR-slashes.
> >> With a comma, it is backward compatible:
> >>
> >> v=DMARC1; p=none; rua=mailto:local@example.com, mailto:
> report@service.example, /https://service.example/report/;
> >
> > No, it's invalid according to the syntax in RFC 7489.
>
>
> I see.  We have:
>
>      dmarc-auri      = "rua" *WSP "=" *WSP
>                         dmarc-uri *(*WSP "," *WSP dmarc-uri)
>
>      URI             = scheme ":" hier-part [ "?" query ] [ "#" fragment ]
>
>      scheme      = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )
>
> So /https cannot be a scheme.  How about:
>
>      v=DMARC1; p=none; rua=mailto:local@example.com, mailto:
> report@service.example, OR-https://service.example/report/;
>
>
> > We have no idea what existing implementations do with DMARC records with
> syntax errors.
> >
> > Here's an experiment -- put that slash syntax in the rua= in your DMARC
> record
> > and see who does or doesn't continue sending reports.
>
>
> Done, with the second alternative.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.herr@valimail.com
*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.