Re: [dmarc-ietf] draft-kucherawy-dmarc-base updated (-06)

["Murray S. Kucherawy" <[e-mail]>]

Hi Rolf, getting back to your review (thanks for the nudge):

On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld <
[e-mail]> wrote:

>
>
> Abstract:
>
> This lack of cohesion has several effects: receivers have difficulty
> providing feedback to senders about authentication, senders therefore have
> difficulty evaluating their authentication deployments, and as a result
> neither is able to make effective use of existing authentication technology.
>
>
> This focuses on the reporting function of DMARC, leaving out the policy
> part of it.
>
> Suggested text:
>
> This lack of cohesion has several effects: senders have difficulty
> providing information about their use of an authentication policy and
> receivers have difficulty determining a disposition preferred by senders.
> Vice versa, mail receivers have difficulty providing feedback to senders
> about authentication, senders therefore have difficulty evaluating their
> authentication deployments, and as a result neither is able to make
> effective use of existing authentication technology.
>
>
The Abstract appears to have been rewritten since you reviewed it, so a
straight text swap won't work anymore.  The new text focuses on what's
being provided, not what was missing.  Do you want to take another run at
it?


>  Introduction:
>
> [...] mail receivers have tried to protect senders [...]
>
>
> Suggested:
>
> [...] mail receivers have tried to protect senders and their own
> users/customers [...]
>
> This text no longer appears in the draft.


>  Starting with "DMARC allows domain owners and receivers to collaborate
> by", the terms 'domain owners', 'receivers', 'senders' and 'SMTP
> receivers', 'Mail Receivers', 'mail receivers' are used throughout the
> document. I'd suggest to add a definition of the term ' Mail Senders' to
> the introduction part of chapter 3 and then use only the terms as defined
> in 3., throughout the document. Suggested text for the term Mail Sender:
>
>
>    - Mail Sender: the sender of mail with a domain for which the Domain
>    Owner may have published a DKIM public key and/or an SPF authentication
>    record and/or a DMARC policy;
>
>
> (although we may want to not mention DKIM or SPF here).
>

It looks like that got cleared up; -08 has no reference to "Mail Sender".


> 2.2 Out of Scope
>
> Add:
>
> o    cousin domain attacks
>
Covered in Section 2.4 of -08.


>  3.1.2 Key Concepts
>
> Last sentence: add a reference to this 'other referenced material'.
>
Good idea; added.

>  3.1.3 Flow diagram
>
> The box titled 'User Mailbox' could give the impression that there's only
> one choice for delivery. However, quarantining can be done without delivery
> to a mailbox. I'd suggest to label this box 'rMDA'.
>
That's already done in -08.


>  The part within parentheses of step 6:
>
>   6. Recipient transport service conducts SPF and DKIM authentication
> checks by passing the necessary data to their respective modules, each of
> which require queries to the Author Domain’s DNS data (when identifiers are
> aligned; see below).
>
>
> might indicate that SPF and DKIM authentication checks need not be
> performed when identifiers are not aligned. However, for sake of reporting,
> SPF and DKIM authentication checks will in general always be done, or am I
> missing something?
>

I can envision a DMARC implementation that skips SPF or DKIM checks if the
corresponding identifiers are not aligned, because they won't be
interesting to DMARC in that case.

> 3.1.4.1 DKIM-authenticated Identifiers
>
> remove (or change) the 'Cousin Domain' example: it doesn't hold when a bad
> actor is signing the mail with d=cousindomain and
> RFC5322.From=localpart@cousindomain
>

It's not there in -08.


>  4 Use of RFC5322.From
>
> Last bullet (The DMARC mechanism ...). It seems the other bullets provide
> reasons why RFC5322.From is chosen while the last one does not. It looks to
> me as a circular reasoning.
>
It's not there in -08.


>  5.2 DMARC URIs
>
> It is not clear from the text what the report originator must do when the
> report payload exceeds the maximum size as indicated by the record. Should
> it not send anything, should it split up reports, should it notify the
> requester that there was a report exceeding the maximum size?
>

Section 6.2.2 in both versions explains what to do here.


