Subject: [dmarc-ietf] Suggestion: clarification of what is a SPF-pass in the DMARC realm

From: "J. Gomez" <[email-masked]>
Date: Wed, 10 Apr 2013 22:50:09 +0200

Hello all.

It is 'somewhat' clear that in the realm of DMARC-processing only a 'positive' SPF match constitutes a pass for the SPF-mechanism. I.e., that a SPF match for 'neutral' does NOT constitute a pass for the SPF-mechanism in the realm of DMARC-processing. However, this is not clearly stated, beyond reasonable doubt and discussion, in the DMARC draft specification.

Possible result of a SPF check, according to RFC 4408, are:
 --Pass
 --Fail
 --SoftFail
 --Neutral
 --None
 --TempError
 --PermError

So I think that it should be clearly stated, in Section 4.1, where the SPF mechanims is specified, that only a 'positive' match in the SPF-mechanism constitutes a pass in the realm of DMARC-processing; or even better, stating that a 'neutral' match in the SPF-mechanism does NOT constitute a pass-result for the SPF-mechanism in the realm of DMARC-processing.

https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1

Regards,

J. Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Apr 2013 14:20:45 -0700

Section 4.1 only identifies the underlying mechanisms and references their
defining documents.  It doesn't dive into their interpretation at all.
Meanwhile, Section 5 says:

   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.

This doesn't strike me as ambiguous versus the list of possible SPF
outcomes, or DKIM's for that matter.

On Wed, Apr 10, 2013 at 1:50 PM, J. Gomez <[email-masked]> wrote:

> Hello all.
>
> It is 'somewhat' clear that in the realm of DMARC-processing only a
> 'positive' SPF match constitutes a pass for the SPF-mechanism. I.e., that a
> SPF match for 'neutral' does NOT constitute a pass for the SPF-mechanism in
> the realm of DMARC-processing. However, this is not clearly stated, beyond
> reasonable doubt and discussion, in the DMARC draft specification.
>
> So I think that it should be clearly stated, in Section 4.1, where the SPF
> mechanims is specified, that only a 'positive' match in the SPF-mechanism
> constitutes a pass in the realm of DMARC-processing; or even better,
> stating that a 'neutral' match in the SPF-mechanism does NOT constitute a
> pass-result for the SPF-mechanism in the realm of DMARC-processing.
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: "J. Gomez" <[email-masked]>
Date: Wed, 10 Apr 2013 23:44:57 +0200

It does remain dubious whether an alignment with a 'neutral' match if SPF is a DMARC-pass or not for the SPF-mechanism in the realm of DMARC-processing.

Consider this SPF DNS RR for "example.com":

"v=spf1 ip4:195.234.236.237 ?ip4:195.234.236.238 ~all"

And here comes an email from a sending MTA at IP 195.234.236.238 carrying a RFC5321.MailFrom of [email-masked] and a RFC5322.From header of [email-masked].

The "From:" header identifier in that email is explicitedly aligned with a 'neutral' match in SPF. So there is a match, and there is an alignment. But not an alignment 'good enough' for DMARC, or 'qualified enough' for DMARC. Therefore this nuance should be clearly stated in the DMARC specification, to avoid rivers of ink flowing in the future.

Regards,

J. Gomez

---- Original Message ----
From: Murray S. Kucherawy
To: J. Gómez
Cc: [email-masked]
Sent: Wednesday, April 10, 2013 11:20 PM
Subject: Re: [dmarc-ietf] Suggestion: clarification of what is a
SPF-pass in the DMARC realm 

> Section 4.1 only identifies the underlying mechanisms and references
> their defining documents.  It doesn't dive into their interpretation
> at all.  Meanwhile, Section 5 says:  
> 
> 
> 'positive' SPF match constitutes a pass for the SPF-mechanism. I.e.,
> that a SPF match for 'neutral' does NOT constitute a pass for the
> SPF-mechanism in the realm of DMARC-processing. However, this is not
> clearly stated, beyond reasonable doubt and discussion, in the DMARC
> draft specification.     
> 
> So I think that it should be clearly stated, in Section 4.1, where
> the SPF mechanims is specified, that only a 'positive' match in the
> SPF-mechanism constitutes a pass in the realm of DMARC-processing; or
> even better, stating that a 'neutral' match in the SPF-mechanism does
> NOT constitute a pass-result for the SPF-mechanism in the realm of
> DMARC-processing.     
>

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 10 Apr 2013 18:01:53 -0400

So we need to specify that pass means pass?

Scott K

On Wednesday, April 10, 2013 11:44:57 PM J. Gomez wrote:
> It does remain dubious whether an alignment with a 'neutral' match if SPF is
> a DMARC-pass or not for the SPF-mechanism in the realm of DMARC-processing.
> 
> And here comes an email from a sending MTA at IP 195.234.236.238 carrying a
> RFC5321.MailFrom of [email-masked] and a RFC5322.From header of
> [email-masked].
> 
> The "From:" header identifier in that email is explicitedly aligned with a
> 'neutral' match in SPF. So there is a match, and there is an alignment. But
> not an alignment 'good enough' for DMARC, or 'qualified enough' for DMARC.
> Therefore this nuance should be clearly stated in the DMARC specification,
> to avoid rivers of ink flowing in the future.
> 
> Regards,
> 
> J. Gomez
> 
>

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 10 Apr 2013 15:23:05 -0700

In light of the perception (by some) that SPF is negatively oriented (fail
can be relied upon to be meaningful, while all other results are less
actionable), I think so. It is a case of what one does with the "excluded
middle" for a tri-state response mapped into a binary decision. Does
"neutral" map to a positive interpretation (yes for SPF by itself, no for
DMARC) or a negative one (DMARC's "not pass").

--Kurt

---

From: "J. Gomez" <[email-masked]>
Date: Thu, 11 Apr 2013 00:24:36 +0200

Specifying that neutral does not mean pass would be better.

J. Gomez

On Thursday, April 11, 2013 12:01 AM [GMT+1=CET], Scott Kitterman wrote:

> > It does remain dubious whether an alignment with a 'neutral' match
> > if SPF is a DMARC-pass or not for the SPF-mechanism in the realm of
> > DMARC-processing. 
> > 
> > And here comes an email from a sending MTA at IP 195.234.236.238
> > carrying a RFC5321.MailFrom of [email-masked] and a
> > RFC5322.From header of [email-masked].
> > 
> > The "From:" header identifier in that email is explicitedly aligned
> > with a 'neutral' match in SPF. So there is a match, and there is an
> > alignment. But not an alignment 'good enough' for DMARC, or
> > 'qualified enough' for DMARC. Therefore this nuance should be
> > clearly stated in the DMARC specification, to avoid rivers of ink
> > flowing in the future. 
> > 
> > Regards,
> > 
> > J. Gomez
> > 
> > 
> > > Section 4.1 only identifies the underlying mechanisms and
> > > references their defining documents.  It doesn't dive into their
> > > interpretation 
> > > 
> > >    A Mail Receiver MUST consider an arriving message to pass the
> > >    DMARC test if and only if one or more of the underlying message
> > > This doesn't strike me as ambiguous versus the list of possible
> > > SPF outcomes, or DKIM's for that matter.
> > > 
> > > 
> > > 
> > > It is 'somewhat' clear that in the realm of DMARC-processing only
> > > a 'positive' SPF match constitutes a pass for the SPF-mechanism.
> > > I.e., that a SPF match for 'neutral' does NOT constitute a pass
> > > for the SPF-mechanism in the realm of DMARC-processing. However,
> > > this is not clearly stated, beyond reasonable doubt and
> > > discussion, in the DMARC draft specification.
> > > 
> > > the SPF mechanims is specified, that only a 'positive' match in
> > > the SPF-mechanism constitutes a pass in the realm of
> > > DMARC-processing; or even better, stating that a 'neutral' match
> > > in the SPF-mechanism does NOT constitute a pass-result for the
> > > SPF-mechanism in the realm of DMARC-processing.
> > >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 10 Apr 2013 18:11:17 -0700

Are there any existing implementations of SPF that would return a "pass"
result for the example you gave?

I don't think the rule of the excluded middle applies here.  The logic is
"pass" vs "does not pass" (which covers the universe of possibilities), not
"pass" vs "fail" (which does not).

If the consensus really is that this is ambiguous, then I suggest referring
to the specific sections of the DKIM and SPF RFCs where "pass" (or
equivalent) is defined.  But I don't agree that the current draft text is
ambiguous.  Anyone else?

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 10 Apr 2013 21:22:31 -0400

If the definition of neutral in 4408 or 4408bis isn't clear enough, I don't think the DMARC spec is going to close the comprehension gap.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 11 Apr 2013 04:09:46 -0000

>actionable), I think so.

The SPF spec is plenty clear on this point.  SPF pass is well defined,
it means what the spec says is means.  I don't think it is a good idea
for the DMARC spec to argue with people who inisist on misreading it.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Thu, 11 Apr 2013 23:55:28 +0200

> for the DMARC spec to argue with people who inisist on misreading it.

+1. Although pages like http://www.openspf.org/SPF_Record_Syntax may 
give the impression that SPF is a 'policy enforcement vehicle', from a 
standards point of view we have to deal with the bare RFC4408 and 
4408bis specs and as such DMARC can simply refer to these specifications 
without having to explain things for a 2nd time.

Having said that, I wonder whether people deploying DMARC with a 
p=reject for transactional mail will realize how important it is to get 
(and keep) their SPF and DKIM records present and available/reachable in 
DNS. This might be something for the BCP document of Dave?

Furthermore, the fact that DNS problems may have the effect of getting 
mail rejected, introduces an attack vector, which may need to be 
described in the 'security' section.

/rolf

---

From: Franck Martin <[email-masked]>
Date: Thu, 11 Apr 2013 22:25:07 +0000

On Apr 11, 2013, at 2:55 PM, Rolf E. Sonneveld <[email-masked]> wrote:

> +1. Although pages like http://www.openspf.org/SPF_Record_Syntax may give the impression that SPF is a 'policy enforcement vehicle', from a standards point of view we have to deal with the bare RFC4408 and 4408bis specs and as such DMARC can simply refer to these specifications without having to explain things for a 2nd time.
> 
> Having said that, I wonder whether people deploying DMARC with a p=reject for transactional mail will realize how important it is to get (and keep) their SPF and DKIM records present and available/reachable in DNS. This might be something for the BCP document of Dave?
> 
> Furthermore, the fact that DNS problems may have the effect of getting mail rejected, introduces an attack vector, which may need to be described in the 'security' section.
> 

This tool is useful as for example: http://www.dmarcian.com/spf-survey/godaddy.com

My experience is that a SPF DNS error, will tempfail the email, till DNS works but not with DKIM. Am I right to assume this is the common behavior?

May be a word on possibilities here in the BCP could help.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 11 Apr 2013 16:54:07 -0700

It depends on the kind of error and on the implementation.  Generally, a
temporary DNS error should result in a temp-fail of the message, while a
permanent DNS error should not.

"Record not found" is not a temporary error.

I'd say both of those points are true for both protocols.

On Thu, Apr 11, 2013 at 3:25 PM, Franck Martin <[email-masked]> wrote:

> standards point of view we have to deal with the bare RFC4408 and 4408bis
> specs and as such DMARC can simply refer to these specifications without
> having to explain things for a 2nd time.
> >
> mail rejected, introduces an attack vector, which may need to be described
> in the 'security' section.
> >
>
> This tool is useful as for example:
> http://www.dmarcian.com/spf-survey/godaddy.com
>
> My experience is that a SPF DNS error, will tempfail the email, till DNS
> works but not with DKIM. Am I right to assume this is the common behavior?
>

---

From: "John R Levine" <[email-masked]>
Date: 11 Apr 2013 23:18:13 -0400

>> works but not with DKIM. Am I right to assume this is the common behavior?

Since nobody uses ADSP, until DMARC came along there wasn't any reason to 
reject on DKIM failure.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Apr 2013 06:40:10 -0700

On 4/11/2013 8:18 PM, John R Levine wrote:
> Since nobody uses ADSP, until DMARC came along there wasn't any reason
> to reject on DKIM failure.

I think it worth making a significantly stronger statement:

      Until receivers had a basis for getting distinctive claims from 
senders, it was essential that receivers /not/ reject based on a DKIM 
failure.

Absent that information, the receiver could not distinguish between 
transit failures that killed the signature, from other errors.

Of course, they still can't, but the claim from the sender is presumed 
to be based on the sender's knowledge that transit breakage is extremely 
unlikely.

d/

-- 
  Dave Crocker
  bbiw.net

---

From: Franck Martin <[email-masked]>
Date: Fri, 12 Apr 2013 15:22:14 +0000

On Apr 12, 2013, at 6:40 AM, Dave Crocker <[email-masked]> wrote:

>     Until receivers had a basis for getting distinctive claims from senders, it was essential that receivers /not/ reject based on a DKIM failure.
> 
> Absent that information, the receiver could not distinguish between transit failures that killed the signature, from other errors.
> 
> Of course, they still can't, but the claim from the sender is presumed to be based on the sender's knowledge that transit breakage is extremely unlikely.
> 
I mean in DKIM there is one DNS operation, which is to fetch the key. If the DNS does not answer (not that the DNS answers there is no key), I think systems would not tempfail the email and just carry on? What happens if there is more than one DKIM signature, and one has DNS failing?

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Apr 2013 09:17:54 -0700

On 4/12/2013 8:22 AM, Franck Martin wrote:
> I mean in DKIM there is one DNS operation, which is to fetch the key.
> If the DNS does not answer (not that the DNS answers there is no
> key), I think systems would not tempfail the email and just carry on?

If they believd that DNS queries were perfectly reliable, perhaps.

But they aren't, so they shouldn't.

d/
-- 
  Dave Crocker
  bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Apr 2013 09:36:47 -0700

On Fri, Apr 12, 2013 at 8:22 AM, Franck Martin <[email-masked]> wrote:

> I mean in DKIM there is one DNS operation, which is to fetch the key. If
> the DNS does not answer (not that the DNS answers there is no key), I think
> systems would not tempfail the email and just carry on? What happens if
> there is more than one DKIM signature, and one has DNS failing?
>
>
I don't believe either SPF or DKIM specifies a single action to be taken
when the DNS query results in a temporary error of some kind.  It would be
perfectly legitimate to temp-fail the message until the DNS query works,
and it would be perfectly legitimate to allow it to pass without completing
verification.  It's a local policy matter.

As one data point, OpenDKIM offers the operator the ability to choose the
action taken in this situation, defaulting to temp-failing for transient
DNS errors and passing with an error noted for permanent DNS errors (e.g.,
key not found).

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Fri, 12 Apr 2013 20:56:44 +0200

On 04/12/2013 01:54 AM, Murray S. Kucherawy wrote:
> It depends on the kind of error and on the implementation.  Generally, 
> a temporary DNS error should result in a temp-fail of the message, 
> while a permanent DNS error should not.

SPF leaves this open. Quoting 4408bis:

    A "temperror" result means the SPF verifier encountered a transient
    (generally DNS) error while performing the check.  Checking software
    can choose to accept or temporarily reject the message.

> I'd say both of those points are true for both protocols.

Unless I'm missing something obvious, an SPF temporary DNS error reduces 
the DMARC mechanism check to a DKIM-only check, correct? At least: this 
is how I read the DMARC spec:

    4.  Perform SPF validation checks.  The results of this step are
        passed to the remainder of the algorithm and MUST include the
        domain name used to complete the SPF check if evaluation returned
        a "pass" result.

and

    5.  Conduct identifier alignment checks.  With authentication checks
        and policy discovery performed, the Mail Receiver checks if
        Authenticated Identifiers fall into alignment as decribed in
        Section 4  <http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-4>.  If one or more of the Authenticated Identifiers align
        with theRFC5322  <http://tools.ietf.org/html/rfc5322>.From domain, the message is considered to pass
        the DMARC mechanism check.  All other conditions (authentication
        failures, identifier mismatches) are considered to be DMARC
        mechanism check failures.

