Subject: [dmarc-ietf] Another minor contradiction in the draft specification

From: "J. Gomez" <[email-masked]>
Date: Thu, 18 Apr 2013 23:49:35 +0200

Hello all.

The DMARC Requirement #7 in Section 3.4 reads:

  Message disposition requests via DMARC override those requested
  by any other public mechanism.

The old draft in its pre-IETF track ( http://dmarc.org/draft-dmarc-base-00-02.txt ) said in the fourth paragraph in Section 7:

  DMARC-compliant Mail Receivers MUST disregard any mail directive
  discovered as part of an authentication mechanism (e.g., ADSP, SPF)
  where a DMARC policy is also discovered. {R7}

However, now the current DMARC draft ( https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1 ) says in that same spot:

   DMARC-compliant Mail Receivers SHOULD disregard any mail directive
   discovered as part of an authentication mechanism (e.g., ADSP, SPF)
   where a DMARC policy is also discovered that specifies a policy other
   than "none". {R7}

It can be argued that both MUST and SHOULD fall into {R7}, but it is dubious that excepting the policy of "p=none" from being subjected to either that MUST or SHOULD makes it also fall into {R7}. The new text effectively excepts "p=none" from Requirement #7, but Requirement #7 does not seem to allow for that.

Regards,

J. Gomez

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 18 Apr 2013 18:34:31 -0400

On Thursday, April 18, 2013 11:49:35 PM J. Gomez wrote:
> The old draft in its pre-IETF track (
> http://dmarc.org/draft-dmarc-base-00-02.txt ) said in the fourth paragraph
> in Section 7:
> 
> However, now the current DMARC draft (
> https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1
> ) says in that same spot:
> 
> It can be argued that both MUST and SHOULD fall into {R7}, but it is dubious
> that excepting the policy of "p=none" from being subjected to either that
> MUST or SHOULD makes it also fall into {R7}. The new text effectively
> excepts "p=none" from Requirement #7, but Requirement #7 does not seem to
> allow for that.

If there's no DMARC policy (none), there's nothing to override.  The change is 
a welcome improvement in the spec.  Under the old version it wasn't possible 
to publish DMARC records for testing without affecting existing processing.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 18 Apr 2013 21:36:34 -0700

> to publish DMARC records for testing without affecting existing processing.

+1.

Moreover, as was pointed out on another thread, we did decide along the way
that some of our requirements were not exactly what we needed in the end.
Maybe this is another one we should update or simply remove.

-MSK