On 4/17/2023 9:43 AM, Scott Kitterman wrote:
OK. The discussion of the 5322.From comment through me off, I guess.
I think there's probably room for the IETF to document Bext Current Practices
(BCP) around DMARC usage. I think it's a step beyond the interoperability
discussion we need for the DMARCbis protocol document. Assuming we think we
know enough, we might consider that for additional WG scope after we have
(essentially) completed the currently chartered work.
From my readings, my support considerations are:
+1 Codifying a MUST NOT use p=reject for XYZ reasons,
+1 Changing status to Informational, Experimental.
We can't make this a "Standard" when the odds are extremely high there
is going to be many addressing this DKIM POLICY problem that could not
be resolved for the 2nd time in nearly 17 years, for the same
reasons. Thanks to DMARC. We have more DKIM Policy advocates today.
If have had this with ADSP, we would be debating MUST NOT use
"Discardable" instead use "All".
We should piggyback off DMARC calls. It would be nice to see support
by the key cogs for section 4.4.3 and Extended Tag Extensions.
Suggestion: Add some more text here regarding dealing with authorization.
I consider DMARC today as the new "railroad tracks," the DNS method to
get a mail operations policy from the Author Domain. But its policies
are incomplete. We need to recognize there are other policies other
than the most restrictive with perfect alignment. We had more
flexibility with SSP and a few with ADSP "must be signed by me" and
"must be signed by someone." More flexible.
--
Hector Santos,
https://santronics.com
https://winserver.com
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
