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

[John R Levine <[e-mail]>]

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

At this point we're both just guessing what current code might do with 
syntax errors in a rua= tag.  Here's something that's definitely 
compatible:

We add a new ruap= tag for rua preferred, with the same syntax as rua.  If 
the reporting system can handle all of the URIs in the ruap tag, it uses 
them.  (They don't all have to successfully deliver, but it knows how to 
try.)  Otherwise it falls back to rua.  The goal here is that someone can 
put the new https: URI in ruap and the old mailto: URI in rua.

To send a report using the https: URI, the reporter appends the filename 
described in section 7.2.1.1 to the given URI and does a PUT of the 
report, with MIME type application/gzip if it's compressed an text/xml if 
not. The server responds with code 201 if the report is succesfully 
stored.

It'd be something like this if the URI is https://report.bar.com/dmarc/

PUT https://report.bar.com/dmarc/foo.com%21bar.com%211607068800%211607155200.xml.gz


Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly