Subject: [dmarc-ietf] Review of draft-kucherawy-dmarc-base-00

From: Scott Kitterman <[email-masked]>
Date: Mon, 15 Jul 2013 00:38:24 -0400

In the introduction, there is a discussion about the RFC5322.From field being 
the primary identifier in the DMARC mechanism and how DMARC is leveraging SPF 
and DKIM, but nothing about how DMARC is connecting 5322.From to either the d= 
signing domain for DKIM or the 5321.MailFrom for SPF.  For a reader that knows 
anything about either of those, it will be confusing, since neither of the 
technologies that DMARC is leveraging have anything to say about 5322.From.

I don't think 2.4.  Experiment Team belongs in an IETF draft.

Section 3.  Requirements should be stricken and to the extent these 
requirements are still relevant to the intended draft/RFC they should be 
captured in the WG charter.  The requirements are inconsistent, in some cases 
conflicting, and not all satisfied by the current design.  Any reference to 
requirements should be to ones that are still operative.

Section 4: Terminology:

If domain owner is analogous to the existing email-arch term ADMD, just use 
that instead of inventing another term for the same thing.

Similarly, I don't find Mail Receiver in 5598 either.  It would be better to 
use existing, consistent terminology.

The concept of organizational domain is critical to applying identifier 
alignment correctly, but it's impossible to do so based on the information in 
the spec.  I'm not sure what the solution is, but this seems like a 
substantial mess in the making.

Section 4.3 implies that SPF HELO checks are only done if 5321.MailFrom is 
null.  This is not correct.

In Section 4.3.1, I know what's meant by DKIM relaxed mode due to the example, 
but the normative text is not at all clear.  I would not consider 
"news.example.com" and "example.com" to be "equal".  Relaxed is equal and 
strict is identical doesn't parse.

Section 5:

>    A Mail Receiver implementing the DMARC mechanism MUST make a best-
>    effort to adhere to the Domain Owner's published DMARC policy when a
>    message fails the DMARC test.

We're about a decade into working on email authentication technology (SPF 
started in 2003, it has older antecedents).  For almost all of that time we've 
been working with a construct that senders don't get to dictate receive 
policy.  I think a 2119 MUST is wrong here.  I think it's up to the draft and 
the DMARC community to explain why receivers would want to do this, but MUST 
is the wrong way to go about this.  It's certainly a novel approach that 
warrants consideration and not just swallowing whole, unexamined.

Section 6.1.  Apparently people get confused about when bytes are supposed to 
have 1,000 bits and when they are supposed to have 1,024 bits plus mail 
sometimes gets sent 7 bit and sometimes 8 bit, so something that starts out on 
disk as a 50MB file can be substantially larger at the receiving MTA.  I would 
suggest some additional precision about what it meant by file size would be 
appropriate to ensure a common understanding and avoid interoperatility 
problems.

Section 6.2 - In the section about policy, the definition for none:

>       none:  {R5} The Domain Owner requests no specific action be taken
>          regarding delivery of messages.

should have ... due to DMARC ... added to it to appropriately scope the 
request.

In the report format section:

Having two types that not all senders/receivers will implement seems 
suboptimal.

I've previously expressed my reservations about Section 7, policy enforcement 
considerations.  I've been asked for inputs offlist, so I anticipate changes in 
the next revision, but even when there is some discussion outside the secret 
design group writing these drafts, it is very difficult to consider it actual 
participation.  I think that will be a problem until this is the list where 
actual work on DMARC happens.

Secton 11.2 describes SPF checks being done after DKIM verification.  This is, 
in my experience, and odd order to describe them in and it's equally odd to 
describe both DKIM and SPF verification being done after a DMARC record is 
retrieved.  In reality, the order doesn't matter.  You need an SPF result, a 
DKIM result, and a DMARC record to determine the DMARC result.  The current 
language implies sequence requirements that don't exist.

I think mentioning best guess SPF is out of place too.  That's no where defined 
in any IEFT document, so there's no way to describe the thing you're telling 
people not to do.  I think general advice is enough.

At the end of 12.2:

>    ... The Mail Receiver MAY cache that
>    data and try again later, or MAY discard data that could not be sent.

I don't thing the 2119 words are needed here.  I don't think there's a third 
option here, so you're telling the receiver they can do whatever they want.  
You don't need 2119 language to tell them that.

Section 15.4 describes SPF as a "backup" to DKIM.  That's not consistent with 
the rest of the draft.  Similar to 15.4, there are also senders that aren't 
very careful about what the put DKIM signatures on, so there's a similar, but 
missing security consideration for DKIM.

Section 15.8 needs a complete rewrite.  Start with SMTP rejections don't cause 
backscatter and go from there.

A.6.1.  Public Suffix Lists mentions one publicly maintained list and license 
states that license terms can be found at the relevant URL.  They aren't 
there.

The XML schema definition is confusing to me to read (I'm not an XML expert by 
any means, so it may just be me).  It does not seem to consistently match up 
with what I see being used in the wild.  I see forwarded used quite often for 
mailing lists and I don't recall ever having seen mailing list as a policy 
override reason.

I think there's substantial work to be done here once we look at the spec 
versus what's going out on the wire.

Appdendix D should be updated to refer to this list.

I kept waiting for a justification for why TLS was recommended, but I got to 
the end and didn't find it.

I'm on vacation this week and work's been busy up to being on vacation, so 
I've only had limited time to review this.  Consider these comments after a 
light read.  I'm sure if I had more time, the review could have been longer.  

Scott K