On Sun 24/Jan/2021 19:46:58 +0100 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.
Good! That's much better than any other idea we've been discussing.
Say an external URI overrides a mailto:"u"; with a pair https:,mailto: and the
https: succeeds. Are mailto: URIs following "u" to be ignored? Answering yes
eases the job of a report generator, as it is enough to produce a report and a
verified list of URIs. Answering no may seem to ease the composition of DMARC
records; otherwise one has to pay attention to put external URIs toward the
end. Some examples are needed anyway.
You'll have to revert the order in your DMARC record.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
