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

[John Levine <[e-mail]>]

In article <[e-mail]> you write:
>On Tue 01/Dec/2020 23:21:48 +0100 John R Levine wrote:
>> We can adapt the approach MTA-STS uses in RFC 8460.
>> 
>> If rua= has an https URI, the reporter uses HTTP POST to that URI with
>> the report as an uncompressed or gzipped XML file as the POST body.
>
>TL;DR: neutral
>
>Delivery via https, with possible retry queue, imposes an additional burden to 
>report producers.  Since there seem to be less producers than consumers, it may 
>be fair to grant the choice of transport to the former.  That is, to make the 
>mailto scheme mandatory and https optional.
>
>Even if the the spec allows consumers to specify the transport they like 
>better, there will probably be producers which only honor one type.  So, 
>consumers may want to specify both schemes anyway.

That seems reasonable to make mailto: mandatory and https: optional if
you have an rua tag. I wouldn't expect reporters to provide queueing
if https fails, and mailto is certainly not going away. But if both
are available, http is a lot faster.

>A better means to control report size is to gauge the reporting interval.

When this came up before someone said that reports can be extremely
large, many megabytes.  An HTTP POST or PUT is a much better way to send that.

Here's another nit: POST doesn't pass the report's filename. There
should be a copy of the name in the header of the gzip data, but
semantically it would be better to do an https PUT to
<url>/<filename>. That also has the advantage of being idempotent so
if it puts the same file twice the server can tell it's a duplicate.

R's,
John