Subject: Re: [dmarc-ietf] Jim Fenton's review of -04

From: "John Levine" <[email-masked]>
Date: 1 Jan 2015 16:17:48 -0000

In article <CAL0qLwaiQh=eg-QxD9hXe00uK+xxrWaKgfW1Rb8=[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>OK, seriously, I hope I don't have to crack this open again.  Conflict
>review is slated for the 1/8 telechat, and a flurry of last minute edits
>might not sit well with the IESG.  We need to leave actual work, as much as
>at all possible, to the WG, and not to hacking on the ISE version.
>
>Diffs to -09 which will be in -10 within the next few days:
>http://blackops.org/~msk/dmarc/diff.html

The current diff shows the entire file deleted and replaced with an
empty one.  While I would enthusiastically endorse this change, I
suspect it's not the one you had in mind.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jan 2015 09:28:30 -0800

> suspect it's not the one you had in mind.

I was going for brevity.

Actually, xml2rfc was complaining that it's now 2015 and the XML source was
trying to force a date in 2014.  Fixed now.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 01 Jan 2015 15:50:36 -0500

On December 31, 2014 11:43:06 PM EST, "Murray S. Kucherawy" <[email-masked]> wrote:
>On Mon, Dec 29, 2014 at 11:38 AM, Scott Kitterman
><[email-masked]>
>wrote:
>
>> On December 29, 2014 2:32:27 PM EST, Dave Crocker <[email-masked]>
>> wrote:
>> >On 12/29/2014 10:40 AM, Scott Kitterman wrote:
>> >TO:
>> >>> >
>> >DMARC evaluation can only complete and yield a "pass" result when
>one
>> >of the underlying authentication mechanisms passes for an aligned
>> >identifier.  If neither passes and one or both of them failed due to
>> >>> >a
>> >temporary error, the Receiver evaluating the message is also unable
>> >>> >to
>> >conclude that the DMARC mechanism had a permanent failure and
>thereby
>> >can apply the advertised DMARC policy.
>> >>> >
>> >>> >This looks good to me.
>> >> Shouldn't it be cannot apply the advertised DMARC policy?
>> >
>> >Actually, no, but I also was confused.  It took me some serious
>effort
>> >to decide that the current wording was correct.  And a spec should
>not
>> >require that sort of linguistic diligence, IMO.
>> >
>> >Looks like a small change can make your form correct...
>> >
>> >So I suggest:
>> >
>> >     DMARC evaluation can only yield a "pass" result after one
>> >of the underlying authentication mechanisms passes for an aligned
>> >identifier. If neither passes and one or both of them fails due to a
>> >temporary error, the Receiver evaluating the message is unable to
>> >conclude that the DMARC mechanism had a permanent failure; they
>> >therefore cannot (yet) apply the advertised DMARC policy.
>> >
>> >d/
>>
>> I think that's better. I'd prefer to leave out the parenthetical yet
>as I
>> think it raises ambiguity rather than reduces it.
>>
>> Scott K
>>
>> _______________________________________________
>> dmarc mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>dmarc mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dmarc

Personally I prefer what you had for -09.  I think it's clearer, but I'm ok with either. 

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Sun, 04 Jan 2015 12:38:51 -0800

On 12/24/14 10:08 PM, Scott Kitterman wrote:
> On Thursday, December 25, 2014 00:02:41 Murray S. Kucherawy wrote:
>> On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman <[email-masked]>
>>
>> wrote:
>>>    Messages for which SPF and/or DKIM evaluation encounters a temporary
>>>    DNS error have not received a definitive result for steps 3 and/or 4
>>>
>>> above.
>>>
>>>    If the message has not passed the the DMARC mechanism check due to
>>>    an SPF or DKIM check that did not have a DNS error, receivers can
>>>    either
>>>    ignore DMARC for this message due to incomplete evaluation or they
>>>    can defer the message in the hope that the temporary error will be
>>>    resolved when the message is retried.  Receivers MUST NOT apply DMARC
>>>    policy and reject or quarantine the message because the DMARC
>>>    evaluation is incomplete. When otherwise appropriate due to DMARC
>>>    policy, receivers MAY send feedback reports regarding temporary errors.
>>>    
>>>    Handling of messages for which SPF and/or DKIM evaluation encounters
>>>    a permanent DNS error is left to the discretion of the Mail Receiver.
>>>
>>> How's that?
>> I think it pretty much says what's there, but is a lot more clear about
>> it.  I also think the second sentence is a bit convoluted, so I reworked it
>> into this.  Does it match what you're trying to say?
>>
>>                 <t> Messages for which SPF and/or DKIM evaluation encounters
>> a temporary DNS error have not received a definitive result for steps 3
>> and/or 4 above.  When such an evaluation
>>                     is done in conjunction with an aligned identifier,
>>                     completion of the DMARC algorithm is not possible.
>>                     In this case, receivers can either skip DMARC for this
>>                     message due to incomplete evaluation, or they can
>> arrange
>>                     to defer handling of the message in the hope that the
>>                     temporary error will be resolved when the message is
>>                     retried.  In any case, Receivers cannot apply DMARC
>>                     policy and reject or quarantine the message because the
>>                     DMARC evaluation is incomplete.  When otherwise
>>                     appropriate due to DMARC policy, receivers MAY send
>>                     feedback reports regarding temporary errors. </t>
>>
>> -MSK
> I don't think it does.  What I was trying to say is that if you already got an 
> aligned pass from one method, you're done.  It doesn't matter if they other 
> one gets a DNS error, you already have a definitive result.  I don't think your 
> text says that, but I may be wrong.

It's a bit more complicated than that, unfortunately. While an aligned
pass from one method does yield an overall DMARC "pass", depending on
the setting of the "fo" flag, you might still need to send a failure
report for the other method. If fo=1, should a report be sent for the
temporary failure, or should the message be held to see if the failure
clears?

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 04 Jan 2015 15:49:21 -0500

On Sunday, January 04, 2015 12:38:51 Jim Fenton wrote:
> > I don't think it does.  What I was trying to say is that if you already
> > got an aligned pass from one method, you're done.  It doesn't matter if
> > they other one gets a DNS error, you already have a definitive result.  I
> > don't think your text says that, but I may be wrong.
> 

I think we covered that down thread from here.

Scott K