means: we have two things to check for: SPF and DKIM. If SPF evaluation 
does not provide a 'pass' (i.e. when the outcome is one of "None", 
"Neutral", "Fail", "SoftFail", "TempError" or "PermError") we're left 
with only DKIM.

As SPF allows for the include: mechanism, it is possible that now and 
then DKIM and DMARC records can be retrieved from DNS, while SPF records 
(temporarily) can't. Suppose I'm using MessageLabs and I have an 
include:spf.messagelabs.com in my SPF record, while my DNS provides my 
DMARC p=reject record to any DNS client asking for it and meanwhile the 
DNS servers of MessageLabs are under a DDoS, this may impact delivery of 
my mail (in the 5? percent of all cases where DKIM validation fails [1]).

Or am I misinterpreting DMARC?

/rolf

[1] http://www.ietf.org/iesg/implementation/report-rfc4871.txt

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Apr 2013 15:11:04 -0400

"Rolf E. Sonneveld" <[email-masked]> wrote:

>Section 4 
><http://tools.ietf.org/html/draft-kucherawy-dmarc-base-00#section-4>. 
>If one or more of the Authenticated Identifiers align
It depends on which of the two options that RFC 4408 gives you've chosen to use.   If you defer the message based on SPF temperror, then DMARC doesn't even come up.

Scott K

---

From: "John R Levine" <[email-masked]>
Date: 12 Apr 2013 16:03:36 -0400

> verification.  It's a local policy matter.

Right.  Until DMARC came along, there was no particular reason to do the 
DKIM verification during the SMTP session.  My system has always done it 
as part of the spamassassin step that happens when the message is about to 
be delivered.  At that point, if there's any sort of DNS failure, the DKIM 
verification just fails and the delivery goes ahead without it.

I'm doing it in the SMTP session now for DMARC and adding an A-R header, 
but I still don't see much point in tempfailing the mail on DKIM failure. 
It's fairly hard to think of a plausible scenario in which the DKIM check 
would tempfail, but the DMARC would succeed, since they're generally 
handled by the same DNS server.

Regards,

---

From: "J. Gomez" <[email-masked]>
Date: Fri, 12 Apr 2013 22:14:43 +0200

On Friday, April 12, 2013 9:11 PM [GMT+1=CET], Scott Kitterman wrote:

> >    A "temperror" result means the SPF verifier encountered a
> >   transient (generally DNS) error while performing the check. 
> >    Checking software can choose to accept or temporarily reject the
> > message. 
> > 
> > 
> > > 
> >      domain name used to complete the SPF check if evaluation
> >        returned a "pass" result.
> > 
> > and
> > 
> >   5.  Conduct identifier alignment checks.  With authentication
> >        checks and policy discovery performed, the Mail Receiver
> >        checks if Authenticated Identifiers fall into alignment as
> > decribed in 
> > Section 4
> >       the DMARC mechanism check.  All other conditions
> >        (authentication failures, identifier mismatches) are
> >        considered to be DMARC mechanism check failures.
> > 
> > 
> > "Neutral", "Fail", "SoftFail", "TempError" or "PermError") we're
> > left with only DKIM.
> > 
> > As SPF allows for the include: mechanism, it is possible that now
> > and then DKIM and DMARC records can be retrieved from DNS, while SPF
> > records
> > include:spf.messagelabs.com in my SPF record, while my DNS provides
> > my DMARC p=reject record to any DNS client asking for it and
> > meanwhile the 
> > 
> It depends on which of the two options that RFC 4408 gives you've
> chosen to use.   If you defer the message based on SPF temperror,
> then DMARC doesn't even come up.

Allow me to quote Requirement #7 for DMARC: "Message disposition requests via DMARC override those requested by any other public mechanism." Which amounts to your reply does not apply, and Rolf's question is still pertinent.

Regards,

J. Gomez

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 12 Apr 2013 13:23:00 -0700

