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
