On 5/20/2020 11:49 AM, Dave Crocker wrote:
On 5/20/2020 8:29 AM, Kurt Andersen (b) wrote:
Agree 100%


This looks like it has a strong constituency against the proposal, a
much smaller constituency in favor of it, and little or no offered
benefit.  Yes?

Just like DKIM Policy had a "strong constituency" against DKIM Policy, yet, the wrong decision was made to abandon DKIM Policy, only to find out today (the last few years), it was the wrong decision. Just look at the support we have today for DKIM policy.

Whatever.

In regards to the report format, I am proposing an easy non-complicated compromise. Consumer will instantly benefit by offering additional registered report formats such as:

csv
json
xml  as the fall back.

The key is the register the tags, not mandate that verifiers need to support csv or json. I am proposing an new tag "prf=" to be recognized by standard DMARC verifiers but optional implementation of the registered tags csv and json. XML will be registered and required reporting format IFF reporting is offered by the verifier. Reporting is not a requirement.

Keep in mind DMARC specs need a major cleanup in this regard and many others. It mentions XML, but the "rf=" no longer defined. It says the tag is registered, but no description describing its possible values.

We need to stop this lock down methods and expand the desperately needed fix up for DMARC policy tags. We have discussed these issues but the "smaller" entities in this group are getting absolutely pushed out with no recognition. In the end, we get the usual, the "Follow the Chieftain" syndrome and other folks, who may agree, stay quiet or just agree with "chief" +1 -- no rocking of the proverbial boat.

Rough Consensus is good, but is not always correct.

--
HLS


_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Reply via email to