There's nothing the protocol can do, or specify, to make sure this
happens.  The operator has to make sure of it.

On Fri, Apr 12, 2013 at 1:14 PM, J. Gomez <[email-masked]> wrote:

> Allow me to quote Requirement #7 for DMARC: "Message disposition requests
> via DMARC override those requested by any other public mechanism." Which
> amounts to your reply does not apply, and Rolf's question is still
> pertinent.
>

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Apr 2013 16:30:35 -0400

"J. Gomez" <[email-masked]> wrote:

>Allow me to quote Requirement #7 for DMARC: "Message disposition
>requests via DMARC override those requested by any other public
>mechanism." Which amounts to your reply does not apply, and Rolf's
>question is still pertinent.
>

SPF temperror is a protocol result, not a message disposition request.  It's a matter of local policy.

Scott K

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 13 Apr 2013 00:05:10 +0200

On Friday, April 12, 2013 10:30 PM [GMT+1=CET], Scott Kitterman wrote:

> > > >    Checking software can choose to accept or temporarily reject
> > > > the message.
> > > > 
> > > > 
> > > > > 
> > > >    4.  Perform SPF validation checks.  The results of this step
> > > >        are passed to the remainder of the algorithm and MUST
> > > > include 
> > the
> > > >        checks if Authenticated Identifiers fall into alignment
> > > > as decribed in
> > > > Section 4
> > > > 
> > > > with theRFC5322  <http://tools.ietf.org/html/rfc5322>.From
> > > > domain, the message is considered to pass
> > > > does not provide a 'pass' (i.e. when the outcome is one of
> > > > "None", "Neutral", "Fail", "SoftFail", "TempError" or
> > > > "PermError") we're left with only DKIM.
> > > > 
> > > > As SPF allows for the include: mechanism, it is possible that
> > > > now and then DKIM and DMARC records can be retrieved from DNS,
> > > > while 
> > SPF
> > > > records
> > > > include:spf.messagelabs.com in my SPF record, while my DNS
> > > > provides my DMARC p=reject record to any DNS client asking for
> > > > it and meanwhile the
> > > > 

No. DMARC requires to pass the results of the SPF-check to the "remainder of the [DMARC] algorithm". If you take any action (whatever action) directly on the results of the SPF-check which is different from the action of passing said results to "the remainder of [DMARC] the algorithm", then you are not DMARC-compliant. Period. So whatever the SPF-result is, you must go straight after it to check "identifier alignment checks", and if in that step the identifier is DKIM-aligned then you have a DMARC pass (and not a SPF-temperror on which you can act, unless you are not checking DMARC at all). [See Section 11.2.4 and 11.2.5]

Regards,

J. Gomez

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 12 Apr 2013 18:13:50 -0400

On Saturday, April 13, 2013 12:05:10 AM J. Gomez wrote:
> > > On Friday, April 12, 2013 9:11 PM [GMT+1=CET], Scott Kitterman
> > > 
> > > wrote:
> > > > > > It depends on the kind of error and on the implementation.
> > > > > 
> > > > > Generally,
> > > > > 
> > > > > > a temporary DNS error should result in a temp-fail of the
> > > 
> > > message,
> > > 
> No. DMARC requires to pass the results of the SPF-check to the "remainder of
> the [DMARC] algorithm". If you take any action (whatever action) directly
> on the results of the SPF-check which is different from the action of
> passing said results to "the remainder of [DMARC] the algorithm", then you
> are not DMARC-compliant. Period. So whatever the SPF-result is, you must go
> straight after it to check "identifier alignment checks", and if in that
> step the identifier is DKIM-aligned then you have a DMARC pass (and not a
> SPF-temperror on which you can act, unless you are not checking DMARC at
> all). [See Section 11.2.4 and 11.2.5]
> 

I think in the spirit of that requirement, it's quite reasonable to wait for a 
final disposition (wait for the temperror to resolve itself) before acting on 
that requirement.

Also, before DMARC was submitted to the IETF, it was discussed and I had 
thought agreed that if the DMARC policy for a domain was none then that should 
mean DMARC policy should have no effect, not that DMARC and all other email 
authentication related policies should have no effect.

