Hi Nevil,
I reviewed draft-kucherawy-dmarc-base-04. I am copying the review to
Murray as a courtesy, and ietf(_at_)ietf(_dot_)org as there has been a lot of
discussion about the matter on that mailing list. I presume that a
healthy technical dialog with the authors is appropriate. I'll defer
to you on how to handle the review.
draft-kucherawy-dmarc-base-04 proposes a scalable mechanism by which
a mail sending organization can express, using the Domain Name
System, domain-level policies and preferences for message validation,
disposition, and reporting, and a mail receiving organization can use
those policies and preferences to improve mail handling. It's a
length document (76 pages). The mechanism builds upon IETF
specifications such as DKIM, SPF and ARF. I'll use the soon-to-be
published specification for SPF as a reference instead of the
reference listed in the document.
In my opinion the document is not ready for publication in the
Independent Submissions Stream. Overall, the is more discussion
about policy, anti-abuse, etc. compared to technical material. There
is a significant amount of tutorial material in the document. My
suggestion is to explain how the mechanism works, then provide the
details without getting into lengthy details unless the intention is
to set best common practices. The usage of RFC 2119 key words comes
out as prescribing requirements instead of focusing on
interoperability. The IANA requests seem problematic as it might not
fit the assertion of IANA allocations not requiring IETF action.
The main issue is that the proposed mechanism extends SPF to cover a
header field. That may work well with personal messages,
notifications about bank payments, etc. It can be overly restrictive
in cases where a MUA is not being used, e.g. someone entering his/her
email address for use as the author of a notification (see
https://mailarchive.ietf.org/arch/msg/httpbisa/CUCtnKhz133AXM_b9tVHZmn2O2Y ).
From Section 1:
"DMARC differs from previous approaches to policy advertisement (e.g.,
[SPF] and [ADSP]) in that:
o Authentication technologies are:
1. decoupled from any technology-specific policy mechanisms; and
2. used solely to establish reliable per-message domain-level
identifiers.
o Multiple authentication technologies are used to:
1. reduce the impact of transient authentication errors
2. reduce the impact of site-specific configuration errors and
deployment gaps
3. enable more use cases than any individual technology supports
alone"
I read the following:
http://forums.cpanel.net/f43/yahoos-new-dmarc-policy-causing-mailman-bounces-402751.html
http://digest.sialia.com/?rm=message;id=849627
It's difficult to determine whether there was a reduction in impact
compared to previous email authentication initiatives. DMARC
actually couples two email policy mechanisms instead of decoupling them.
DMARC attempts to solve the phishing problem (see Section 1.2) by
preventing bad people from sending mail which claims to come from
legitimate senders. Section 1.2 sounds like a mix between problem
definition and marketing. The following sentence is difficult to understand:
"Thus, DMARC is significantly informed by ongoing efforts to enact
large-scale, Internet-wide, anti-phishing measures."
The document then states that:
"Although DMARC can only be used to combat specific forms of exact-
domain spoofing directly, the DMARC mechanism is a substantial step
towards the creation of reliable and defensible message streams."
The above sentence tries to sell the technology.
From Section 2.1:
"One common attack on Internet users involves imitating mail from a
reputable mail sender while including malicious content of some kind.
The most damaging version of this attack, both to end-users and to
organizations, uses the RFC5322 From: address of the reputable
sender."
In simple terms, the technology is about protecting the email address
that is visible to the end-user.
According to Section 3, the document uses terminology from RFC
5598. I suggest further review of the document to ensure consistent
usage of the terminology in that RFC.
From Section 4:
"A Mail Receiver MUST consider an arriving message to pass the DMARC
test if and only if one or more of the underlying message
authentication mechanisms pass with proper identifier alignment."
The above sets a requirement based on underlying message
authentication mechanisms. I gather that it is the mechanisms
defined in Section 3.1.1.
From Section 6:
"Mail Receivers MAY choose to reject or quarantine email even if email
passes the DMARC mechanism check."
The above can be interpreted in two ways:
(a) The specification is getting into local (receiver) policy.
(b) The organization advertising a DMARC policy takes responsibility
for all messages that pass the DMARC mechanism check.
"Mail Receivers are encouraged to maintain anti-abuse technologies
to combat the possibility of DMARC-enabled criminal campaigns."
The above sentence does not belong in a document that defines a
mechanism. Who determines what is a criminal compaign?
"Mail Receivers need to make a best effort not to increase the likelihood
of accepting abusive mail if they choose not to comply with a Domain
Owner's reject, against policy."
The above sounds like preaching for anti-abuse.
"At a minimum, addition of the Authentication-Results header field
(see [AUTH-RESULTS]) is RECOMMENDED when delivery of failing mail
is done."
Why is that header field recommended as a minimum?
"Mail Receivers are only obligated to report reject or quarantine
policy actions in aggregate feedback reports that are due to DMARC
policy."
The above sentence binds or compels mail receivers. I don't think
that it is the purpose of a technical specification to set moral or
legal obligations.
"If local policy information is exposed, abusers can gain insight
into the effectiveness and delivery rates of spam campaigns."
It sounds like the document is also trying to mitigate spam problems.
"Mail Receivers SHOULD also implement reporting instructions of DMARC
in place of any extensions to SPF or DKIM that might enable such
reporting."
The above recommendation is to replace extensions defined in IETF
specifications with what is defined in the document.
From Section 7.3.1:
"Operators implementing this specification also implement an augmented
version of [AFRF] as follows:"
The above extends an IETF specification.
In Section 7.4:
"These reports SHOULD include as much of the message and message header
as is reasonable to support the Domain Owner's investigation into what
caused the message to fail authentication and track down the sender."
The recommendation looks like what one would usually see in a legal document.
In Section 8:
"If the RFC5322.From domain does not exist in the DNS, Mail Receivers
SHOULD direct the receiving SMTP server to reject the message."
Why is there such a recommendation? What is a mail receiver? I am
asking the question as there is "receiving SMTP server" in that sentence.
In Section 10.1:
"Have no RFC5322.From field (which is also forbidden under RFC 5322
[MAIL])"
Where is it stated in RFC 5322 that it is forbidden? That RFC
specifies a syntax for the Internet Message Format.
"Such messages SHOULD be rejected."
Why should such messages be rejected?
"Heuristics applied in the absence of use by a Domain Owner of either
SPF or DKIM (e.g., [Best-Guess-SPF]) SHOULD NOT be used, as it may be
the case that the Domain Owner wishes a Message Receiver not to
consider the results of that underlying authentication protocol at
all."
This is more of a reminder that there was agreement in some IETF
working group not to say anything about Best-Guess-SPF.
In Section 10.3:
"If email is subject to the DMARC policy of "quarantine", the Mail
Receiver SHOULD quarantine the message."
The above prescribes what the mail receiver should do.
"If email is subject to the DMARC policy of "reject", the Mail
Receiver SHOULD reject the message (see Section 15.4)."
The above has been a subject of debate on several mailing lists.
Section 14 is about privacy considerations. The mechanism proposed
in this document enables the domain name registrant to track usage of
its domain name in email across DMARC-compliant sites on the internet
without prior agreement between the relevant entities. Based on my
reading of RFC 6591 I think that the privacy considerations does not
explain the extent of the data exposure. The reader may construe
"sender and recipient identifiers" as the email addresses of the
sender and recipient only.
In Section 14.4:
"This document encourages use of secure transport mechanisms to
prevent loss of private data to third parties that may be able to
monitor such transmissions. Unencrypted mechanisms should be
avoided."
Given the state spying reports an encouragement to use secure
transport mechanisms sounds like a feeble attempt at securing the
private data which will be sent across the internet.
From Section 15.4:
"550 5.7.1 Email rejected per DMARC policy for example.com"
I note that the company that has been mentioned in DMARC discussions
does not follow the example given.
Section 16 describes IANA registry updates. I suggest contacting the
IETF Application Directors for information about the procedure to be
followed for the registry updates.
Section 16.4 defines a DMARC Tag Registry. The proposed registry
policy for new entries is to have "a published RFC that has had IETF
Review". I suggest that the authors contact the IESG for advice
about this registry. It is highly unusual to have a RFC in the
Independent Submissions Stream requesting the creation of a (IANA) registry.
From Section 17.4:
"Generally, display name attacks are out of scope for DMARC"
Are display name attacks out of scope or not? The above can be
interpreted as display attacks are out of scope when it is convenient
to say that. Section 17.4 discusses about mechanisms to mitigate
these attacks.
I read the appendices quickly. Appendix A.1 explains why S/MIME is
bad. Appendix B explains how SMTP works. Appendix C proposes a XML
Schema and descriptions of
PolicyOverrideTypes.
Regards,
S. Moonesamy