>  5.3 General Record Format
>
> adkim and aspf do not provide a list of all possible options (like is done
> for fo and p). Of course it is pretty obvious that for 'strict' the 's'
> must be used, but it's not clear from the text.
>
They're there in -08.

> Next, the P: and pct: tags: they show that (in hindsight) the policy part
> and the reporting part of DMARC might have been better off, when they were
> defined in different specs. Now we need to complicate the text to say that
> the policy tag p: is required, but not for third-party reporting records.
> And for pct, that it "MUST NOT be applied to the DMARC-generated reports".
> Well, I believe this has been discussed before, no need to redo this
> discussion.
>
> I'd suggest to synchronize the short description of the tags in 5.3 with
> the descriptions of the tags in the table of 10.4 (now different
> terminology is used here and there, for example Requested Mail Receiver
> policy (5.3) and Requested handling policy (10.4). Suggested text in 5.3
> becomes then:
> [...]
>
Section 5.3 is meant to be verbose descriptions of each of the tags, while
Section 10.4 is a set of short, terse descriptions with references to the
places where the details can be found.  We could add section numbers to the
references found in 10.4 if you think that would be helpful.

> Further suggestion for the table in 10.4: reverse the order of 'p' and
> 'pct' as 'p' is first discussed in the text of 5.3, before 'pct'.
>

I see what you're after here, but as it is they're in alphabetical order,
like a dictionary, and I think that makes for easier referencing.

> Suggestion for 'ri': remove the normative language (MUST and SHOULD) as
> that might ask for a 'compliancy'  section. Instead, move these suggested
> values to the BCP document.
>
Well there is a normative component there, which is to say that anyone has
to be able to produce at least daily reports.  I think we have to at least
say that.  We (the IETF) seem to shy away from doing minimum compliance
sections these days.

>  5.6.2. Determine Handling Policy
>
> Bullet 6 in combination with the introduction text might give the
> impression that the receiver MUST always follow the policy as published by
> the Domain Owner. Suggestion to replace the text:
>
> 6. Apply policy. Emails that fail the DMARC mechanism check are disposed
> of in accordance with the discovered DMARC policy of the Domain Owner. See
> Section 5.3
>
> with:
>
> 6. Apply policy. Emails that fail the DMARC mechanism SHOULD be disposed
> of in accordance with the discovered DMARC policy of the Domain Owner. See
> Section 5.3
>
> Section 5 itself already has the equivalent of that SHOULD, followed by a
"MAY deviate" based on local policy.

>  5.6.3. Policy Discovery.
>
> This paragraph states that:
>
> If the RFC5322.From domain does not exist in the DNS, Mail Receivers
> SHOULD direct the receiving SMTP server to reject the message. The choice
> of mechanism for such rejection and the implications of those choices are
> discussed in Section 9.3.
>
> Although this might be common practice (either by default MTA settings, or
> by configuration parameters set by many mail operators), I believe this
> informational RFC about DMARC cannot use normative language here to decribe
> what must be done with mail with a domain that is not present in DNS.
>
This has been brought up before.  I think consensus has landed on the idea
that this is an acceptable thing to say because it applies only to
operators that are choosing to be DMARC participants.  Moreover, the SHOULD
ultimately enables you to make the choice for yourself if you think
bouncing mail from non-existent domains would be destructive.  And this is
what DMARC operators have been doing for a while now, so I'll also fall
back to noting that this specific effort is documenting current practice.
If the working group wants to make a different statement, it can crack this
topic open if and when it starts work on a version of DMARC along the
Standards Track.

 5.7 Last sentence:
>
> Mail Receivers SHOULD also implement reporting instructions of DMARC in
> place of any extensions to SPF or DKIM that might enable such reporting.
>
> Not sure what this means. But it seems to me DMARC cannot claim priority
> over other options/extensions in other IETF protocols.
>
This is another spot where the SHOULD gives the operator the choice to do
both if it wishes.  I can't remember off the top of my head what the use
case is here, but essentially the absence of a request for DKIM or SPF
reporting (as developed by the MARF working group some time ago) should not
preclude DMARC reporting, nor should their presence interfere with DMARC
reporting.

-MSK