I'm also not at all convinced that the requirement in the current draft is 
necessary or appropriate.  If senders don't wan't receivers to reject mail 
based on SPF, all they have to do is not publish -all SPF records.  There's no 
need to reach down from the DMARC layer to the SPF layer to override what it 
does.

Scott K

---

From: "J. Gomez" <[email-masked]>
Date: Sat, 13 Apr 2013 11:38:27 +0200

On Saturday, April 13, 2013 12:13 AM [GMT+1=CET], Scott Kitterman wrote:
> > > > > It depends on which of the two options that RFC 4408 gives
> > > > > you've chosen to use.   If you defer the message based on SPF
> > > > > temperror, then DMARC doesn't even come up.
> > > > 
> > > > mechanism." Which amounts to your reply does not apply, and
> > > > Rolf's question is still pertinent.
> > > > 
> > No. DMARC requires to pass the results of the SPF-check to the
> > "remainder of the [DMARC] algorithm". If you take any action
> > (whatever action) directly on the results of the SPF-check which is
> > different from the action of passing said results to "the remainder
> > of [DMARC] the algorithm", then you are not DMARC-compliant.
> > Period. So whatever the SPF-result is, you must go straight after
> > it to check "identifier alignment checks", and if in that step the
> > identifier is DKIM-aligned then you have a DMARC pass (and not a
> > SPF-temperror on which you can act, unless you are not checking
> > DMARC at all). [See Section 11.2.4 and 11.2.5] 
> > 
> I think in the spirit of that requirement, it's quite reasonable to
> wait for a final disposition (wait for the temperror to resolve
> itself) before acting on that requirement.

Yes, you can wait for the SPF-temperror to resolve itself, but then you are not checking SPF in the realm of DMARC, i.e. you are not checking for DMARC proper (because that is not what the DMARC algorithm dictates) but checking SPF-by-itself and applying local policies to the results of those checks of SPF-by-itself.

> Also, before DMARC was submitted to the IETF, it was discussed and I
> had thought agreed that if the DMARC policy for a domain was none
> then that should mean DMARC policy should have no effect, not that
> DMARC and all other email authentication related policies should have
> no effect. 

In DMARC "p=none" is not 'undeclared policy' but 'apply no policy', which is not the same. So if the DMARC check fails and there is a policy of "p=none" then I think you should not override the DMARC request to 'apply no policy' with any other public mechanism's requested policy, as per Requirement #7 for DMARC.

And if the DMARC check passes but you also got a SPF-temperror when checking SPF in the realm of DMARC, I don't think you can defer the message as per the DMARC-algorithm itself (but you could defer it as per local policies outside of the scope of DMARC processing, to be applied only after DMARC processing has ended or before DMARC processing has begun). This case is problematic because DMARC only states policy for DMARC-fail cases, not for DMARC-pass cases. DMARC allows you to post-process the message with other mechanisms after the message exists the DMARC algorithm [*], and I guess you can in that stage defer it until the SPF-temperror solves itself, but you should not make such a message deferral inside the DMARC algorithm processing (ie., inside of the DMARC plugin/milter).

[*] DMARC allows to post-process a message with other mechanisms after the message exists the DMARC processing, but does not allow to apply policies --if any-- stated by any other PUBLIC mechanism. Therefore, you can post-process a message with other PUBLIC mechanisms after DMARC processing, but you cannot apply any discovered policy from those other PUBLIC mechanisms, you can only apply local policies based on the results from those other PUBLIC mechanisms. I.e, you cannot reject a message based on SPF "-all" after DMARC processing or while DMARC processing, because that is a policy in a PUBLIC mechanism other than DMARC, but you could defer based on SPF-temperror after and only after DMARC processing has ended, because that would be a local policy in the scope of DMARC post-processing.

Regards, 

J. Gomez

---

From: Tim Draegen <[email-masked]>
Date: Sun, 14 Apr 2013 21:36:28 -0400

> final disposition (wait for the temperror to resolve itself) before acting on 

