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
<[email protected] <mailto:[email protected]>> 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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
