On 5/24/19 11:25 AM, John R Levine wrote:
> 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.
I consider that to be a different situation because both were Standards
Track. This is situation where we are starting with an Informational
RFC, although granted it has more deployment experience than many things
that go to Standards Track.
>
>> 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.
Although Section 8 of the spec currently has normative requirements for
implementations. Yes, that's different from deployment but having those
requirements to implement something that isn't deployed much (4a
specifically) seems unnecessarily burdensome.
-Jim
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