As an implementor, I'd treat temporary errors as exceptions to normal processing, and either reply with "Try again later" or, if a message has already been accepted, queue until some timeout occurs.  If anything times out (SPF, DKIM, or DMARC-related), I'd flag these failures in related XML/Forensic feedback as TempErrors for the domain owner to track down (with "can't retrieve DMARC record" being a possible security hole if the resulting behavior is "fail open").

IMO, Rolf suggested that mentioning this in a BCP document would be nice to connect the dots for people that are deploying on top of DNS.  +1 to that idea.

Finally, Rolf put up the question about "SPF produces temp-err, which means DMARC-verdict then becomes solely based on DKIM result, right?".  From my narrow perspective as a DMARC receiver, I'm searching for a reliable way to assert "NOT PASS" so I can enforce policy without incurring support burden.  If DKIM produces a passing DMARC-verdict, then the value of resolving an SPF temperr goes way down.  FWIW.

> authentication related policies should have no effect.

The context then was "if I publish a DMARC record with p=none, will I be causing a change in receiver behave?".  Specifically, this was around having an SPF "-all" policy in place causing rejections that might be modified if a DMARC record was found.

FTR, consensus was to allow people to publish "p=none" to collect feedback without impacting existing email behavior.

> need to reach down from the DMARC layer to the SPF layer to override what it 

How about: I want receivers that are not doing DMARC to continue to reject email based on my "-all" policy, but I want receivers that *are* doing DMARC to use DMARC's policy mechanism instead?  Maintain existing functionality but take advantage of newness if its available.  Clunkily worded, eh!

=- Tim

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 14 Apr 2013 22:00:30 -0400

On Sunday, April 14, 2013 09:36:28 PM Tim Draegen wrote:
> > I think in the spirit of that requirement, it's quite reasonable to wait
> > for a final disposition (wait for the temperror to resolve itself) before
> > acting on that requirement.
> 
> As an implementor, I'd treat temporary errors as exceptions to normal
> processing, and either reply with "Try again later" or, if a message has
> already been accepted, queue until some timeout occurs.  If anything times
> out (SPF, DKIM, or DMARC-related), I'd flag these failures in related
> XML/Forensic feedback as TempErrors for the domain owner to track down
> (with "can't retrieve DMARC record" being a possible security hole if the
> resulting behavior is "fail open").
> 
> IMO, Rolf suggested that mentioning this in a BCP document would be nice to
> connect the dots for people that are deploying on top of DNS.  +1 to that
> idea.
> 
> Finally, Rolf put up the question about "SPF produces temp-err, which means
> DMARC-verdict then becomes solely based on DKIM result, right?".  From my
> narrow perspective as a DMARC receiver, I'm searching for a reliable way to
> assert "NOT PASS" so I can enforce policy without incurring support burden.
>  If DKIM produces a passing DMARC-verdict, then the value of resolving an
> SPF temperr goes way down.  FWIW.
> > thought agreed that if the DMARC policy for a domain was none then that
> > should mean DMARC policy should have no effect, not that DMARC and all
> > other email authentication related policies should have no effect.
> 
> The context then was "if I publish a DMARC record with p=none, will I be
> causing a change in receiver behave?".  Specifically, this was around
> having an SPF "-all" policy in place causing rejections that might be
> modified if a DMARC record was found.
> 
> FTR, consensus was to allow people to publish "p=none" to collect feedback
> without impacting existing email behavior.
> > based on SPF, all they have to do is not publish -all SPF records. 
> > There's no need to reach down from the DMARC layer to the SPF layer to
> > override what it does.
> 
> How about: I want receivers that are not doing DMARC to continue to reject
> email based on my "-all" policy, but I want receivers that *are* doing
> DMARC to use DMARC's policy mechanism instead?  Maintain existing
> functionality but take advantage of newness if its available.  Clunkily
> worded, eh!

I'm not certain what the best answer is, but I think that at least getting the 
spec to say you can publish p=none and not affect existing behavior is very 
important.  Unfortunately, there's no venue to discuss updating the base spec.

Scott K