Hi, Murray,
On 11/11/2014 02:52 AM, Murray S. Kucherawy wrote:
I've posted an update to the base draft, based on recent feedback from
Ned and others. Hopefully I've resolved all of the concerns
(especially the major ones), as the ISE would like to send the draft
to the IESG for conflict review in the next day or two. It also has
to begin formal review of its IANA Considerations section as soon as
possible.
Thanks to all who provided recent comments to lead us to this version.
I started earlier this week a review of -05. Please find below my
comments, I think most if not all of them also apply to -06. I didn't
have time to finish my review, but thought to send my comments 'as is'
(before -07 is published ;-)). Most of my comments are of type
'editorial nits', no big changes proposed ;-)
Regards,
/rolf
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.
Introduction:
[...] mail receivers have tried to protect senders [...]
Suggested:
[...] mail receivers have tried to protect senders and their own
users/customers [...]
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).
2.2 Out of Scope
Add:
o cousin domain attacks
3.1.2 Key Concepts
Last sentence: add a reference to this 'other referenced material'.
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'.
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?
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
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.
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?
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.
Suggested edit:
adkim: (plain-text; OPTIONAL, default is "r".) Indicates whether
strict or relaxed DKIM identifier alignment mode is required by the
Domain Owner.
Possible values:
r: relaxed DKIM identifier alignment mode required
s: strict DKIM identifier alignment mode required
See Section 3.1.4.1 for details.
and
aspf: (plain-text; OPTIONAL, default is "r".) Indicates whether
strict or relaxed SPF identifier alignment mode is required by the
Domain Owner.
Possible values:
r: relaxed SPF identifier alignment mode required
s: strict SPF identifier alignment mode required
See Section 3.1.4.2 for details
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:
adkim: DKIM alignment mode (plain-text; OPTIONAL, default is "r".)
Indicates whether [...]
aspf: SPF alignment mode (plain-text; OPTIONAL, default is "r".)
Indicates whether [...]
fo: (leave as it is)
p: Requested Mail Receiver Policy (plain-text; REQUIRED for policy
records). Indicates [...]
pct: Sampling rate (plain-text integer between 0 and 100, inclusive;
OPTIONAL; default is 100). Percentage of messages [...]
rf: Failure Reporting Format(s) (colon-separated plain-text list of
values; OPTIONAL; default "afrf"). Format to be used for
message-specific failure reports. [...]
ri: Aggregate Reporting Interval (plain-text, 32-bit unsigned
integer; OPTIONAL; default 86400). Indicates [...]
rua: Reporting URI(s) for aggregate data (comma-separated plain-text
list of DMARC URIs; OPTIONAL). Addresses to which aggregate feedback
is to be sent. A comma or exclamation point [...]
ruf: Reporting URI(s) for failure data (comma-separated plain-text
list of DMARC URIs; OPTIONAL). Addresses to which message-specific
failure information is to be reported. If present [...]
sp: Requested Mail Receiver Policy for subdomains (plain-text;
OPTIONAL). Indicates [...]
v: Specification Version (plain-text; REQUIRED). Identifies [...]
and then change the corresponding table in 10.4 as follows:
for p: use 'Requested Mail Receiver policy'
for sp: use 'Requested Mail Receiver policy'.
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'.
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.
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
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.
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.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
