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

[Michael Thomas <[e-mail]>]

any reporting needs to be authenticated. if you're going to use http, 
you need to show how you're going to do that.

Mike

On 1/24/21 11:08 AM, John Levine wrote:
> In article <[e-mail]> you write:
>> issue #99 needs to be addressed.
> I don't see any connection between issue 99 and this proposal.  This is not about failure reports.
>
> R's,
> John
>
>> On 1/24/21 10:46 AM, John Levine wrote:
>>> Here's a concrete proposal for https reporting:
>>>
>>> In draft-ietf-dmarc-aggregate-reporting, in the transport section,
>>> between Email and Other Methods add:
>>>
>>> Https POST
>>>
>>> The message is an XML file with GZIP compression, sent with an https POST message
>>> to the given URI as media type application/gzip.
>>> The data SHOULD contain the filename described in Email transport
>>> above as the filename in the gzip header. The filename helps recipient
>>> hosts recognize duplicate reports.
>>>
>>> In draft-ietf-dmarc-dmarcbis section 6.3 under the rua tag, add:
>>>
>>> If there is more than one URI in the value, the URIs are conceptually evaluated from
>>> left to right and each report is delivered to each URI in turn.
>>> If a delivery to an "https:" URI succeeds, any subsequent URIs that are not "https:" are ignored.
>>> This allows a report recipient to prefer https reports while falling back to mailto reports.
>>>
>>> R's,
>>> John
>>>
>>> _______________________________________________
>>> dmarc mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dmarc
>