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:lo...@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 <ves...@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:lo...@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:lo...@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.h...@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.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
