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

[Alessandro Vesely <[e-mail]>]

On Sat 05/Dec/2020 22:06:38 +0100 John Levine wrote:
> In article <[e-mail]> you write:
> 
>> The VALCHAR element in Section 3.2 of RFC 6376 accepts "/", which is seldom used in email addresses and
>> ubiquitous in https URIs.  We could convene that when a mailto is to be considered as an alternative ...
> 
> If we want to do something like that, I would overload the existing
> !size hack. For example, add an "f" for finished flag and say that the
> URIs are conceptually processed from left to right and if you send
> your report to one with a !f (or !10mf or the like) flag, you can stop.


Legacy producers unable to interpret "f" may discard the whole URI.


> Still not convinced this is useful but it is slightly more backward
> compatible.


For backward compatibility, one could add a comma before the OR-slash:

v=DMARC1; p=none; rua=mailto:[e-mail], mailto:[e-mail], /https://service.example/report/;

A legacy producer will discard "/https" as an unknown scheme.  It would have discarded "https" as well.

Am upgraded producer can interpret a leading slash as introducing an alternative to the preceding destination.  Possibly, there can be a series of them, to allow for secondary servers in case the previous URI fails.  The first scheme without a leading slash introduces a new series of alternatives.

For compatibility, mailto has to be the first URI of each series.  Logically, however, it must be considered to be the last alternative.  In fact, sending mail can only fail if the local submission server is unavailable.  So it doesn't make sense to have multiple mailto's in the same series.  This, the fact that supporting mailto is mandated, and backward compatibility justify the logic exception.


Best
Ale
--