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

["Rolf E. Sonneveld" <[e-mail]>]

Hi, Murray,

On 12/24/2014 06:45 AM, Murray S. Kucherawy wrote:
> 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] <mailto:[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?

No need for it, the text of the Abstract in -09 is OK.

>
>     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.

OK.

>     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".

OK.

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

OK.

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

Thanks.

>     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.

OK. Well, it's MDA, but that's OK. One typo in the diagram. When:

> "sMTA" is the sending
>     MTA, and "rMTA" is the receiving MTA.

is correct, the box in the diagram should be labelled 'sMTA', not 'oMTA'.

>
>     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.

Whether or not to generate reports in the case of non-alignment is not 
clear from the text, or am I missing something? Par. 3.1.3:

>     8.  If a policy is found, it is combined with the Author's domain and
>         the SPF and DKIM results to produce a DMARC policy result (a
>         "pass" or "fail"), and can optionally cause one of two kinds of
>         reports to be generated (not shown).

and par. 6.2 goes right into the format of reports, not the conditions 
under which a report is to be sent.

>     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.

OK.

>
>     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.

OK.

>     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.

OK.

>
>     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.

Excellent.

>     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.

Fair enough.

>     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.

A 'conformance' section, similar to what RFC2049 is for MIME, would be 
nice, indeed ;-)

>     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.

OK.

>     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.

This has been discussed in the recent thread 'Jim Fenton's review of 
-04', no need to redo this discussion.

>
>     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.

Then, borrowing from your text, may I suggest the following text:

    "Mail Receivers SHOULD implement reporting instructions of DMARC,
    even in the absence of a request for DKIM or SPF reporting [MARF].
    Furthermore, the presence of such requests SHOULD NOT interfere with
    DMARC reporting."


And as a general statement: thanks for all the work, Murray!

/rolf