Subject: [dmarc-ietf] Calling for Input on DMARC Draft

From: "J. Trent Adams" <[email-masked]>
Date: Fri, 28 Feb 2014 18:06:36 -0700

DMARC Folks -

As you know, the authors of the DMARC specification have been looking to
find a home for the base document somewhere within the IETF.  We've
explored various options in the past year, and now it looks like we've
found the right path.

We have chosen to submit the DMARC specification via the Independent
Submission Editor (ISE). This will have three primary effects: (1) it
will be published with a permanent reference location; (2) it will be
classified as Informational rather than as a Proposed Standard; (3) the
ISE process is a much more direct path to publication.

A primary reason for this shift is that DMARC is already a mature
specification with broad adoption. We also want to help support its
continued deployment and provide a foundation for potential future
evolution. There are some related issues that still need to mature
further, such as reporting practices, domain boundary identification,
etc. To facilitate those work streams, it is important to publish a
referenceable version of the specification.

To support this effort, we are asking the community for input as we
prepare the current version for submission to the ISE. We are seeking
concise statements that can be incorporated into the specification
primarily with a focus toward clarity, readability, and utility. While
we're happy to continue cataloging suggestions for future work, our goal
is primarily to tighten up this version of the document. Please send
your comments to this IETF discussion list within the next week as we
intend to submit the final version of the specification to the ISE by
the close of the meeting in London.

Current Specification:
https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/

Also, if you happen to be at IETF 89 in London, you can corner Murray
Kucherawy and share your thoughts with him (as he has the pen on the
current draft)... though he'll probably suggest you send your specific
suggestions to the list, anyway.

Once the specification is published, our intent is to wind down the
loose collaboration effort known as DMARC.org.  The goal is to clearly
turn DMARC over to the community to maintain like any other open
specification.

On behalf of the original authors, we would like to extend our thanks to
everyone for being part of the effort thus far. DMARC is not perfect but
it's clear that it is having a substantial positive influence across the
ecosystem. We look forward to your final comments and hope to engage
with everyone on some other new and exciting work that will help improve
trust in email.

Thank you all,
Trent

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 28 Feb 2014 21:44:42 -0500

> DMARC Folks -
...
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/
...

I didn't have time for a detailed review of the entire document, but I did 
take a look at the SPF aspects of it and do have comments:

In Section 4, the next to last paragraph currently is:

   A Domain Owner may find that although its messages pass a particular
   authentication scheme's checks, it wishes not to have Mail Receivers
   consider those results as evidence that the message was authorized.
   In this case, the Domain Owner simply declines to advertise
   participation in those schemes.  For example, if the results of path
   authorization checks ought not be considered as part of the overall
   DMARC result for a given Author Domain, then the Domain Owner does
   not publish an SPF policy record.

It's slightly more correct to end with "SPF policy record that can produce an 
SPF pass result."  It is rare, but I have seen SPF records published that were 
only meant to produce fail results from known forgery sources.  Something like 
"v=spf1 -ip4:xxx.xxx.xxx.xxx ?all".  A record like this could never trigger a 
DMARC pass.

Section 3.1.4.2.  SPF-authenticated Identifiers says:

   DMARC provides the option of applying SPF in a strict mode or a
   relaxed mode.

   In relaxed mode, the [SPF]-authenticated domain and RFC5322.From
   domain must have the same Organizational Domain.  In strict mode,
   only an exact DNS domain match is considered to produce identifier
   alignment.

5.2.  General Record Format includes:

   aspf:  (plain-text; OPTIONAL, default is "r".)  Indicates whether
      strict or relaxed SPF identifier alignment is required by the
      Domain Owner.  See Section 3.1.4.2 for details.

The language doesn't seem quite parallel between the two.  3.1.4.2 talks about 
strict or relaxed mode while 5.2 talks about strict or relaxed SPF identifier 
alignment.  I figured out what it means, but it confused me for a minute (and I 
knew what meant to say before I read it).  I'd recommend changing (in 
3.1.4.2):

   DMARC provides the option of applying SPF in a strict mode or a
   relaxed mode.

to

   DMARC provides the option of applying SPF in strict or relaxed
   identifier alignment modes

and also changing (in section 5)

   aspf:  (plain-text; OPTIONAL, default is "r".)  Indicates whether
      strict or relaxed SPF identifier alignment is required by the
      Domain Owner.  See Section 3.1.4.2 for details.

to

   aspf:  (plain-text; OPTIONAL, default is "r".)  Indicates whether
      strict or relaxed SPF identifier alignment mode is required by the
      Domain Owner.  See Section 3.1.4.2 for details.

I think similar changes for DKIM in 3.1.4.1 and the adkim definition would be 
an improvement.

Since I've bitched about it enough previously, I'll mention that the 
discussion about SPF policy versus DMARC policy in 6.  Policy Enforcement 
Considerations (from -01) resolves my concerns about that text.

In section 10.2.4 there is a discussion about what must be included from the 
validation checks if there is an SPF pass.  I don't see any companion in 
formation about what information to carry forward from the SPF validation if 
it's not pass.  I wonder if it should be included.  It should be, in addition 
to the domain, the SPF result (there are several possible results that would 
cause it not to pass for DMARC purposes) along with any explanatory text (most 
all SPF implementations provide information beyond the bare result to assist 
in troubleshooting).

In 15.5, there is the phrase, "If malicious or unaware users can gain control 
of the SPF record or signing practices for a subdomain, ...".  I think that 
should be "If malicious or unaware users can gain control of the SPF record or 
DKIM signing practices for a subdomain, ..."

I B.1.1, the SPF alignment examples, I think it might be a bit confusing.  
When Mail From is in the same organizational domain and not the same, it's (in 
my experience) a subdomain to the From domain, not the other way around (which 
is what the example has).  I think the example would make more sense to most 
readers if the Mail From/From was reversed in the second example.  This would 
also be more consistent with the example in B.3.1.

I think this is significantly improved from -00, which is the last one I really 
had a chance to review.

Scott K