See below.
On Fri, May 24, 2019 at 2:39 PM Jim Fenton <fen...@bluepopcorn.net> wrote:
> 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.
>
> I think you are underestimating the deployment. Many receiving/validating
> organizations have privacy concerns about promiscuously disseminating
> reports. As a result, these organizations limit reports to senders with
> which they have either direct contractual relationships or intermediaries
> with which they have contractual relationships. Personally I would prefer
> to see more and better reporting but I recognize the issues involved. It's
> important to recognize that senders publishing DMARC records are indicating
> their policy preferences to receivers which choose to validate for DMARC.
> Receivers which choose to validate DMARC are not required to provide
> records in response to sender requests. I know that reporting is valuable
> for senders and to the extent possible we should be finding ways to
> encourage and support reporting.
>
Michael Hammer
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
