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

[Alessandro Vesely <[e-mail]>]

On Wed 20/Jan/2021 03:31:51 +0100 John Levine wrote:
> In article <CAHej_8=K_x5xOw47XBtPYBWzCbfpPSAs=[e-mail]> 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; rua=mailto:[e-mail], OR-https://service.example/report/; ruf=mailto:[e-mail];"


> 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; rua=mailto:[e-mail],https://dmreport.abuse.net/dmreport/; ruf=mailto:[e-mail]"


> 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:

7.2.1.2.  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:[phone].  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; ruap=mailto:[e-mail], https://service.example/report/; rua=mailto:[e-mail], mailto:[e-mail];"
"v=DMARC1; p=none; ruap=https://example.com/dmarcaggr, https://service.example/report/; rua=mailto:[e-mail], mailto:[e-mail];"

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

"v=DMARC1; p=none; rua=mailto:[e-mail], mailto:[e-mail], OR-https://service.example/report/;"
"v=DMARC1; p=none; rua=mailto:[e-mail], OR-https://example.com/dmarcaggr, mailto:[e-mail], 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:

at _dmarc.example.com:
"v=DMARC1; p=none; rua=mailto:[e-mail], mailto:[e-mail];"

at example.com._report._dmarc.service.example the verification record can specify a preferred reporting address:

"v=DMARC1; ruap=https://service.example/report/; rua=mailto:[e-mail];"

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

or it can use OR- syntax:

"v=DMARC1; rua=mailto:[e-mail], 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?


Best
Ale
--