Subject: Review of draft-kucherawy-dmarc-base-04

From: S Moonesamy <[email-masked]>
Date: Tue, 22 Apr 2014 11:53:19 -0700

Hi Nevil,

I reviewed draft-kucherawy-dmarc-base-04.  I am copying the review to 
Murray as a courtesy, and [email-masked] 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

---

From: [email-masked] (Martin Rex)
Date: Wed, 23 Apr 2014 02:30:45 +0200 (CEST)

> asking the question as there is "receiving SMTP server" in that sentence.

That would be silly.  RFC5322.From might contain no DNS domain to begin with.

> specifies a syntax for the Internet Message Format.

Some MTAs (sendmail?) seem to recreate an RFC5322.From from the Envelope,
in case that it is missing in the message.

-Martin

---

From: [email-masked]
Date: Tue, 22 Apr 2014 19:14:10 -0700 (PDT)

Do we really want to be discussing changes to this draft on the main 
IETF list?

> That would be silly.  RFC5322.From might contain no DNS domain to begin with.

It has to contain a domain. If it doesn't it's syntactically invalid. Here's
the relevant ABNF:

 from            =   "From:" mailbox-list CRLF
 mailbox-list    =   (mailbox *("," mailbox)) / obs-mbox-list
 obs-mbox-list   =   *([CFWS] ",") mailbox *("," [mailbox / CFWS])
 mailbox         =   name-addr / addr-spec
 name-addr       =   [display-name] angle-addr
 angle-addr      =   [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
 obs-angle-addr  =   [CFWS] "<" obs-route addr-spec ">" [CFWS]
 addr-spec       =   local-part "@" domain

There's no way through that doesn't include at least one addr-space, which in
turn contains a domain.

> > specifies a syntax for the Internet Message Format.

See the table in section 3.6. It says that the minimum number of from fields
in the header is 1.

> in case that it is missing in the message.

Indeed they do. It's a reasonable action to take on message submission.
Relay is more ... interesting.

				Ned

---

From: Mitch Rodrigues <[email-masked]>
Date: Tue, 22 Apr 2014 20:02:59 -0700

I don't see why we wouldn't, discussions regarding this draft have been going for quite some time. Might as well get community support regarding this, plus if nothing else it's fairly interesting subject.

Mitch Rodrigues / Software Engineer
Telmate
655 Montgomery Street, 18th Floor
San Francisco, CA 94111
Email  
Office www.Telmate.com |www.GettingOut.com | GettingOut Facebook

> On Apr 22, 2014, at 7:14 PM, [email-masked] wrote:
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 23 Apr 2014 00:24:35 -0700

On Tue, Apr 22, 2014 at 8:02 PM, Mitch Rodrigues <[email-masked]> wrote:

> I don't see why we wouldn't, discussions regarding this draft have been
> going for quite some time. Might as well get community support regarding
> this, plus if nothing else it's fairly interesting subject.
>

Might I suggest [email-masked]?

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 23 Apr 2014 00:54:16 -0700

Hi Mitch,
At 20:02 22-04-2014, Mitch Rodrigues wrote:
>I don't see why we wouldn't, discussions regarding this draft have 
>been going for quite some time. Might as well get community support 
>regarding this, plus if nothing else it's fairly interesting subject.

The review was for a draft being processed as an Independent 
submission.  Publication is intended to be done outside the IETF 
process.  Although the subject is interesting it would not be 
productive to discuss about it on the main IETF mailing list given 
the IETF is not taking a decision about that.

It would make life easier for the authors (of the draft) if the main 
IETF mailing list was not used to get community support.  That 
mailing list is well-known for unmanaged discussions; that can turn 
into an unpleasant experience.

>Might I suggest [email-masked]?

I am okay with that.

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Apr 2014 10:35:19 -0700

> That would be silly.  RFC5322.From might contain no DNS domain to begin with.

That was legal for RFC 733.  Apparently I dropped it for RFC 822.

The idea of an online surrogate (Sender:) for an offline author (From:)
was a friendly construct, but it didn't prove useful.

So a From: field address with no domain name has never been valid for
"Internet" email.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Pete Resnick <[email-masked]>
Date: Wed, 23 Apr 2014 13:28:58 -0500

On 4/23/14 12:35 PM, Dave Crocker wrote:
>> RFC5322.From might contain no DNS domain to begin with.
>>      

Well, except http://tools.ietf.org/html/rfc6854

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Apr 2014 11:40:24 -0700

> Well, except http://tools.ietf.org/html/rfc6854

You seem to be saying that that doc counters my assertion.

This is a classic example of the problem with such a generic pointer: 
it leaves the reader to search through the document to find the 
essential bit of text.  And alas in my case, I failed.

I do not see anything in that doc that makes it valid to have a From 
field with no domain name.

d/

ps.  If indeed that doc re-introduced that bit of flexibility, it needs 
to be fixed.

---

From: Pete Resnick <[email-masked]>
Date: Wed, 23 Apr 2014 14:01:41 -0500

> field with no domain name.

Sorry for being obscure. 6854 says:

    from = "From:" (mailbox-list / address-list) CRLF

And from 5322:

    address-list    =   (address *("," address)) / obs-addr-list
    mailbox-list    =   (mailbox *("," mailbox)) / obs-mbox-list
    address         =   mailbox / group
    mailbox         =   name-addr / addr-spec
    name-addr       =   [display-name] angle-addr
    angle-addr      =   [CFWS] "<" addr-spec ">" [CFWS] /
                        obs-angle-addr
    group           =   display-name ":" [group-list] ";" [CFWS]
    display-name    =   phrase

Which makes the following legal (from the examples in 6854):

       From: Nightly Monitor Robot:;

pr

---

From: [email-masked]
Date: Wed, 23 Apr 2014 11:52:44 -0700 (PDT)

> > Well, except http://tools.ietf.org/html/rfc6854

Pete's right; I forgot about this update.

> You seem to be saying that that doc counters my assertion.

It does. RFC 6854 changes the syntax of From: header fields to allow an
address-list. The ABNF from there is:

Note that group list is optional, so something like:

  From: group: ;

is now legal. In fact RFC 6854 contains this example:

I don't see a domain in there. Do you? I note that RFC 6854 exists precisly
because of the legitimate applications I've been talking about that need a way
to generate a legitimate message.

And IMO DMARC needs to take such usage into account.

				Ned

---

From: "John Levine" <[email-masked]>
Date: 23 Apr 2014 22:53:53 -0000

>field with no domain name.

Section 2.1:

In RFC 5322 sec 3.4:

So this is valid:

 From:  Redacted for your own good :;

That's deliberate; the use case we had in mind is EAI mail downgraded
by a POP or IMAP server where there's no way to turn the EAI address
into an ASCII address.

R's,
John