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 <dd3da825-bb39-6c37-762c-39ce5422f...@mtcc.com> 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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
