On Fri, 24 May 2019, Jim Fenton wrote:
I hope this isn't devolving into a "we can't make any changes, because
it might break something" argument.
I don't think so, but we also have a tradition of minimizing the changes
to what's needed. Look at RFCs 2821 and 5321 for example, where they
deliberately left the section numbering and most of the language alone and
fit the changes into the existing structure.
1. When an MTA product says that it "supports DMARC", does that mean
that it has to support both policy and reporting? ...
2. Along similar lines, I get confused when I hear that x% of {some set
of domains} has "deployed DMARC". What does that mean? ...
Deploying DMARC seems to mean any subset of these:
1a. Publish a DMARC record
1b. Publish a DMARC record with a restrictive policy
2a. Evaluate DMARC status of incoming messages
2b. Use that status to manage message disposition
3. Collect reports
4a. Send aggregate reports
4b. Send failure reports
It is my impression that most domains that have "deployed DMARC" have done
1b and 3. I've done 1a, 2a, 3, and a very small amount of 2b. Only a few
sites do 4a and even fewer do 4b.
I'm getting the impression that what we need is a non-normative deployment
guide, not as part of the spec.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
