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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 00:45:39 -0500

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

On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld <
[email-masked]> 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

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 29 Dec 2014 23:29:21 +0100

Hi, Murray,

On 12/24/2014 06:45 AM, Murray S. Kucherawy wrote:
> On Wed, Nov 12, 2014 at 6:26 PM, Rolf E. Sonneveld 
> <[email-masked] <mailto:[email-masked]>> 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
> 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.

>         [...] mail receivers have tried to protect senders and their
>         own users/customers [...]
>

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

OK.

> Covered in Section 2.4 of -08.

OK.

>     Last sentence: add a reference to this 'other referenced material'.

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

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

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

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.

>     remove (or change) the 'Cousin Domain' example: it doesn't hold
>     when a bad actor is signing the mail with d=cousindomain and

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

OK.

>     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 ;-)

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

>         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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Dec 2014 20:36:17 -0800

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

Fixed.

> under which a report is to be sent.

Added an item at the end of the bullet list in 3.1.3.

> "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."
>
>
Done, with slight changes.

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

Anything to get this thing put to bed!

-MSK

---

From: Wei Chuang <[email-masked]>
Date: Thu, 01 Jan 2015 06:30:30 +0000

ni

On Wed, Dec 31, 2014, 8:36 PM Murray S. Kucherawy <[email-masked]>
wrote:

>>> 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'.
>>>
>>> which require queries to the Author Domain's DNS data (when identifiers are
>>> aligned; see below).
>>>
>>>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>