For the stuff not already answered in my last reply to Dave:
On Sun, Dec 21, 2014 at 2:18 AM, Jim Fenton <[email protected]> wrote:
> [2.4 Out of Scope]
> >> Bullet 10: Again, DMARC doesn't do authentication, even for domains; it
> >> relies on other authentication mechanisms.
> > I originally thought this, too, but in fact DMARC does do authentication:
> >
> > DMARC asserts authenticity of the rfc5322.From field domain name.
> > That's a distinct semantic increment over anything SPF or DKIM do on
> > their own.
>
> What it does is different enough from SPF and DKIM that I think it's
> overloading the term "authentication" to use it again here. It doesn't
> contribute to a clear understanding. It looks at the results of SPF and
> DKIM, which operate at the domain level, so this bullet isn't really
> necessary.
>
Doesn't RFC5322.From also operate at the domain level in our context?
DMARC's filtering function is based on whether SPF or DKIM can provide
> an authenticated, aligned identifier for the message under
> consideration. Messages that purport to be from a Domain Owner's domain
> and arrive from servers that are not authorized by that domain's SPF and
> do not contain an appropriate DKIM signature can be affected by DMARC
> policies.
>
> [I think the additional "that domain's" will do it.]
>
Added.
> >> 5. DMARC policy record
> >>
> >> Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate
> >> characterization. If the query requirement matched perfectly with the
> >> DNS, DNS would have a way to determine the Administrative Domain without
> >> resorting to suffix lists and such. Just strike the sentence; this isn't
> >> relevant here anyway.
> > -08 doesn't have this language.
>
> Now section 5.1, paragraph 2. Honestly, this reads like marketing fluff
> that doesn't belong in a specification like this.
>
I don't have any trouble removing it. I think it was added to ward off
anyone that might claim "You shouldn't be using the DNS for this."
> >> 11.1 Discovery
> > 6.2.1 in -08
> >
> >> Mail Receivers can also discover reporting requests from the
> >> Organizational Domain. That should be mentioned here. But I'm a little
> >> confused why we have another Discovery section at all.
> > The text's use of the word 'corresponds' handles the mapping to org
> > domain, IMO.
>
> This is more of a comment about document organization. The previous
> sections have been talking about things that follow discovery of the
> policy record, and now when talking about aggregate reports there's
> another section about discovery. Why here; isn't this a little redundant?
>
It's mainly to say that there isn't a specific discovery process for
aggregate report details; it's already done. This might be a legacy from
ancient versions where there was a separate process. I'll tidy it up by
merging it into the previous subsection.
> SHOULD isn't strong enough for the Report Receiver to depend on. There
> are other ways to get the information that is encoded into the filename.
>
Like what?
> If the spec wants to suggest, "here's a nice file name format that you
> MAY want to use", that's fine. But SHOULD is both too weak if the
> recipient can't depend on it and too strong if it's merely advice.
>
I'm not so sure. If we're going to go with MAY, then we also need some
kind of signal that the filename used does conform to the proposed
encoding, or else there might be some attempt to extract report parameters
that simply aren't there.
> >> The privacy consideration here, which isn't obvious from the wording, is
> >> that users may currently use forwarding in a way that prevents the
> >> sender from determining the ultimate delivery address. DMARC has the
> >> potential to break that. This might be important in the case of a user
> >> that is trying to distance themselves from a stalker.
> > How is that a DMARC-specific 'exposure' consideration?
>
> Because it's the retrieval (or search for) the DMARC record might
> reveals that. But on rereading this, paragraph 4 addresses this
> sufficiently.
>
> New issue: Paragraph 3 refers to "Both report types" but since iodef was
> removed, it should just say "The AFRF report type".
>
That refers to the aggregate and detailed reports ("rua" and "ruf"), not
IODEF and AFRF.
-MSK
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
