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

[Todd Herr <[e-mail]>]

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:[e-mail],
mailto:[e-mail], 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 <[e-mail]> 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:[e-mail], mailto:
> [e-mail], /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:[e-mail], mailto:
> [e-mail], 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [e-mail]
*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.