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

[Scott Kitterman]

On Sunday, January 04, 2015 12:38:51 Jim Fenton wrote:
> 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 
> >> 
> >> 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?
> >> 
> >>  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. 
> >> 
> >> -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?

I think we covered that down thread from here.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Jim Fenton]

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 
>>
>> 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?
>>
>>  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. 
>>
>> -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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On December 31, 2014 11:43:06 PM EST, "Murray S. Kucherawy" 
 wrote:
>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
>
>-MSK
>
>
>On Mon, Dec 29, 2014 at 11:38 AM, Scott Kitterman
>
>wrote:
>
>> On December 29, 2014 2:32:27 PM EST, Dave Crocker 
>> 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
>> dmarc@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmarc
>>
>
>
>
>
>___
>dmarc mailing list
>dmarc@ietf.org
>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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Thu, Jan 1, 2015 at 8:17 AM, John Levine  wrote:

> >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.
>

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
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

In article  
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

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

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

-MSK


On Mon, Dec 29, 2014 at 11:38 AM, Scott Kitterman 
wrote:

> On December 29, 2014 2:32:27 PM EST, Dave Crocker 
> 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
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Franck Martin]

> On Dec 30, 2014, at 5:39 AM, MH Michael Hammer (5304)  wrote:
> 
> 
> 
>> -Original Message-
>> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
>> Sent: Monday, December 29, 2014 4:58 PM
>> To: dmarc@ietf.org
>> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
>> 
>> On 12/29/2014 12:32 PM, MH Michael Hammer (5304) wrote:
>>> I suppose it's ultimately another example of local policy.
>> 
>> Depends on what that means.
>> 
>> The rule within the protocol needs to be -- and is -- mechanical and
>> universal: In order to apply DMARC policy, you must first obtain an
>> authenticated (or, described more usefully, 'authorized') domain name that
>> is aligned with the From: field domain.
>> 
>> A protocol that treats an initial, temporary error as producing a permanent
>> error is a pretty fragile protocol, in a networking environment.  As such,
>> DMARC should at least strongly recommend retries, in the case of no passes
>> and at least one temp fail.
>> 
> 
> The choices offered were tempfail and allow retry or don't apply DMARC 
> policy. I was expressing a preference for tempfail which ultimately would 
> degrade to a permfail after whatever number of retries the sending system has 
> set. 
> 
+1

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 12/30/2014 6:38 AM, MH Michael Hammer (5304) wrote:
> he first question is whether this is a matter of local policy. If the
> answer is yes (Which I believe and invoke King Canute), then anything
> written IS a recommendation (even if it is only documenting what "We"
> - for some definition of "we" - believe is existing common practice.


Documenting common practice is fine for a document seeking to be a BCP.

For a document specifying a protocol, it is best to be simpler and more
definitive.

 Define the boundaries of the protocol.  Try to put everything in
terms of MUST or MUST NOT.  Allows SHOULD [NOT] when it is understood
that some exceptions by knowledgeable actors can reasonably be
tolerated.  Include MAY (MAY NOT isn't really meaningful IMO) to permit
benign flexibility that the community consider plausibly useful.

But discussion of what an actor might do outside of the boundaries of
the protocol really are outside of the protocol.

Especially in the context of DMARC, most references to "local policy"
have tended to serve to blur the demarcation between what is inside the
protocol and what is outside.

What is really meant, when we say "local policy" for DMARC is:

 Outside of the DMARC spec, you can do what you want.

 This is, of course, a tautology, but we keep talking as if it isn't.

DMARC has a pretty simple model.

 If you are a domain owner participating in DMARC, you publish an
associated record and state your desires.  If you are a receiver
participating in DMARC, you attend to that record, after performing some
tests on the message.

 The tests are also pretty simple, at the level of DMARC.  We have
discussed them at length.  Since they involve some sequencing, we've had
some fun getting the exact language right, but none of that has been a
debate about the actual algorithm; it's strictly wordsmithing.

 So DMARC's conditions for asserting the requests by a domain owner
are crisp and simple.

What is inherently fuzzy is how to handle a temporary failure.  Unlike a
transport-level timeout, the handling of temporary failures at the
application level often are a matter taste.

(Note that some of the original Arpanet specs including guidance such as
"wait for something to change".  So guidance can indeed be fuzzy.)

It might help to distinguish between the detection of a temporary
failure versus what to do in the event of a temp failure.

 The occurrence of a temporary failure is objective and needs to be
specified within the protocol.  We need to state what qualifies as a
temp fail and then simply label it as such.

 For the /handling/ of a temp fail, we need to decide whether a
DMARC participant is obligated to try again versus obligated /not/ to
try again.  The nature of 'conformance' we might specify can be nicely
distinguished by choosing one of MUST, SHOULD or MAY, possibly with some
justification text.

After that, any discussion of possible receiver actions moves into the
realm of BCP operational preferences.  As long as the text is clear that
this all really is outside the protocol and rather moves into local
preferences for how to use DMARC within the local system, that's fine.

Instead of saying 'local policies' or 'local overrides', we ought to
help ourr clarity by saying something like "ad hoc, non-DMARC policies"
or the like.

That is, 'local policy' means 'independent of the DMARC specification.'


d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[MH Michael Hammer (5304)]

> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Steven M Jones
> Sent: Monday, December 29, 2014 5:00 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> 
> On 12/29/2014 12:32 PM, MH Michael Hammer (5304) wrote:
> >
> >> -Original Message-
> >> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott
> >> Kitterman [...] I think the only two reasonable choices are defer and
> >> see what happens on retry or to treat it as DMARC none and press on
> >> with other checks.
> >>
> > I suppose it's ultimately another example of local policy.  I feel like a
> DMARC "none" opens the door to abuse (I'm thinking of abused financials for
> example). How easily can an abuser induce temporary failures for DNS for a
> given host/domain? I'd prefer a recommendation of "defer and retry" rather
> than a fail open (DMARC none).
> 
> Is this a point where the phrase "documenting existing common practice"
> should guide us? That sounded a lot like recommending a practice versus
> documenting...
> 

The first question is whether this is a matter of local policy. If the answer 
is yes (Which I believe and invoke King Canute), then anything written IS a 
recommendation (even if it is only documenting what "We" - for some definition 
of "we" - believe is existing common practice. Personally I don't believe it IS 
existing common practice if we look at the number of validators implementing 
(vs percentage of mail it is applied to). We know, or should know, that many 
implementers on the validation side are struggling with implementing local 
policy for things like white listing. I have not seen any data to indicate that 
tempfail on temporary DNS failures is truly an existing common practice.

So we are back to "What do we believe validators should do when encountering 
temporary failures?" For an implementation such as DMARC I prefer tempfail 
which is fail closed rather than DMARC none which is fail open. Based on 
visibility into our own mail streams and DMARC reporting, this particular case 
represents (for our domains) a very low number on an absolute basis /percentage 
of mail that I view it as generally a corner case of an edge case. Others may 
have different data.

Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[MH Michael Hammer (5304)]

> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
> Sent: Monday, December 29, 2014 4:58 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> 
> On 12/29/2014 12:32 PM, MH Michael Hammer (5304) wrote:
> > I suppose it's ultimately another example of local policy.
> 
> Depends on what that means.
> 
> The rule within the protocol needs to be -- and is -- mechanical and
> universal: In order to apply DMARC policy, you must first obtain an
> authenticated (or, described more usefully, 'authorized') domain name that
> is aligned with the From: field domain.
> 
> A protocol that treats an initial, temporary error as producing a permanent
> error is a pretty fragile protocol, in a networking environment.  As such,
> DMARC should at least strongly recommend retries, in the case of no passes
> and at least one temp fail.
> 

The choices offered were tempfail and allow retry or don't apply DMARC policy. 
I was expressing a preference for tempfail which ultimately would degrade to a 
permfail after whatever number of retries the sending system has set. 

Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Steven M Jones]

On 12/29/2014 12:32 PM, MH Michael Hammer (5304) wrote:
>
>> -Original Message-
>> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott Kitterman
>> [...]
>> I think the only two reasonable choices are defer and see what happens on
>> retry or to treat it as DMARC none and press on with other checks.
>>
> I suppose it's ultimately another example of local policy.  I feel like a 
> DMARC "none" opens the door to abuse (I'm thinking of abused financials for 
> example). How easily can an abuser induce temporary failures for DNS for a 
> given host/domain? I'd prefer a recommendation of "defer and retry" rather 
> than a fail open (DMARC none).

Is this a point where the phrase "documenting existing common practice"
should guide us? That sounded a lot like recommending a practice versus
documenting...

--S.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 12/29/2014 12:32 PM, MH Michael Hammer (5304) wrote:
> I suppose it's ultimately another example of local policy. 

Depends on what that means.

The rule within the protocol needs to be -- and is -- mechanical and
universal: In order to apply DMARC policy, you must first obtain an
authenticated (or, described more usefully, 'authorized') domain name
that is aligned with the From: field domain.

A protocol that treats an initial, temporary error as producing a
permanent error is a pretty fragile protocol, in a networking
environment.  As such, DMARC should at least strongly recommend retries,
in the case of no passes and at least one temp fail.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[MH Michael Hammer (5304)]

> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott Kitterman
> Sent: Monday, December 29, 2014 3:22 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> 
> On December 29, 2014 3:15:26 PM EST, "MH Michael Hammer (5304)"
>  wrote:
> >Still not quite correct...
> >
> >> -Original Message-
> >> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
> >> Sent: Monday, December 29, 2014 2:32 PM
> >> To: Scott Kitterman; dmarc@ietf.org
> >> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> >>
> >> 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/
> >> --
> >
> >If neither of them passes and only one of them fails due to a temporary
> >error (but the other one does not fail due to a temporary error) then
> >the other one should (must?, not in the normative sense) be an actual
> >failure. Perhaps the wording should be: "If neither SPF nor DKIM pass
> >and both of them fail due to temporary errors...". The case we seem to
> >be discussing is where we have temporary failures for both SPF and
> >DKIM.
> 
> No.  As long as either of them have a temporary DNS error, then you can't
> apply DMARC policy.
> 

DOH! I stand corrected.

> >The other issue (more than a quibble) I have is leaving it at "; they
> >therefore cannot (yet) apply the advertised DMARC policy." What should
> >they do? I prefer the treat it as a tempfail and allow for retries. The
> >problem with that approach is if the mail has been accepted for
> >delivery. I don't like the idea of DSNs or out of band bounces.
> 
> I think the only two reasonable choices are defer and see what happens on
> retry or to treat it as DMARC none and press on with other checks.
> 

I suppose it's ultimately another example of local policy.  I feel like a DMARC 
"none" opens the door to abuse (I'm thinking of abused financials for example). 
How easily can an abuser induce temporary failures for DNS for a given 
host/domain? I'd prefer a recommendation of "defer and retry" rather than a 
fail open (DMARC none).

Mike 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On December 29, 2014 3:15:26 PM EST, "MH Michael Hammer (5304)" 
 wrote:
>Still not quite correct...
>
>> -Original Message-
>> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
>> Sent: Monday, December 29, 2014 2:32 PM
>> To: Scott Kitterman; dmarc@ietf.org
>> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
>> 
>> 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/
>> --
>
>If neither of them passes and only one of them fails due to a temporary
>error (but the other one does not fail due to a temporary error) then
>the other one should (must?, not in the normative sense) be an actual
>failure. Perhaps the wording should be: "If neither SPF nor DKIM pass
>and both of them fail due to temporary errors...". The case we seem to
>be discussing is where we have temporary failures for both SPF and
>DKIM.

No.  As long as either of them have a temporary DNS error, then you can't apply 
DMARC policy. 

>The other issue (more than a quibble) I have is leaving it at "; they
>therefore cannot (yet) apply the advertised DMARC policy." What should
>they do? I prefer the treat it as a tempfail and allow for retries. The
>problem with that approach is if the mail has been accepted for
>delivery. I don't like the idea of DSNs or out of band bounces.

I think the only two reasonable choices are defer and see what happens on retry 
or to treat it as DMARC none and press on with other checks. 

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[MH Michael Hammer (5304)]

Still not quite correct...

> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Dave Crocker
> Sent: Monday, December 29, 2014 2:32 PM
> To: Scott Kitterman; dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> 
> 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/
> --

If neither of them passes and only one of them fails due to a temporary error 
(but the other one does not fail due to a temporary error) then the other one 
should (must?, not in the normative sense) be an actual failure. Perhaps the 
wording should be: "If neither SPF nor DKIM pass and both of them fail due to 
temporary errors...". The case we seem to be discussing is where we have 
temporary failures for both SPF and DKIM.

The other issue (more than a quibble) I have is leaving it at "; they therefore 
cannot (yet) apply the advertised DMARC policy." What should they do? I prefer 
the treat it as a tempfail and allow for retries. The problem with that 
approach is if the mail has been accepted for delivery. I don't like the idea 
of DSNs or out of band bounces.

Mike

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On December 29, 2014 2:32:27 PM EST, Dave Crocker  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
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

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/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On December 29, 2014 11:50:51 AM EST, ned+dm...@mrochek.com wrote:
>> On 12/29/2014 7:26 AM, MH Michael Hammer (5304) wrote:
>> > It's still not quite right:
>> >
>> > DMARC evaluation can only complete and yield a "pass" result when
>one
>> >
>> >
>> > of the underlying authentication mechanisms passes for an aligned
>> >
>> > identifier.  If this is not the case and either or both of them
>> >
>> > suffered some kind of temporary error (such as a transient DNS
>> >
>> > problem), the Receiver evaluating the message is also unable to
>> >
>> > conclude that the DMARC mechanism failed and thereby apply the
>> >
>> > advertised DMARC policy.  Rather, the Receiver can either skip
>DMARC
>> >
>> >
>> > processing for this message due to incomplete evaluation, or it can
>> >
>> >
>> > arrange to defer handling of the message in the hope that the
>> >
>> > temporary error will be resolved when the message is retried.  When
>> >
>> >
>> > otherwise appropriate due to DMARC policy, receivers MAY send
>> >
>> > feedback reports regarding temporary errors.
>> >
>> >
>> > The problem is with:
>> >
>> > "If this is not the case and either or both of them suffered some
>> > kind of temporary error (such as a transient DNS problem),...",
>> > Specifically the use of "either or". If only one (SPF or DKIM) has
>a
>> > transient DNS error then presumably the other, which has not had an
>> > error, can be evaluated (resulting in a "pass" or "DMARC failure".
>It
>> > only becomes an issue when BOTH SPF and DKIM have concurrent
>> > temporary errors.  I'm thinking that removing the "either or" is
>> > appropriate. I'm still cogitating on the rest of the paragraph.
>
>
>> Good catch.  This is complicated by there really being two
>conditions.
>
>> The first is the negative that neither method authenticates.  The
>second
>> is the affirmative that one of them failed with a temporary error.
>
>> So perhaps something like:
>
>> FROM:
>
>> > DMARC evaluation can only complete and yield a "pass" result when
>one
>> > of the underlying authentication mechanisms passes for an aligned
>> > identifier.  If this is not the case and either or both of them
>> > suffered some kind of temporary error (such as a transient DNS
>> > problem), the Receiver evaluating the message is also unable to
>> > conclude that the DMARC mechanism failed and thereby apply the
>> > advertised DMARC policy.
>
>
>> 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? 

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[ned+dmarc]

> On 12/29/2014 7:26 AM, MH Michael Hammer (5304) wrote:
> > It's still not quite right:
> >
> > DMARC evaluation can only complete and yield a "pass" result when one
> >
> >
> > of the underlying authentication mechanisms passes for an aligned
> >
> > identifier.  If this is not the case and either or both of them
> >
> > suffered some kind of temporary error (such as a transient DNS
> >
> > problem), the Receiver evaluating the message is also unable to
> >
> > conclude that the DMARC mechanism failed and thereby apply the
> >
> > advertised DMARC policy.  Rather, the Receiver can either skip DMARC
> >
> >
> > processing for this message due to incomplete evaluation, or it can
> >
> >
> > arrange to defer handling of the message in the hope that the
> >
> > temporary error will be resolved when the message is retried.  When
> >
> >
> > otherwise appropriate due to DMARC policy, receivers MAY send
> >
> > feedback reports regarding temporary errors.
> >
> >
> > The problem is with:
> >
> > "If this is not the case and either or both of them suffered some
> > kind of temporary error (such as a transient DNS problem),...",
> > Specifically the use of "either or". If only one (SPF or DKIM) has a
> > transient DNS error then presumably the other, which has not had an
> > error, can be evaluated (resulting in a "pass" or "DMARC failure". It
> > only becomes an issue when BOTH SPF and DKIM have concurrent
> > temporary errors.  I'm thinking that removing the "either or" is
> > appropriate. I'm still cogitating on the rest of the paragraph.


> Good catch.  This is complicated by there really being two conditions.

> The first is the negative that neither method authenticates.  The second
> is the affirmative that one of them failed with a temporary error.

> So perhaps something like:

> FROM:

> > DMARC evaluation can only complete and yield a "pass" result when one
> > of the underlying authentication mechanisms passes for an aligned
> > identifier.  If this is not the case and either or both of them
> > suffered some kind of temporary error (such as a transient DNS
> > problem), the Receiver evaluating the message is also unable to
> > conclude that the DMARC mechanism failed and thereby apply the
> > advertised DMARC policy.


> 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.

Ned

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 12/29/2014 7:26 AM, MH Michael Hammer (5304) wrote:
> It's still not quite right:
> 
> DMARC evaluation can only complete and yield a "pass" result when one
> 
> 
> of the underlying authentication mechanisms passes for an aligned
> 
> identifier.  If this is not the case and either or both of them
> 
> suffered some kind of temporary error (such as a transient DNS
> 
> problem), the Receiver evaluating the message is also unable to
> 
> conclude that the DMARC mechanism failed and thereby apply the
> 
> advertised DMARC policy.  Rather, the Receiver can either skip DMARC
> 
> 
> processing for this message due to incomplete evaluation, or it can
> 
> 
> arrange to defer handling of the message in the hope that the
> 
> temporary error will be resolved when the message is retried.  When
> 
> 
> otherwise appropriate due to DMARC policy, receivers MAY send
> 
> feedback reports regarding temporary errors.
> 
> 
> The problem is with:
> 
> "If this is not the case and either or both of them suffered some
> kind of temporary error (such as a transient DNS problem),...", 
> Specifically the use of "either or". If only one (SPF or DKIM) has a
> transient DNS error then presumably the other, which has not had an
> error, can be evaluated (resulting in a "pass" or "DMARC failure". It
> only becomes an issue when BOTH SPF and DKIM have concurrent
> temporary errors.  I'm thinking that removing the "either or" is
> appropriate. I'm still cogitating on the rest of the paragraph.


Good catch.  This is complicated by there really being two conditions.

The first is the negative that neither method authenticates.  The second
is the affirmative that one of them failed with a temporary error.

So perhaps something like:

FROM:

> DMARC evaluation can only complete and yield a "pass" result when one
> of the underlying authentication mechanisms passes for an aligned
> identifier.  If this is not the case and either or both of them
> suffered some kind of temporary error (such as a transient DNS
> problem), the Receiver evaluating the message is also unable to
> conclude that the DMARC mechanism failed and thereby apply the
> advertised DMARC policy.


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.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[MH Michael Hammer (5304)]

It's still not quite right:

DMARC evaluation can only complete and yield a "pass" result when one  

   of the underlying authentication mechanisms passes for an aligned  

   identifier.  If this is not the case and either or both of them  

   suffered some kind of temporary error (such as a transient DNS  

   problem), the Receiver evaluating the message is also unable to  

   conclude that the DMARC mechanism failed and thereby apply the  

   advertised DMARC policy.  Rather, the Receiver can either skip DMARC  

   processing for this message due to incomplete evaluation, or it can  

   arrange to defer handling of the message in the hope that the  

   temporary error will be resolved when the message is retried.  When  

   otherwise appropriate due to DMARC policy, receivers MAY send  

   feedback reports regarding temporary errors.  


The problem is with:

"If this is not the case and either or both of them suffered some kind of 
temporary error (such as a transient DNS problem),...",
Specifically the use of "either or". If only one (SPF or DKIM) has a transient 
DNS error then presumably the other, which has not had an error, can be 
evaluated (resulting in a "pass" or "DMARC failure". It only becomes an issue 
when BOTH SPF and DKIM have concurrent temporary errors.  I'm thinking that 
removing the "either or" is appropriate. I'm still cogitating on the rest of 
the paragraph.

Mike


> -Original Message-
> From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Scott Kitterman
> Sent: Thursday, December 25, 2014 11:55 PM
> To: dmarc@ietf.org
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> 
> On December 25, 2014 8:43:29 PM CST, "Murray S. Kucherawy"
>  wrote:
> >On Thu, Dec 25, 2014 at 1:08 AM, Scott Kitterman 
> >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 it's close.  I see the distinction you're making, and I've
> >adjusted.  Have a look at the diff now:
> >http://www.blackops.org/~msk/dmarc/diff.html
> 
> I believe that covers it.
> 
> >Also, I don't like the change from MUST NOT to cannot.  Receivers can
> >do
> >> whatever they want, so cannot isn't correct.  This bit is meant to
> >say that
> >> receivers aren't free to use DMARC as an excuse to throw away
> >messages
> >> every
> >> time there's a DNS hiccup.  Applying policy in an inappropriate way
> >does
> >> have
> >> an interoperability impact (messages quarantined/rejected that should
> >not
> >> be),
> >> so I think the MUST NOT is appropriate.
> >>
> >
> >I think "cannot" does do that, actually.  We're saying here that DMARC
> >can't complete for the case you describe, namely where both SPF and
> >DKIM suffered some kind of transient error.  In that case, if you're
> >rejecting, you aren't legitimately doing it in the name of DMARC.
> >
> >I'm deliberately avoiding using new RFC2119 language here because it's
> >way too late to be adding major normative goo.  These are supposed to
> >be corrections to existing text, not addressing oversights in the
> >protocol itself.  If we got this wrong in the base spec, then it's
> >potential material for a standards track revision.  Otherwise, if we
> >start down the path of fixing things, we're never going to be done with
> >this version.
> >
> >(Pete and Barry would also point out here that it's possible for
> >normative language to exist without using RFC2119's key words...)
> 
> OK. I think this solves the problem I was worried about.
> 
> Thanks,
> 
> Scott K
> 
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Franck Martin]

> On Dec 25, 2014, at 8:30 PM, Murray S. Kucherawy  wrote:
> 
> On Thu, Dec 25, 2014 at 10:15 PM, Dave Crocker  > wrote:
> One could argue either way about the multi-valued From:, but at least it
> has an essential relationship to DMARC, since DMARC evaluates From:.  If
> DMARC were required to handle multi-valued From:, it would alter DMARC
> noticeable, as was evident in the debate about this issue.
> 
> The MX requirement has no such linkage.
> 
> I'm afraid the glue is still too thick.  Fortunately at this point, this is 
> all academic.
> 
> I'm staring at this and not understanding how the two are all that different. 
>  They both seek to ensure that a DMARC evaluation can be done on the From: 
> domain, and thus both seek to ensure that the From: that lands in the inbox 
> can be trusted by end users to be valid.
> 
> In both cases, as you put it, DMARC evaluates From:.  The only difference I 
> can see is that one is a self-contained syntactical check while the other 
> requires consulting another data source (the DNS, in this case) for a simple 
> validity test.
> 
> If the MX/A/ test fails, then there's no policy to apply.  We [used to] 
> reject on the basis that it's impossible for that message to legitimately 
> exist.
> 
> If the single-value From: test fails, then which domain's policy is to be 
> applied is potentially indeterminate.  We [still, typically] reject on the 
> basis that it's impossible to be sure which domain the end user will see, and 
> thus decide which policy should apply.  DMARC participants don't like that 
> case and (we claim) protected mail streams never use that syntax anyway, so 
> we disallow its use for those cases.
> 
> To me they have approximately identical goals.  If the MX test can 
> legitimately be dismissed because it aspires to world peace, why shouldn't 
> the other?
> 
> Anyway, I'm content at this point to leave this for the standards track 
> discussion when the WG gets around to it.  I'll remain quietly confused until 
> then.
> 

Checking the domain in From is emailable is a security issue, if you don’t do 
it, then you let miscreant be able to use examples.com  
instead of example.com  and easily get away with it. So it 
is not normative, but it is just here to point out, that DMARC does not solve 
the lower layer vulnerabilities… they have to be taken cared of for DMARC to be 
any remotely useful.

This is a common critic to DMARC, to say DMARC is easily workaround by 
miscreants, so why bother?

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Jim Fenton]

On 12/23/2014 10:25 PM, Murray S. Kucherawy wrote:
> >> 11.1 Discovery
>
> > 6.2.1 in -08
> >
> >> Mail Receivers can also discover reporting requests from the
> >> Organizational Domain. That should be mentioned here. But I'm a
> little
> >> confused why we have another Discovery section at all.
> > The text's use of the word 'corresponds' handles the mapping to org
> > domain, IMO.
>
> This is more of a comment about document organization. The previous
> sections have been talking about things that follow discovery of the
> policy record, and now when talking about aggregate reports there's
> another section about discovery. Why here; isn't this a little
> redundant?
>
>
> It's mainly to say that there isn't a specific discovery process for
> aggregate report details; it's already done.  This might be a legacy
> from ancient versions where there was a separate process.  I'll tidy
> it up by merging it into the previous subsection.
>  
>
> SHOULD isn't strong enough for the Report Receiver to depend on. There
> are other ways to get the information that is encoded into the
> filename.
>
>
> Like what?

In Appendix C, the section "Report generator metadata" seems to have
most if not all of that information. And that's where it belongs: in the
body of the report, not as metadata that may be conveyed by some
transports and not others. Currently the only transport that is defined
is email, but others may be added later.

For email, some of the metadata currently shows up in three places: (1)
encoded in the filename, (2) encoded in the subject, and (3) in the
metadata section of the report. It would help interoperability to define
one of those that the recipient should depend on, and I nominate the
metadata section of the report, so that other transports can be added
more easily if needed.

>  
>
> If the spec wants to suggest, "here's a nice file name format that you
> MAY want to use", that's fine. But SHOULD is both too weak if the
> recipient can't depend on it and too strong if it's merely advice.
>
>
> I'm not so sure.  If we're going to go with MAY, then we also need
> some kind of signal that the filename used does conform to the
> proposed encoding, or else there might be some attempt to extract
> report parameters that simply aren't there.

I'm suggesting that they shouldn't attempt to do so.New issue: Paragraph
3 refers to "Both report types" but since iodef was
>
> removed, it should just say "The AFRF report type".
>
>
> That refers to the aggregate and detailed reports ("rua" and "ruf"),
> not IODEF and AFRF.

Ah, thanks.

-Jim

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On December 25, 2014 8:43:29 PM CST, "Murray S. Kucherawy" 
 wrote:
>On Thu, Dec 25, 2014 at 1:08 AM, Scott Kitterman 
>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 it's close.  I see the distinction you're making, and I've
>adjusted.  Have a look at the diff now:
>http://www.blackops.org/~msk/dmarc/diff.html

I believe that covers it.

>Also, I don't like the change from MUST NOT to cannot.  Receivers can
>do
>> whatever they want, so cannot isn't correct.  This bit is meant to
>say that
>> receivers aren't free to use DMARC as an excuse to throw away
>messages
>> every
>> time there's a DNS hiccup.  Applying policy in an inappropriate way
>does
>> have
>> an interoperability impact (messages quarantined/rejected that should
>not
>> be),
>> so I think the MUST NOT is appropriate.
>>
>
>I think "cannot" does do that, actually.  We're saying here that DMARC
>can't complete for the case you describe, namely where both SPF and
>DKIM
>suffered some kind of transient error.  In that case, if you're
>rejecting,
>you aren't legitimately doing it in the name of DMARC.
>
>I'm deliberately avoiding using new RFC2119 language here because it's
>way
>too late to be adding major normative goo.  These are supposed to be
>corrections to existing text, not addressing oversights in the protocol
>itself.  If we got this wrong in the base spec, then it's potential
>material for a standards track revision.  Otherwise, if we start down
>the
>path of fixing things, we're never going to be done with this version.
>
>(Pete and Barry would also point out here that it's possible for
>normative
>language to exist without using RFC2119's key words...)

OK. I think this solves the problem I was worried about. 

Thanks,

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Thu, Dec 25, 2014 at 10:15 PM, Dave Crocker  wrote:

> One could argue either way about the multi-valued From:, but at least it
> has an essential relationship to DMARC, since DMARC evaluates From:.  If
> DMARC were required to handle multi-valued From:, it would alter DMARC
> noticeable, as was evident in the debate about this issue.
>
> The MX requirement has no such linkage.
>

I'm afraid the glue is still too thick.  Fortunately at this point, this is
all academic.

I'm staring at this and not understanding how the two are all that
different.  They both seek to ensure that a DMARC evaluation can be done on
the From: domain, and thus both seek to ensure that the From: that lands in
the inbox can be trusted by end users to be valid.

In both cases, as you put it, DMARC evaluates From:.  The only difference I
can see is that one is a self-contained syntactical check while the other
requires consulting another data source (the DNS, in this case) for a
simple validity test.

If the MX/A/ test fails, then there's no policy to apply.  We [used to]
reject on the basis that it's impossible for that message to legitimately
exist.

If the single-value From: test fails, then which domain's policy is to be
applied is potentially indeterminate.  We [still, typically] reject on the
basis that it's impossible to be sure which domain the end user will see,
and thus decide which policy should apply.  DMARC participants don't like
that case and (we claim) protected mail streams never use that syntax
anyway, so we disallow its use for those cases.

To me they have approximately identical goals.  If the MX test can
legitimately be dismissed because it aspires to world peace, why shouldn't
the other?

Anyway, I'm content at this point to leave this for the standards track
discussion when the WG gets around to it.  I'll remain quietly confused
until then.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 12/25/2014 6:46 PM, Murray S. Kucherawy wrote:
> Although I've already removed the paragraph under discussion, one more
> point occurred to me:
> 
> There was text in there until recently that required rejection of
> messages with multi-valued From: fields.  People complained about this,
> and so we backed that down to "are typically rejected" (removing RFC2119
> language), and that seems to have satisfied the critics; as I understand
> it, this works under the "profile" argument I made earlier.


I'm pretty sure that the horse is well into the glue stage, but just in
case...

Making modifications to basic, underlying specifications, is a difficult
and potentially dangerous game.

One could argue either way about the multi-valued From:, but at least it
has an essential relationship to DMARC, since DMARC evaluates From:.  If
DMARC were required to handle multi-valued From:, it would alter DMARC
noticeable, as was evident in the debate about this issue.

The MX requirement has no such linkage.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Dec 24, 2014 at 11:23 AM, Dave Crocker  wrote:

> > This paragraph appears in the DMARC spec because the operators
> > participating all agreed that it should be part-and-parcel of this
> > operating profile of email.  It's not as happenstance as this sounds so
> > far; the very thrust of DMARC is to make the From: content believable,
> > and permitting a nonexistent domain name to make it to the inbox
> > contradicts that goal.
>
>
> The goal, as you state it, is at the level of seeking world peace.  It
> is very laudable and and very, very broad.  It covers vastly more than
> the scope of DMARC.
>
> DMARC is a specific bit of technology working towards that broader goal.
>  That something happens to fall within this very broad scope does not
> automatically justify documenting it within the much narrower scope of a
> detailed specification, unless it is part of that specification's
> technology.
>
> The MX record check has no /technical/ relationship to the /technical/
> details of DMARC.
>
> Please note that I'm not commenting on the efficacy of the record check,
> but on the need to document it in a place that makes sense for the full
> range of its implementers.
>
> There are, and will continue to be, plenty of operators using that check
> but not DMARC.  That simple fact provides a very pragmatic reason for
> moving its specification into some document outside of DMARC.
>

Although I've already removed the paragraph under discussion, one more
point occurred to me:

There was text in there until recently that required rejection of messages
with multi-valued From: fields.  People complained about this, and so we
backed that down to "are typically rejected" (removing RFC2119 language),
and that seems to have satisfied the critics; as I understand it, this
works under the "profile" argument I made earlier.

How would this be any different?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Thu, Dec 25, 2014 at 1:08 AM, Scott Kitterman 
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 it's close.  I see the distinction you're making, and I've
adjusted.  Have a look at the diff now:
http://www.blackops.org/~msk/dmarc/diff.html

Also, I don't like the change from MUST NOT to cannot.  Receivers can do
> whatever they want, so cannot isn't correct.  This bit is meant to say that
> receivers aren't free to use DMARC as an excuse to throw away messages
> every
> time there's a DNS hiccup.  Applying policy in an inappropriate way does
> have
> an interoperability impact (messages quarantined/rejected that should not
> be),
> so I think the MUST NOT is appropriate.
>

I think "cannot" does do that, actually.  We're saying here that DMARC
can't complete for the case you describe, namely where both SPF and DKIM
suffered some kind of transient error.  In that case, if you're rejecting,
you aren't legitimately doing it in the name of DMARC.

I'm deliberately avoiding using new RFC2119 language here because it's way
too late to be adding major normative goo.  These are supposed to be
corrections to existing text, not addressing oversights in the protocol
itself.  If we got this wrong in the base spec, then it's potential
material for a standards track revision.  Otherwise, if we start down the
path of fixing things, we're never going to be done with this version.

(Pete and Barry would also point out here that it's possible for normative
language to exist without using RFC2119's key words...)

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On Thursday, December 25, 2014 00:02:41 Murray S. Kucherawy wrote:
> On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman 
> 
> 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?
> 
>  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. 
> 
> -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.

Also, I don't like the change from MUST NOT to cannot.  Receivers can do 
whatever they want, so cannot isn't correct.  This bit is meant to say that 
receivers aren't free to use DMARC as an excuse to throw away messages every 
time there's a DNS hiccup.  Applying policy in an inappropriate way does have 
an interoperability impact (messages quarantined/rejected that should not be), 
so I think the MUST NOT is appropriate.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On Wednesday, December 24, 2014 19:22:21 Franck Martin wrote:
> - Original Message -
> 
> > From: "Scott Kitterman" 
> > To: dmarc@ietf.org
> > Sent: Wednesday, December 24, 2014 2:48:17 PM
> > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> > 
> > On Wednesday, December 24, 2014 10:46:42 Murray S. Kucherawy wrote:
> > > On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman 
> > > 
> > > wrote:
> > > > The draft strongly encourages DMARC implementers to ignore SPF policy,
> > > > so
> > > > I don't think assuming messages will be deferred due only due to SPF
> > > > or
> > > > DKIM results indicating a temporary DNS error is appropriate.
> > > 
> > > If there's a transient DNS error getting the SPF policy, then there's no
> > > SPF policy to be ignored.  That's quite a different situation.
> > > 
> > > > I think that in the case of a temporary DNS error in one of the lower
> > > > level protocols, insufficient inputs are available to conclude a
> > > > message
> > > > has failed DMARC tests.
> > > 
> > > I agree.
> > > 
> > > > 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 because the DMARC
> > > > evaluation
> > > > is
> > > > incomplete.
> > > 
> > > Can you provide specific changes, with section numbers, that you'd like
> > > to
> > > see applied to resolve this?
> > 
> > Here's my suggestion.  Replace this text at the end of section 5.6.2:
> >Handling of messages for which SPF and/or DKIM evaluation encounters
> >a DNS error is left to the discretion of the Mail Receiver.  Further
> >discussion is available in Section 5.6.3.
> > 
> > with:
> >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?
> 
> What about pointing it may be a security issue to let these messages
> through?

It's a security risk to let any messages through.  

What text would you suggest for an addition to security considerations?

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[John Levine]

>What about pointing it may be a security issue to let these messages through?

Only if we also point out that it may be a security issue not to let them 
through.

Seasons xmas,
John

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Dec 24, 2014 at 11:23 AM, Dave Crocker  wrote:

> The goal, as you state it, is at the level of seeking world peace.  It
> is very laudable and and very, very broad.  It covers vastly more than
> the scope of DMARC.
>
> DMARC is a specific bit of technology working towards that broader goal.
>  That something happens to fall within this very broad scope does not
> automatically justify documenting it within the much narrower scope of a
> detailed specification, unless it is part of that specification's
> technology.
>
> The MX record check has no /technical/ relationship to the /technical/
> details of DMARC.
>
> Please note that I'm not commenting on the efficacy of the record check,
> but on the need to document it in a place that makes sense for the full
> range of its implementers.
>
> There are, and will continue to be, plenty of operators using that check
> but not DMARC.  That simple fact provides a very pragmatic reason for
> moving its specification into some document outside of DMARC.
>

I'm surprised we're not hearing more passionate voices in favor of keeping
it given the genesis of the paragraph we're discussing.

At any rate, I'm going to take it out in -09, because I just discovered
that it's actually directly contradicting what Appendix A.4 says.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Dec 24, 2014 at 5:48 PM, Scott Kitterman 
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?

 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. 

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Franck Martin]

- Original Message -
> From: "Scott Kitterman" 
> To: dmarc@ietf.org
> Sent: Wednesday, December 24, 2014 2:48:17 PM
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> 
> On Wednesday, December 24, 2014 10:46:42 Murray S. Kucherawy wrote:
> > On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman 
> > 
> > wrote:
> > > The draft strongly encourages DMARC implementers to ignore SPF policy, so
> > > I don't think assuming messages will be deferred due only due to SPF or
> > > DKIM results indicating a temporary DNS error is appropriate.
> > 
> > If there's a transient DNS error getting the SPF policy, then there's no
> > SPF policy to be ignored.  That's quite a different situation.
> > 
> > > I think that in the case of a temporary DNS error in one of the lower
> > > level protocols, insufficient inputs are available to conclude a message
> > > has failed DMARC tests.
> > 
> > I agree.
> > 
> > > 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 because the DMARC evaluation
> > > is
> > > incomplete.
> > 
> > Can you provide specific changes, with section numbers, that you'd like to
> > see applied to resolve this?
> 
> Here's my suggestion.  Replace this text at the end of section 5.6.2:
> 
>Handling of messages for which SPF and/or DKIM evaluation encounters
>a DNS error is left to the discretion of the Mail Receiver.  Further
>discussion is available in Section 5.6.3.
> 
> with:
> 
>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?
> 
What about pointing it may be a security issue to let these messages through?
 

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On Wednesday, December 24, 2014 10:46:42 Murray S. Kucherawy wrote:
> On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman 
> 
> wrote:
> > The draft strongly encourages DMARC implementers to ignore SPF policy, so
> > I don't think assuming messages will be deferred due only due to SPF or
> > DKIM results indicating a temporary DNS error is appropriate.
> 
> If there's a transient DNS error getting the SPF policy, then there's no
> SPF policy to be ignored.  That's quite a different situation.
> 
> > I think that in the case of a temporary DNS error in one of the lower
> > level protocols, insufficient inputs are available to conclude a message
> > has failed DMARC tests.
> 
> I agree.
> 
> > 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 because the DMARC evaluation
> > is
> > incomplete.
> 
> Can you provide specific changes, with section numbers, that you'd like to
> see applied to resolve this?

Here's my suggestion.  Replace this text at the end of section 5.6.2:

   Handling of messages for which SPF and/or DKIM evaluation encounters
   a DNS error is left to the discretion of the Mail Receiver.  Further
   discussion is available in Section 5.6.3.

with:

   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?

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On December 24, 2014 9:43:40 AM CST, "Murray S. Kucherawy" 
 wrote:
>On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman 
>wrote:
>
>> 5.6.2 promises 5.6.3 addresses the question and it doesn't. At the
>very
>> least, 5.6.2 should be fixed not to over promise what 5.6.3 will
>provide.
>>
>
>I'm not clear why you say "it doesn't".  5.6.3 describes two options
>for
>handling a message when the query for the DMARC policy fails due to
>transient DNS errors.  Is your issue that it doesn't prescribe one
>specific
>action?
>
>I also don't understand why you say the reference is dangling.  5.6.2
>says
>that transient DNS errors for SPF and DKIM can occur and says the
>handling
>for that case is left to receiver discretion, but also points out that
>what
>5.6.3 says can also be applied when that happens.

And 5.6.3 is completely silent on what to do with SPF or DKIM results 
indicating a temporary DNS error. The only references to transient DNS errors 
in 5.6.3 are specific to errors retrieving DMARC records. 

Scott K

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On Wednesday, December 24, 2014 10:46:42 Murray S. Kucherawy wrote:
> On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman 
> 
> wrote:
> > The draft strongly encourages DMARC implementers to ignore SPF policy, so
> > I don't think assuming messages will be deferred due only due to SPF or
> > DKIM results indicating a temporary DNS error is appropriate.
> 
> If there's a transient DNS error getting the SPF policy, then there's no
> SPF policy to be ignored.  That's quite a different situation.
> 
> > I think that in the case of a temporary DNS error in one of the lower
> > level protocols, insufficient inputs are available to conclude a message
> > has failed DMARC tests.
> 
> I agree.
> 
> > 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 because the DMARC evaluation
> > is
> > incomplete.
> 
> Can you provide specific changes, with section numbers, that you'd like to
> see applied to resolve this?

Yes, but I just finished a 20 hour drive, so I'll probably sleep first.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 12/24/2014 7:50 AM, Murray S. Kucherawy wrote:
> This paragraph appears in the DMARC spec because the operators
> participating all agreed that it should be part-and-parcel of this
> operating profile of email.  It's not as happenstance as this sounds so
> far; the very thrust of DMARC is to make the From: content believable,
> and permitting a nonexistent domain name to make it to the inbox
> contradicts that goal.


The goal, as you state it, is at the level of seeking world peace.  It
is very laudable and and very, very broad.  It covers vastly more than
the scope of DMARC.

DMARC is a specific bit of technology working towards that broader goal.
 That something happens to fall within this very broad scope does not
automatically justify documenting it within the much narrower scope of a
detailed specification, unless it is part of that specification's
technology.

The MX record check has no /technical/ relationship to the /technical/
details of DMARC.

Please note that I'm not commenting on the efficacy of the record check,
but on the need to document it in a place that makes sense for the full
range of its implementers.

There are, and will continue to be, plenty of operators using that check
but not DMARC.  That simple fact provides a very pragmatic reason for
moving its specification into some document outside of DMARC.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Franck Martin]

- Original Message -

> From: "Murray S. Kucherawy" 
> To: "Scott Kitterman" 
> Cc: dmarc@ietf.org
> Sent: Wednesday, December 24, 2014 7:46:42 AM
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04

> On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman < skl...@kitterman.com >
> wrote:

> > The draft strongly encourages DMARC implementers to ignore SPF policy, so I
> > don't think assuming messages will be deferred due only due to SPF or DKIM
> > results indicating a temporary DNS error is appropriate.
> 

> If there's a transient DNS error getting the SPF policy, then there's no SPF
> policy to be ignored. That's quite a different situation.

> > I think that in the case of a temporary DNS error in one of the lower level
> > protocols, insufficient inputs are available to conclude a message has
> > failed DMARC tests.
> 

> I agree.

> > 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 because the DMARC evaluation is
> > incomplete.
> 
I would prefer this phrasing 

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. Defer seems preferable for security 
reasons. Receivers MUST NOT apply DMARC policy and reject or quarantine because 
the DMARC evaluation is incomplete. 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Franck Martin]

- Original Message -

> From: "Murray S. Kucherawy" 
> To: "Dave Crocker" 
> Cc: dmarc@ietf.org
> Sent: Wednesday, December 24, 2014 7:50:16 AM
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04

> On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker < d...@dcrocker.net > wrote:

> > > I disagree. DMARC operators all seem to apply this practice, so it's
> 
> > > correct to say that if you play this game, you reject mail from
> 
> > > non-existent domains. Essentially in this way DMARC is a profile of
> 
> > > RFC5321/RFC5322, which is perfectly acceptable. We are not updating
> 
> > > those standards here, merely profiling them.
> 

> > The fact that its use happens to correlate with DMARC use is a
> 
> > distraction. For example, there are plenty of operators who use apply
> 
> > this check but do not use DMARC. If the test is documented in a
> 
> > specification, it should be in /one/ specification. Putting it into the
> 
> > DMARC spec means it has to be documented somewhere else, for the folk
> 
> > who don't use DMARC.
> 

> This paragraph appears in the DMARC spec because the operators participating
> all agreed that it should be part-and-parcel of this operating profile of
> email. It's not as happenstance as this sounds so far; the very thrust of
> DMARC is to make the From: content believable, and permitting a nonexistent
> domain name to make it to the inbox contradicts that goal.

All of this I feel strongly is part of "security considerations", even if they 
may be not in that chapter. What is the use of doing DMARC, if you allow weak 
input and vulnerabilities? 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker  wrote:

> > I disagree.  DMARC operators all seem to apply this practice, so it's
> > correct to say that if you play this game, you reject mail from
> > non-existent domains.  Essentially in this way DMARC is a profile of
> > RFC5321/RFC5322, which is perfectly acceptable.  We are not updating
> > those standards here, merely profiling them.
>
> The fact that its use happens to correlate with DMARC use is a
> distraction.  For example, there are plenty of operators who use apply
> this check but do not use DMARC.  If the test is documented in a
> specification, it should be in /one/ specification.  Putting it into the
> DMARC spec means it has to be documented somewhere else, for the folk
> who don't use DMARC.
>

This paragraph appears in the DMARC spec because the operators
participating all agreed that it should be part-and-parcel of this
operating profile of email.  It's not as happenstance as this sounds so
far; the very thrust of DMARC is to make the From: content believable, and
permitting a nonexistent domain name to make it to the inbox contradicts
that goal.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman 
wrote:

> The draft strongly encourages DMARC implementers to ignore SPF policy, so
> I don't think assuming messages will be deferred due only due to SPF or
> DKIM results indicating a temporary DNS error is appropriate.
>

If there's a transient DNS error getting the SPF policy, then there's no
SPF policy to be ignored.  That's quite a different situation.


> I think that in the case of a temporary DNS error in one of the lower
> level protocols, insufficient inputs are available to conclude a message
> has failed DMARC tests.
>

I agree.


> 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 because the DMARC evaluation is
> incomplete.
>

Can you provide specific changes, with section numbers, that you'd like to
see applied to resolve this?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman 
wrote:

> 5.6.2 promises 5.6.3 addresses the question and it doesn't. At the very
> least, 5.6.2 should be fixed not to over promise what 5.6.3 will provide.
>

I'm not clear why you say "it doesn't".  5.6.3 describes two options for
handling a message when the query for the DMARC policy fails due to
transient DNS errors.  Is your issue that it doesn't prescribe one specific
action?

I also don't understand why you say the reference is dangling.  5.6.2 says
that transient DNS errors for SPF and DKIM can occur and says the handling
for that case is left to receiver discretion, but also points out that what
5.6.3 says can also be applied when that happens.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 12/23/2014 10:11 PM, Murray S. Kucherawy wrote:
> -08 text says:
> 
>  "If the RFC5322.From domain does not exist in the DNS, Mail
>Receivers
>SHOULD direct the receiving SMTP server to reject the message.  The
>choice of mechanism for such rejection and the implications of those
>choices are discussed in Section 9.3."
> 
> I suggest removing it.  Although a common anti-abuse mechanism, it's out
> of scope for DMARC.
> 
> 
> I disagree.  DMARC operators all seem to apply this practice, so it's
> correct to say that if you play this game, you reject mail from
> non-existent domains.  Essentially in this way DMARC is a profile of
> RFC5321/RFC5322, which is perfectly acceptable.  We are not updating
> those standards here, merely profiling them.


The fact that its use happens to correlate with DMARC use is a
distraction.  For example, there are plenty of operators who use apply
this check but do not use DMARC.  If the test is documented in a
specification, it should be in /one/ specification.  Putting it into the
DMARC spec means it has to be documented somewhere else, for the folk
who don't use DMARC.

Broadly, there are all sorts of things that DMARC operators commonly do,
but that are not appropriate to document in the DMARC specification.

DMARC concerns the domain name in the From: field and finding that it
has a DMARC record associated with it.  If there is no record associated
with the domain name, then it is not participating in DMARC.

There are other places to document other, common anti-abuse practices.

The check for an MX is completely out of scope for the DMARC spec.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On December 24, 2014 2:20:30 AM EST, "Murray S. Kucherawy" 
 wrote:
>On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin 
>wrote:
>
>> I think we should recommend something here, not sure if it needs to
>be
>> normative. We do say to ignore the SPF policy when p!=none, though I
>think
>> we can be normative on the lower layers. I see 2 options here:
>> 1)tempfail the message is either SPF and DKIM have a tempfail status
>> 2)tempfail the message if both SPF and DKIM have a tempfail status
>>
>> 1) is my preferred and is aggressive, therefore not sure people will
>like
>> it. I'll settle for 2)
>>
>> As explained in another post, I'm worried I can run a DNS attack (or
>just
>> a self inflicted DNS bad config) and get DMARC to reject emails it
>should
>> have accepted (has the DMARC policy in cache, but cannot assert SPF
>and
>> DKIM).
>>
>>
>I think it's reasonably clear from 5.6.3 that the "fail open" choice is
>possibly dangerous, as is anything that fails open.
>
>But more importantly, I'm also worried about making a normative
>decision
>now about something we deliberately haven't specified up to this point
>for
>whatever reason.  We are supposed to be documenting current practice
>with
>this effort, not establishing something new.
>
>Might this something best left for the standards track WG effort?

5.6.2 promises 5.6.3 addresses the question and it doesn't. At the very least, 
5.6.2 should be fixed not to over promise what 5.6.3 will provide. 

I do think it's better to answer it now.  I'm not sure when or if the WG will 
address missing chunks of protocol definition.  The charter pretty well assumes 
there aren't any. 

Scott K


___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On December 24, 2014 1:32:44 AM EST, "Murray S. Kucherawy" 
 wrote:
>On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman
>
>wrote:
>
>> There was a recent thread on postfix-users about DMARC rejections
>when
>> there
>> are DNS errors that caused me to review -08 to see what it says on
>the
>> matter.
>>
>> At the end of section 5.6.2, it says:
>>
>>Handling of messages for which SPF and/or DKIM evaluation
>encounters
>>a DNS error is left to the discretion of the Mail Receiver. 
>Further
>>discussion is available in Section 5.6.3.
>>
>> My reading of 5.6.3 though is that it only discusses DNS errors in
>the
>> context
>> of failing to retrieve the DMARC record.  Any discussion about
>handling DNS
>> errors for SPF/DKIM seems to be missing.
>>
>
>Yes, DMARC punts on what to do when SPF or DKIM encounter transient
>failures.  I imagine that's because those modules would arrange to
>temp-fail a message that has that problem.  I suppose my experience is
>that
>messages don't even get to the point of DMARC evaluation when that
>happens,
>because the message has already been temp-failed.
>
>If you think about DKIM and SPF as being part of a layer below DMARC,
>then
>I'm not sure it's wise of us to be making any kind of normative
>statement
>about what to do when the lower layers fail.
>
>What do you suggest?
>
>-MSK

The draft strongly encourages DMARC implementers to ignore SPF policy, so I 
don't think assuming messages will be deferred due only due to SPF or DKIM 
results indicating a temporary DNS error is appropriate. 

I think that in the case of a temporary DNS error in one of the lower level 
protocols, insufficient inputs are available to conclude a message has failed 
DMARC tests. 

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 because the DMARC evaluation is incomplete. 

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Dec 24, 2014 at 2:40 AM, Franck Martin 
wrote:

> --
>
> *From: *"Murray S. Kucherawy" 
> *To: *"Franck Martin" 
> *Cc: *dmarc@ietf.org, "Scott Kitterman" 
> *Sent: *Tuesday, December 23, 2014 11:20:30 PM
> *Subject: *Re: [dmarc-ietf] Jim Fenton's review of -04
>
> On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin 
> wrote:
>
>> I think we should recommend something here, not sure if it needs to be
>> normative. We do say to ignore the SPF policy when p!=none, though I think
>> we can be normative on the lower layers. I see 2 options here:
>> 1)tempfail the message is either SPF and DKIM have a tempfail status
>> 2)tempfail the message if both SPF and DKIM have a tempfail status
>>
>> 1) is my preferred and is aggressive, therefore not sure people will like
>> it. I'll settle for 2)
>>
>> As explained in another post, I'm worried I can run a DNS attack (or just
>> a self inflicted DNS bad config) and get DMARC to reject emails it should
>> have accepted (has the DMARC policy in cache, but cannot assert SPF and
>> DKIM).
>>
>>
> I think it's reasonably clear from 5.6.3 that the "fail open" choice is
> possibly dangerous, as is anything that fails open.
>
> But more importantly, I'm also worried about making a normative decision
> now about something we deliberately haven't specified up to this point for
> whatever reason.  We are supposed to be documenting current practice with
> this effort, not establishing something new.
>
> Might this something best left for the standards track WG effort?
>
> Fair enough, but curious about standard practice. For instance what
> openDMARC do? and others?
>
> I think DMARC got us to be "stricter" and less "lenient" with email.
>
>
OpenDMARC gets the message only after OpenDKIM is done with it, so if
OpenDKIM temp-fails, OpenDMARC never even sees it.  Thus, the case we're
concerned about here can't ever happen.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Franck Martin]

- Original Message -

> From: "Murray S. Kucherawy" 
> To: "Franck Martin" 
> Cc: dmarc@ietf.org, "Scott Kitterman" 
> Sent: Tuesday, December 23, 2014 11:20:30 PM
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04

> On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin < fra...@peachymango.org >
> wrote:

> > I think we should recommend something here, not sure if it needs to be
> > normative. We do say to ignore the SPF policy when p!=none, though I think
> > we can be normative on the lower layers. I see 2 options here:
> 
> > 1)tempfail the message is either SPF and DKIM have a tempfail status
> 
> > 2)tempfail the message if both SPF and DKIM have a tempfail status
> 

> > 1) is my preferred and is aggressive, therefore not sure people will like
> > it.
> > I'll settle for 2)
> 

> > As explained in another post, I'm worried I can run a DNS attack (or just a
> > self inflicted DNS bad config) and get DMARC to reject emails it should
> > have
> > accepted (has the DMARC policy in cache, but cannot assert SPF and DKIM).
> 

> I think it's reasonably clear from 5.6.3 that the "fail open" choice is
> possibly dangerous, as is anything that fails open.

> But more importantly, I'm also worried about making a normative decision now
> about something we deliberately haven't specified up to this point for
> whatever reason. We are supposed to be documenting current practice with
> this effort, not establishing something new.

> Might this something best left for the standards track WG effort?

Fair enough, but curious about standard practice. For instance what openDMARC 
do? and others? 

I think DMARC got us to be "stricter" and less "lenient" with email. 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin 
wrote:

> I think we should recommend something here, not sure if it needs to be
> normative. We do say to ignore the SPF policy when p!=none, though I think
> we can be normative on the lower layers. I see 2 options here:
> 1)tempfail the message is either SPF and DKIM have a tempfail status
> 2)tempfail the message if both SPF and DKIM have a tempfail status
>
> 1) is my preferred and is aggressive, therefore not sure people will like
> it. I'll settle for 2)
>
> As explained in another post, I'm worried I can run a DNS attack (or just
> a self inflicted DNS bad config) and get DMARC to reject emails it should
> have accepted (has the DMARC policy in cache, but cannot assert SPF and
> DKIM).
>
>
I think it's reasonably clear from 5.6.3 that the "fail open" choice is
possibly dangerous, as is anything that fails open.

But more importantly, I'm also worried about making a normative decision
now about something we deliberately haven't specified up to this point for
whatever reason.  We are supposed to be documenting current practice with
this effort, not establishing something new.

Might this something best left for the standards track WG effort?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Franck Martin]

- Original Message -

> From: "Murray S. Kucherawy" 
> To: "Scott Kitterman" 
> Cc: dmarc@ietf.org
> Sent: Tuesday, December 23, 2014 10:32:44 PM
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04

> On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman < skl...@kitterman.com >
> wrote:

> > There was a recent thread on postfix-users about DMARC rejections when
> > there
> 
> > are DNS errors that caused me to review -08 to see what it says on the
> > matter.
> 

> > At the end of section 5.6.2, it says:
> 

> > Handling of messages for which SPF and/or DKIM evaluation encounters
> 
> > a DNS error is left to the discretion of the Mail Receiver. Further
> 
> > discussion is available in Section 5.6.3.
> 

> > My reading of 5.6.3 though is that it only discusses DNS errors in the
> > context
> 
> > of failing to retrieve the DMARC record. Any discussion about handling DNS
> 
> > errors for SPF/DKIM seems to be missing.
> 

> Yes, DMARC punts on what to do when SPF or DKIM encounter transient failures.
> I imagine that's because those modules would arrange to temp-fail a message
> that has that problem. I suppose my experience is that messages don't even
> get to the point of DMARC evaluation when that happens, because the message
> has already been temp-failed.

As SPF (and DKIM) can report a message with the status tempfail, it means the 
message is not necessarily tempfail (bounced). 

> If you think about DKIM and SPF as being part of a layer below DMARC, then
> I'm not sure it's wise of us to be making any kind of normative statement
> about what to do when the lower layers fail.

> What do you suggest?

I think we should recommend something here, not sure if it needs to be 
normative. We do say to ignore the SPF policy when p!=none, though I think we 
can be normative on the lower layers. I see 2 options here: 
1)tempfail the message is either SPF and DKIM have a tempfail status 
2)tempfail the message if both SPF and DKIM have a tempfail status 

1) is my preferred and is aggressive, therefore not sure people will like it. 
I'll settle for 2) 

As explained in another post, I'm worried I can run a DNS attack (or just a 
self inflicted DNS bad config) and get DMARC to reject emails it should have 
accepted (has the DMARC policy in cache, but cannot assert SPF and DKIM). 
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman 
wrote:

> There was a recent thread on postfix-users about DMARC rejections when
> there
> are DNS errors that caused me to review -08 to see what it says on the
> matter.
>
> At the end of section 5.6.2, it says:
>
>Handling of messages for which SPF and/or DKIM evaluation encounters
>a DNS error is left to the discretion of the Mail Receiver.  Further
>discussion is available in Section 5.6.3.
>
> My reading of 5.6.3 though is that it only discusses DNS errors in the
> context
> of failing to retrieve the DMARC record.  Any discussion about handling DNS
> errors for SPF/DKIM seems to be missing.
>

Yes, DMARC punts on what to do when SPF or DKIM encounter transient
failures.  I imagine that's because those modules would arrange to
temp-fail a message that has that problem.  I suppose my experience is that
messages don't even get to the point of DMARC evaluation when that happens,
because the message has already been temp-failed.

If you think about DKIM and SPF as being part of a layer below DMARC, then
I'm not sure it's wise of us to be making any kind of normative statement
about what to do when the lower layers fail.

What do you suggest?

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

For the stuff not already answered in my last reply to Dave:

On Sun, Dec 21, 2014 at 2:18 AM, Jim Fenton  wrote:

> [2.4 Out of Scope]
> >> Bullet 10: Again, DMARC doesn't do authentication, even for domains; it
> >> relies on other authentication mechanisms.
> > I originally thought this, too, but in fact DMARC does do authentication:
> >
> >  DMARC asserts authenticity of the rfc5322.From field domain name.
> > That's a distinct semantic increment over anything SPF or DKIM do on
> > their own.
>
> What it does is different enough from SPF and DKIM that I think it's
> overloading the term "authentication" to use it again here. It doesn't
> contribute to a clear understanding. It looks at the results of SPF and
> DKIM, which operate at the domain level, so this bullet isn't really
> necessary.
>

Doesn't RFC5322.From also operate at the domain level in our context?

DMARC's filtering function is based on whether SPF or DKIM can provide
> an authenticated, aligned identifier for the message under
> consideration. Messages that purport to be from a Domain Owner's domain
> and arrive from servers that are not authorized by that domain's SPF and
> do not contain an appropriate DKIM signature can be affected by DMARC
> policies.
>
> [I think the additional "that domain's" will do it.]
>

Added.


> >> 5. DMARC policy record
> >>
> >> Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate
> >> characterization. If the query requirement matched perfectly with the
> >> DNS, DNS would have a way to determine the Administrative Domain without
> >> resorting to suffix lists and such. Just strike the sentence; this isn't
> >> relevant here anyway.
> > -08 doesn't have this language.
>
> Now section 5.1, paragraph 2. Honestly, this reads like marketing fluff
> that doesn't belong in a specification like this.
>

I don't have any trouble removing it.  I think it was added to ward off
anyone that might claim "You shouldn't be using the DNS for this."


> >> 11.1 Discovery
> > 6.2.1 in -08
> >
> >> Mail Receivers can also discover reporting requests from the
> >> Organizational Domain. That should be mentioned here. But I'm a little
> >> confused why we have another Discovery section at all.
> > The text's use of the word 'corresponds' handles the mapping to org
> > domain, IMO.
>
> This is more of a comment about document organization. The previous
> sections have been talking about things that follow discovery of the
> policy record, and now when talking about aggregate reports there's
> another section about discovery. Why here; isn't this a little redundant?
>

It's mainly to say that there isn't a specific discovery process for
aggregate report details; it's already done.  This might be a legacy from
ancient versions where there was a separate process.  I'll tidy it up by
merging it into the previous subsection.


> SHOULD isn't strong enough for the Report Receiver to depend on. There
> are other ways to get the information that is encoded into the filename.
>

Like what?


> If the spec wants to suggest, "here's a nice file name format that you
> MAY want to use", that's fine. But SHOULD is both too weak if the
> recipient can't depend on it and too strong if it's merely advice.
>

I'm not so sure.  If we're going to go with MAY, then we also need some
kind of signal that the filename used does conform to the proposed
encoding, or else there might be some attempt to extract report parameters
that simply aren't there.


> >> The privacy consideration here, which isn't obvious from the wording, is
> >> that users may currently use forwarding in a way that prevents the
> >> sender from determining the ultimate delivery address. DMARC has the
> >> potential to break that. This might be important in the case of a user
> >> that is trying to distance themselves from a stalker.
> > How is that a DMARC-specific 'exposure' consideration?
>
> Because it's the retrieval (or search for) the DMARC record might
> reveals that. But on rereading this, paragraph 4 addresses this
> sufficiently.
>
> New issue: Paragraph 3 refers to "Both report types" but since iodef was
> removed, it should just say "The AFRF report type".
>

That refers to the aggregate and detailed reports ("rua" and "ruf"), not
IODEF and AFRF.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Murray S. Kucherawy]

On Fri, Dec 19, 2014 at 5:30 PM, Dave Crocker  wrote:

> > 3.2 Organizational Domain
> >
> > I remain very concerned about this algorithm since I have been
> > previously told very specifically not to do this by the DNS folks. I'm
> > also concerned about the inconsistency (interoperability impact) that
> > could result from different operators using different public suffix
> lists.
>
> Everyone is concerned about it.  But it's the best that is currently
> available.
>

+1, and furthermore, -08's Section 3.2 and Appendix A.6 both admit the
current method is flawed and DMARC operators should switch to something
better as soon as such a thing becomes available.  I don't know what more
can be said at this point.


> > 4. Policy
> >
> > Paragraph 4 basically says, if you don't want a particular
> > authentication scheme to be considered by DMARC, don't use it at all.
> > For a domain that is using SPF and DMARC (for example), this could be an
> > impediment to their deployment of DKIM because they could not test with
> > it without having it immediately affect recipients' message handling.
> > One possibility would be to ignore DKIM if the testing (t=y) flag is
> > set, although a campaign would be needed to get the many domains
> > currently using t=y to turn it off. Another possibility would be to have
> > a setting in DMARC to ignore a specific authentication method entirely.
>
> The first possibility isn't viabile, for the reason cited.  The second
> possibility might be worth pursuing in the DMARC working group, rather
> than in a document that captures existing DMARC practice.
>
> There are, of course, other possibilities, such as not having DMARC
> pursue operational nuance that makes the spec more complex, trying to
> handle special cases.  That is, if a site isn't ready to use DMARC, it
> shouldn't.
>

The "pct" tag was also provided to address the concern that the impact of
enabling DMARC is uncertain.


> > 7.1 Verifying External Destinations
> >
> > Paragraph 3: "verification steps SHOULD be taken" These steps are to
> > protect another domain from attack. It needs to be a MUST.
>
> 6.1 in -08.
>
> Given the problems with the search for org domain, a SHOULD is as far as
> is practical here.
>
> I'd suggest noting that that's a reason this can't be a MUST.
>

I think it's SHOULD because at the time it was written, the verification
process was untested.  It's in production now (OpenDMARC implements it), so
I agree that a MUST is appropriate.


> > 8. Policy Discovery
> ...
>
> 5.6.3 in -08
>
>
> > Second-to-last paragraph: "If the RFC5322.From domain does not exist in
> > the DNS" is basically changing what RFC5321/5322 allow. This isn't the
> > place to be making fundamental changes to the behavior of email.
>
> It isn't meant to be.
>
> -08 text says:
>
>  "If the RFC5322.From domain does not exist in the DNS, Mail
>Receivers
>SHOULD direct the receiving SMTP server to reject the message.  The
>choice of mechanism for such rejection and the implications of those
>choices are discussed in Section 9.3."
>
> I suggest removing it.  Although a common anti-abuse mechanism, it's out
> of scope for DMARC.
>

I disagree.  DMARC operators all seem to apply this practice, so it's
correct to say that if you play this game, you reject mail from
non-existent domains.  Essentially in this way DMARC is a profile of
RFC5321/RFC5322, which is perfectly acceptable.  We are not updating those
standards here, merely profiling them.


> > 9. Domain Owner Actions
>
> 5.5 in -08
>
> > Last paragraph doesn't seem like it fits. Suggest it be removed.
>
> While I could imagine a better place for it in the doc, having a /terse/
> pointer like this to some authentication pedagogy seems useful to me, in
> an authentication-related spec...
>

+1.


> > 11.1 Discovery
> 6.2.1 in -08
>
> > Mail Receivers can also discover reporting requests from the
> > Organizational Domain. That should be mentioned here. But I'm a little
> > confused why we have another Discovery section at all.
>
> The text's use of the word 'corresponds' handles the mapping to org
> domain, IMO.
>

+1, and there isn't a second Discovery section anymore; there was a Great
Consolidation at around the -05 version.


> > 11.2.1 Email
> >
> > The whole thing about filenames needs to go away. Since it's only a
> > SHOULD requirement, the Report Receiver needs to be able to handle
> > reports that don't follow this format as well as those that do.
>
> "SHOULD" is a very strong normative statement. Note that it permits
> non-conformance only in the presence of singular knowledge by the
> non-conforming party.
>
> Filename labeling is generally considered useful.  Why wouldn't it be
> useful here?
>

+1, not to mention again that this is current practice among DMARC
operators and doesn't seem to be an issue so far.


> > 14.1 Data Exposure Considerations
> >
> > Last paragraph: what's an "unexpected Mail Receiver"?
>

Reworded.


> > The privacy co

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

[Dave Crocker]

On 12/22/2014 11:39 AM, Kurt Andersen wrote:
> Failing means that the polices are not applied.  As in MUST NOT be
> applied.
> 
> 
> DMARC is built on a positive assertion model. To say that a failure
> means that no policy is applied is contrary to the model. The policy is
> explicitly *applied* if neither SPF nor DMARC validates the aligned domain


oops. sorry.  right.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Franck Martin]

- Original Message -
> From: "Dave Crocker" 
> To: "R E Sonneveld" , "Scott Kitterman" 
> 
> Cc: dmarc@ietf.org
> Sent: Monday, December 22, 2014 11:16:01 AM
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> 
> On 12/22/2014 11:11 AM, Rolf E. Sonneveld wrote:
> >>
> >> Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a
> >> temporary error in SPF or DKIM processing prevents a full evaluation."
> > 
> > +1
> 
> 
> We need to be careful about how this is phrased.  I specifically suspect
> that the above suggested wording is a bad idea, or worse, probably wrong.
> 
> DMARC /requires/ prior validation of the author From domain via a
> lower-level mechanism.  SPF and DKIM are defined for now.  If neither of
> them validates the domain, then DMARC fails.
> 
> There is no 'should' about it.  It fails.
> 
> Failing means that the polices are not applied.  As in MUST NOT be applied.
> 

You are opening an attack vector here. I could DDoS your domain Name servers 
and then send emails on your behalf... As a receiver, It would be better to 
tempfail emails until DNS is restored.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Rolf E. Sonneveld]

On 12/22/2014 08:16 PM, Dave Crocker wrote:

On 12/22/2014 11:11 AM, Rolf E. Sonneveld wrote:

Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a
temporary error in SPF or DKIM processing prevents a full evaluation."

+1


We need to be careful about how this is phrased.  I specifically suspect
that the above suggested wording is a bad idea, or worse, probably wrong.

DMARC /requires/ prior validation of the author From domain via a
lower-level mechanism.  SPF and DKIM are defined for now.  If neither of
them validates the domain, then DMARC fails.


What do you mean with 'validates'?:

a) confirm that the domain exists and that the required information for 
the lower-level mechanism(s) could successfully be determined?

b) 'authenticates'
c) something else?

Assuming you mean a) (or something that is close to it), then the 
problem here is: what if SPF cannot be 'validated' while DKIM can, and 
vice versa?




There is no 'should' about it.  It fails.

Failing means that the polices are not applied.  As in MUST NOT be applied.


This seems to me to be contradictory of the way the word 'fails' is used 
in http://tools.ietf.org/id/draft-kucherawy-dmarc-base-08.txt. For 
example: how should I interpret these last two lines, when comparing 
this with what is being said about 'fails'  in the context of 
'p=quarantine' and 'p=reject':



   quarantine:  The Domain Owner wishes to have email that fails the
  DMARC mechanism check to be treated by Mail Receivers as
  suspicious.  Depending on the capabilities of the Mail
  Receiver, this can mean "place into spam folder", "scrutinize
  with additional intensity", and/or "flag as suspicious".


and


   reject:  The Domain Owner wishes for Mail Receivers to reject
  email that fails the DMARC mechanism check.  Rejection SHOULD
  occur during the SMTP transaction.  See Section 9.3 for some
  discussion of SMTP rejection methods and their implications.


Please read http://tools.ietf.org/id/draft-kucherawy-dmarc-base-08.txt 
again and mark every occurrence of he word 'fail' or 'fails'. Often it 
is used in the context of DKIM and SPF checks, sometimes in the context 
of DMARC mechanisms etc.


I'm confused.

/rolf

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Kurt Andersen]

On Mon, Dec 22, 2014 at 11:16 AM, Dave Crocker  wrote:

> On 12/22/2014 11:11 AM, Rolf E. Sonneveld wrote:
> >>
> >> Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a
> >> temporary error in SPF or DKIM processing prevents a full evaluation."
> >
> > +1
>
> We need to be careful about how this is phrased.  I specifically suspect
> that the above suggested wording is a bad idea, or worse, probably wrong.
>
> DMARC /requires/ prior validation of the author From domain via a
> lower-level mechanism.  SPF and DKIM are defined for now.  If neither of
> them validates the domain, then DMARC fails.
>
> There is no 'should' about it.  It fails.
>
> Failing means that the polices are not applied.  As in MUST NOT be applied.


DMARC is built on a positive assertion model. To say that a failure means
that no policy is applied is contrary to the model. The policy is
explicitly *applied* if neither SPF nor DMARC validates the aligned domain.

I disagree with the "not act. . .[if not] full evaluation" - if SPF
tempfails, but DKIM passes, that is sufficient for a DMARC pass and I don't
see any reason to force the DMARC evaluation to some other value. If SPF
tempfails and DKIM is missing or fails, then treating the outcome as
"unknown" seems reasonable

If SPF or DKIM come up with a temp error, that could be an attack vector to
bypass DMARC enforcement, but if receivers simply tempfail such mail, it
seems consistent to me with the handling of any other error that is
expected to be transient in nature. If it really is an attack of some sort,
the mail will eventually time out on the sender's machine.

I'm not sure that adding this detail prior to the WG's work output would be
prudent or in keeping with the intent of the current "stake in the sand"
spec.

--Kurt
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 12/22/2014 11:11 AM, Rolf E. Sonneveld wrote:
>>
>> Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a
>> temporary error in SPF or DKIM processing prevents a full evaluation."
> 
> +1


We need to be careful about how this is phrased.  I specifically suspect
that the above suggested wording is a bad idea, or worse, probably wrong.

DMARC /requires/ prior validation of the author From domain via a
lower-level mechanism.  SPF and DKIM are defined for now.  If neither of
them validates the domain, then DMARC fails.

There is no 'should' about it.  It fails.

Failing means that the polices are not applied.  As in MUST NOT be applied.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Rolf E. Sonneveld]

On 12/22/2014 08:02 PM, Scott Kitterman wrote:

On Monday, December 22, 2014 12:40:36 PM Franck Martin wrote:

- Original Message -


From: "Scott Kitterman" 
To: dmarc@ietf.org
Sent: Monday, December 22, 2014 7:44:04 AM
Subject: Re: [dmarc-ietf] Jim Fenton's review of -04

On Friday, December 19, 2014 01:30:10 PM Murray S. Kucherawy wrote:

Colleagues,

draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's
been
pointed out that a review from back in April has not been properly
attended
to.

Could I get the WG (forgive me, co-chairs!) to comment on this so that I
can see what changes might be appropriate here?  Having this resolved
before the telechat in the first week of January would be truly
delightful.

Note that some amount of this may have already been addressed (it was
about
-04; -08 is current, and at least the ABNF issue Jim raises will be
handled
in -09), so please at least check -08 when considering your responses.

The posting:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html

There was a recent thread on postfix-users about DMARC rejections when
there are DNS errors that caused me to review -08 to see what it says on
the matter.

At the end of section 5.6.2, it says:
Handling of messages for which SPF and/or DKIM evaluation encounters
a DNS error is left to the discretion of the Mail Receiver.  Further
discussion is available in Section 5.6.3.

My reading of 5.6.3 though is that it only discusses DNS errors in the
context
of failing to retrieve the DMARC record.  Any discussion about handling
DNS
errors for SPF/DKIM seems to be missing.

I had a few issues with a large sender, which had their TXT record
overloaded (not uncommon, this is where google analytics and other wants to
prove who you are). Combined with a low TTL, it would happen rarely, but
frequently enough that an SPF could not be assessed and DMARC would fail.
The fallback mechanism in bind is slow when you have edns issues.

1) I wished that SPF record location would have been _spf.
2) may be here the recommendation, is that with DMARC it is best to tempfail
an email if you can’t get an SPF result due to DNS (same with DKIM), rather
than carry on and pass the result to higher policy layers.

The underscore location was considered at the time, but in 2004 we believed
that it would have created a significant barrier to deployment since many
tools/service provider control panels at the time didn't allow it.  It would
certainly be better now, but as with type SPF, there's no transition
mechanism.  If we were going to transition SPF records anywhere, it would have
been better to do it to the new RR type.

Both SPF and DKIM do have a temporary error state, so it's certainly possible
to include this.  I think it's totally up to the receiver if they choose to
defer (45X) or choose not to use DMARC in case of a temporary error in one of
the underlying protocols (i.e. SPF or DKIM) making it impossible to make a
complete DMARC evaluation.

Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a
temporary error in SPF or DKIM processing prevents a full evaluation."


+1

/rolf

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On Monday, December 22, 2014 12:40:36 PM Franck Martin wrote:
> - Original Message -
> 
> > From: "Scott Kitterman" 
> > To: dmarc@ietf.org
> > Sent: Monday, December 22, 2014 7:44:04 AM
> > Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> > 
> > On Friday, December 19, 2014 01:30:10 PM Murray S. Kucherawy wrote:
> > > Colleagues,
> > > 
> > > draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's
> > > been
> > > pointed out that a review from back in April has not been properly
> > > attended
> > > to.
> > > 
> > > Could I get the WG (forgive me, co-chairs!) to comment on this so that I
> > > can see what changes might be appropriate here?  Having this resolved
> > > before the telechat in the first week of January would be truly
> > > delightful.
> > > 
> > > Note that some amount of this may have already been addressed (it was
> > > about
> > > -04; -08 is current, and at least the ABNF issue Jim raises will be
> > > handled
> > > in -09), so please at least check -08 when considering your responses.
> > > 
> > > The posting:
> > > http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html
> > 
> > There was a recent thread on postfix-users about DMARC rejections when
> > there are DNS errors that caused me to review -08 to see what it says on
> > the matter.
> > 
> > At the end of section 5.6.2, it says:
> >Handling of messages for which SPF and/or DKIM evaluation encounters
> >a DNS error is left to the discretion of the Mail Receiver.  Further
> >discussion is available in Section 5.6.3.
> > 
> > My reading of 5.6.3 though is that it only discusses DNS errors in the
> > context
> > of failing to retrieve the DMARC record.  Any discussion about handling
> > DNS
> > errors for SPF/DKIM seems to be missing.
> 
> I had a few issues with a large sender, which had their TXT record
> overloaded (not uncommon, this is where google analytics and other wants to
> prove who you are). Combined with a low TTL, it would happen rarely, but
> frequently enough that an SPF could not be assessed and DMARC would fail.
> The fallback mechanism in bind is slow when you have edns issues.
> 
> 1) I wished that SPF record location would have been _spf.
> 2) may be here the recommendation, is that with DMARC it is best to tempfail
> an email if you can’t get an SPF result due to DNS (same with DKIM), rather
> than carry on and pass the result to higher policy layers.

The underscore location was considered at the time, but in 2004 we believed 
that it would have created a significant barrier to deployment since many 
tools/service provider control panels at the time didn't allow it.  It would 
certainly be better now, but as with type SPF, there's no transition 
mechanism.  If we were going to transition SPF records anywhere, it would have 
been better to do it to the new RR type.

Both SPF and DKIM do have a temporary error state, so it's certainly possible 
to include this.  I think it's totally up to the receiver if they choose to 
defer (45X) or choose not to use DMARC in case of a temporary error in one of 
the underlying protocols (i.e. SPF or DKIM) making it impossible to make a 
complete DMARC evaluation.

Perhaps 5.6.3 needs something like "SHOULD NOT act on DMARC policy if a 
temporary error in SPF or DKIM processing prevents a full evaluation."

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Franck Martin]

- Original Message -
> From: "Scott Kitterman" 
> To: dmarc@ietf.org
> Sent: Monday, December 22, 2014 7:44:04 AM
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> 
> On Friday, December 19, 2014 01:30:10 PM Murray S. Kucherawy wrote:
> > Colleagues,
> > 
> > draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's been
> > pointed out that a review from back in April has not been properly attended
> > to.
> > 
> > Could I get the WG (forgive me, co-chairs!) to comment on this so that I
> > can see what changes might be appropriate here?  Having this resolved
> > before the telechat in the first week of January would be truly delightful.
> > 
> > Note that some amount of this may have already been addressed (it was about
> > -04; -08 is current, and at least the ABNF issue Jim raises will be handled
> > in -09), so please at least check -08 when considering your responses.
> > 
> > The posting:
> > http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html
> 
> There was a recent thread on postfix-users about DMARC rejections when there
> are DNS errors that caused me to review -08 to see what it says on the
> matter.
> 
> At the end of section 5.6.2, it says:
> 
>Handling of messages for which SPF and/or DKIM evaluation encounters
>a DNS error is left to the discretion of the Mail Receiver.  Further
>discussion is available in Section 5.6.3.
> 
> My reading of 5.6.3 though is that it only discusses DNS errors in the
> context
> of failing to retrieve the DMARC record.  Any discussion about handling DNS
> errors for SPF/DKIM seems to be missing.


I had a few issues with a large sender, which had their TXT record overloaded 
(not uncommon, this is where google analytics and other wants to prove who you 
are). Combined with a low TTL, it would happen rarely, but frequently enough 
that an SPF could not be assessed and DMARC would fail. The fallback mechanism 
in bind is slow when you have edns issues.

1) I wished that SPF record location would have been _spf.
2) may be here the recommendation, is that with DMARC it is best to tempfail an 
email if you can’t get an SPF result due to DNS (same with DKIM), rather than 
carry on and pass the result to higher policy layers.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Scott Kitterman]

On Friday, December 19, 2014 01:30:10 PM Murray S. Kucherawy wrote:
> Colleagues,
> 
> draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's been
> pointed out that a review from back in April has not been properly attended
> to.
> 
> Could I get the WG (forgive me, co-chairs!) to comment on this so that I
> can see what changes might be appropriate here?  Having this resolved
> before the telechat in the first week of January would be truly delightful.
> 
> Note that some amount of this may have already been addressed (it was about
> -04; -08 is current, and at least the ABNF issue Jim raises will be handled
> in -09), so please at least check -08 when considering your responses.
> 
> The posting:
> http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html

There was a recent thread on postfix-users about DMARC rejections when there 
are DNS errors that caused me to review -08 to see what it says on the matter.

At the end of section 5.6.2, it says:

   Handling of messages for which SPF and/or DKIM evaluation encounters
   a DNS error is left to the discretion of the Mail Receiver.  Further
   discussion is available in Section 5.6.3.

My reading of 5.6.3 though is that it only discusses DNS errors in the context 
of failing to retrieve the DMARC record.  Any discussion about handling DNS 
errors for SPF/DKIM seems to be missing.

Scott K

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 12/20/2014 11:18 PM, Jim Fenton wrote:
>>  DMARC asserts authenticity of the rfc5322.From field domain name.
>> That's a distinct semantic increment over anything SPF or DKIM do on
>> their own.
> 
> What it does is different enough from SPF and DKIM that I think it's
> overloading the term "authentication" to use it again here.

Jim,

It's not 'overloading' anything.

Authentication is a term of art.  It's meaning is well-established.  For
example:

   Internet Security Glossary, Version 2
   https://tools.ietf.org/html/rfc4949

   $ authentication
  (I) The process of verifying a claim that a system entity or
  system resource has a certain attribute value.

There are many authentication mechanisms.  The issue is not whether
DMARC's authentication is 'different from' SPF or DKIM.  The issue is
whether it is authenticating something.

It is.

The fact that SPF and DKIM are in the mix is not relevant to the
question of whether DMARC is authenticating something.

It is authenticating the domain name in the rfc5322.From field.

Neither SPF nor DKIM make any assertions about the validity of the
domain name in the rfc5322.From field.


> It doesn't
> contribute to a clear understanding. It looks at the results of SPF and
> DKIM, which operate at the domain level, so this bullet isn't really
> necessary.

The results of SPF and DKIM say nothing about the rfc5322.From field.
The assertion of validity for the domain name in that field is a bit of
value-add that is specific to DMARC.  Value-add of that sort is
classically called authentication.


>>> 3.1.2 General Concepts
>> ...
>>> Paragraph 3 doesn't quite capture the sense of alignment properly,
>>> especially for SPF. A message that is authorized by SPF might have an
>>> unaligned envelope-from address, so the validity of SPF for such
>>> messages is moot.
>> I think this is par. 2 in the -08 draft and that text looks fine to me.
> 
> Yes, paragraph 2. My point is that a the last sentence seems to say that
> if a message arrives from a server authorized by SPF, it will not be
> affected by DMARC policies.
...

>> If someone thinks the text needs changing, they need to offer candidate
>> text.
> 
> DMARC's filtering function is based on whether SPF or DKIM can provide
> an authenticated, aligned identifier for the message under
> consideration. Messages that purport to be from a Domain Owner's domain
> and arrive from servers that are not authorized by that domain's SPF and
> do not contain an appropriate DKIM signature can be affected by DMARC
> policies.

I don't read that existing last sentence the way you do.  However on
reflection, I think the first sentence can be improved and would prefer
some wording changes for the paragraph, too.  Perhaps:

   DMARC's filtering function is based on whether the rfc5322.From field
domain is aligned with (matches) an authenticated domain name from SPF
or DKIM.  When a message has a published DMARC policy associated with
the domain name in the RFC5322.From field, and that domain is not
validated through SPF or DKIM, the disposition of that message can be
affected by the DMARC policy.



>>> 4. Policy
>>>
>>> Paragraph 4 basically says, 
...
>> There are, of course, other possibilities, such as not having DMARC
>> pursue operational nuance that makes the spec more complex, trying to
>> handle special cases.  That is, if a site isn't ready to use DMARC, it
>> shouldn't.
> 
> The point is that use of DMARC may come first, and makes SPF and DKIM
> more brittle. Domains that have deployed DMARC may want to deploy both
> SPF and DKIM (having already deployed one or the other), but it would be
> better if they didn't have to turn off DMARC to do so.

It does not 'make SPF and DKIM more brittle'.  It does not affect their
operation at all.

As for DMARC 'coming first', I don't understand that.  DMARC can't
operate without an existing SPF and/or DKIM infrastructure.

At any rate, as for your 'it would be better' assertion, it well might
be true.  But responding to that concern can't happen in isolation.

To deal with it appears to impose more overall complexity.  And systems
complexity creates its own base of errors that we would then have to
deal with.


>>> 5. DMARC policy record
>>>
>>> Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate
>>> characterization. If the query requirement matched perfectly with the
>>> DNS, DNS would have a way to determine the Administrative Domain without
>>> resorting to suffix lists and such. Just strike the sentence; this isn't
>>> relevant here anyway.
>> -08 doesn't have this language.
> 
> Now section 5.1, paragraph 2. Honestly, this reads like marketing fluff
> that doesn't belong in a specification like this.

'Perfectly' and 'considerable' do tend to add a bit of marketing tone.

I think that dropping those two words moves the entire paragraph into
the realm of offering a simple and common justification for use of the
DNS, presumably instead of inventing 

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

[Stephen J. Turnbull]

Jim Fenton writes:
 > Hi, Dave -
 > 
 > On 12/19/2014 02:30 PM, Dave Crocker wrote:
 > 
 > [2.4 Out of Scope]
 > >> Bullet 10: Again, DMARC doesn't do authentication, even for domains; it
 > >> relies on other authentication mechanisms.
 > > I originally thought this, too, but in fact DMARC does do authentication:
 > >
 > >  DMARC asserts authenticity of the rfc5322.From field domain name.
 > > That's a distinct semantic increment over anything SPF or DKIM do on
 > > their own.
 > 
 > What it does is different enough from SPF and DKIM that I think it's
 > overloading the term "authentication" to use it again here. It doesn't
 > contribute to a clear understanding. It looks at the results of SPF and
 > DKIM, which operate at the domain level, so this bullet isn't really
 > necessary.

It's important to be precise about these concepts.  As I read RFC
4949, Dave is correct.  It's true that most of the heavy lifting was
done by SPF or DKIM, and in that sense DMARC is very different.

Nevertheless, it's the fact that DMARC authenticates the domain of the
address in From that makes it useful.  And problematic: it is that
claim of authentication that justifies use of "p=reject".  It had
better be in the document.

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Jim Fenton]

Hi, Dave -

On 12/19/2014 02:30 PM, Dave Crocker wrote:

[2.4 Out of Scope]
>> Bullet 10: Again, DMARC doesn't do authentication, even for domains; it
>> relies on other authentication mechanisms.
> I originally thought this, too, but in fact DMARC does do authentication:
>
>  DMARC asserts authenticity of the rfc5322.From field domain name.
> That's a distinct semantic increment over anything SPF or DKIM do on
> their own.

What it does is different enough from SPF and DKIM that I think it's
overloading the term "authentication" to use it again here. It doesn't
contribute to a clear understanding. It looks at the results of SPF and
DKIM, which operate at the domain level, so this bullet isn't really
necessary.
>
>
>
>> 3.1.2 General Concepts
> ...
>> Paragraph 3 doesn't quite capture the sense of alignment properly,
>> especially for SPF. A message that is authorized by SPF might have an
>> unaligned envelope-from address, so the validity of SPF for such
>> messages is moot.
> I think this is par. 2 in the -08 draft and that text looks fine to me.

Yes, paragraph 2. My point is that a the last sentence seems to say that
if a message arrives from a server authorized by SPF, it will not be
affected by DMARC policies.
>
> If someone thinks the text needs changing, they need to offer candidate
> text.

DMARC's filtering function is based on whether SPF or DKIM can provide
an authenticated, aligned identifier for the message under
consideration. Messages that purport to be from a Domain Owner's domain
and arrive from servers that are not authorized by that domain's SPF and
do not contain an appropriate DKIM signature can be affected by DMARC
policies.

[I think the additional "that domain's" will do it.]
>
>
>
>> 3.2 Organizational Domain
>>
>> I remain very concerned about this algorithm since I have been
>> previously told very specifically not to do this by the DNS folks. I'm
>> also concerned about the inconsistency (interoperability impact) that
>> could result from different operators using different public suffix lists.
> Everyone is concerned about it.  But it's the best that is currently
> available.
>
>
>> 4. Policy
>>
>> Paragraph 4 basically says, if you don't want a particular
>> authentication scheme to be considered by DMARC, don't use it at all.
>> For a domain that is using SPF and DMARC (for example), this could be an
>> impediment to their deployment of DKIM because they could not test with
>> it without having it immediately affect recipients' message handling.
>> One possibility would be to ignore DKIM if the testing (t=y) flag is
>> set, although a campaign would be needed to get the many domains
>> currently using t=y to turn it off. Another possibility would be to have
>> a setting in DMARC to ignore a specific authentication method entirely.
> The first possibility isn't viabile, for the reason cited.  The second
> possibility might be worth pursuing in the DMARC working group, rather
> than in a document that captures existing DMARC practice.
>
> There are, of course, other possibilities, such as not having DMARC
> pursue operational nuance that makes the spec more complex, trying to
> handle special cases.  That is, if a site isn't ready to use DMARC, it
> shouldn't.

The point is that use of DMARC may come first, and makes SPF and DKIM
more brittle. Domains that have deployed DMARC may want to deploy both
SPF and DKIM (having already deployed one or the other), but it would be
better if they didn't have to turn off DMARC to do so.

Agree that this is a bit of a corner case.
>
>
>> 5. DMARC policy record
>>
>> Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate
>> characterization. If the query requirement matched perfectly with the
>> DNS, DNS would have a way to determine the Administrative Domain without
>> resorting to suffix lists and such. Just strike the sentence; this isn't
>> relevant here anyway.
> -08 doesn't have this language.

Now section 5.1, paragraph 2. Honestly, this reads like marketing fluff
that doesn't belong in a specification like this.
>
>
>
>> 7.1 Verifying External Destinations
>>
>> Paragraph 3: "verification steps SHOULD be taken" These steps are to
>> protect another domain from attack. It needs to be a MUST.
> 6.1 in -08.
>
> Given the problems with the search for org domain, a SHOULD is as far as
> is practical here.
>
> I'd suggest noting that that's a reason this can't be a MUST.

This is already predicated on having discovered the DMARC policy, so the
org domain search is irrelevant.

If this is only a SHOULD, under what circumstances might a Mail Receiver
follow a different procedure, or not do this at all? This reporting
procedure is one of the core aspects of DMARC; if someone is doing
something different, I would think that the specification would want to
say that it's not DMARC any more.
>
>
>
>> 8. Policy Discovery
> ...
>
> 5.6.3 in -08
>
>
>> Second-to-last paragraph: "If the RFC5322.From domain does not exist in
>> the

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

[Murray S. Kucherawy]

On Fri, Dec 19, 2014 at 2:30 PM, Dave Crocker  wrote:

> Meta-concern:  Since Jim cited paragraph numbers rather than explicitly
> quoting text, I've no idea whether I'm looking at the correct text.  In
> fact, I've started to fear that his par numbering is zero based...
>

The document has been reorganized since his original comments, so this was
an issue for me as well.

Thanks for your comments.  There was a separate feedback comment that was
purely typos/nits which I'll handle myself and not foist on the WG unless I
really get stuck; dealing with this substantive stuff was my greatest worry.

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

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

[Dave Crocker]

On 12/19/2014 1:30 PM, Murray S. Kucherawy wrote:
> Could I get the WG (forgive me, co-chairs!) to comment

Some of Jim's note are about writing style, precision, specific
terminology usage, points of nuance, or requests for clarification.
I'll leave clarification to Murry, and I'll assume that Murray and/or
the RFC Editor will deal with such niceties.  The niceties matter, but
don't group require discussion, IMO.

So my feedback is limited to points I consider substantive or even
possibly controversial:

Meta-concern:  Since Jim cited paragraph numbers rather than explicitly
quoting text, I've no idea whether I'm looking at the correct text.  In
fact, I've started to fear that his par numbering is zero based...

Substative Meta-concern:  It's important to distinguish between comments
that make sense to pursue in an effort at further development -- that
is, the new working group -- versus ones that clarify the existing spec
or identify significant failures in it.


> The posting:
> http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html



> From: Jim Fenton 
> To: "dmarc at ietf.org" 
> Date: Wed, 16 Apr 2014 12:11:45 -0700
...

> Bullet 10: Again, DMARC doesn't do authentication, even for domains; it
> relies on other authentication mechanisms.

I originally thought this, too, but in fact DMARC does do authentication:

 DMARC asserts authenticity of the rfc5322.From field domain name.
That's a distinct semantic increment over anything SPF or DKIM do on
their own.



> 3.1.2 General Concepts
...
> Paragraph 3 doesn't quite capture the sense of alignment properly,
> especially for SPF. A message that is authorized by SPF might have an
> unaligned envelope-from address, so the validity of SPF for such
> messages is moot.

I think this is par. 2 in the -08 draft and that text looks fine to me.

If someone thinks the text needs changing, they need to offer candidate
text.



> 3.2 Organizational Domain
> 
> I remain very concerned about this algorithm since I have been
> previously told very specifically not to do this by the DNS folks. I'm
> also concerned about the inconsistency (interoperability impact) that
> could result from different operators using different public suffix lists.

Everyone is concerned about it.  But it's the best that is currently
available.


> 4. Policy
> 
> Paragraph 4 basically says, if you don't want a particular
> authentication scheme to be considered by DMARC, don't use it at all.
> For a domain that is using SPF and DMARC (for example), this could be an
> impediment to their deployment of DKIM because they could not test with
> it without having it immediately affect recipients' message handling.
> One possibility would be to ignore DKIM if the testing (t=y) flag is
> set, although a campaign would be needed to get the many domains
> currently using t=y to turn it off. Another possibility would be to have
> a setting in DMARC to ignore a specific authentication method entirely.

The first possibility isn't viabile, for the reason cited.  The second
possibility might be worth pursuing in the DMARC working group, rather
than in a document that captures existing DMARC practice.

There are, of course, other possibilities, such as not having DMARC
pursue operational nuance that makes the spec more complex, trying to
handle special cases.  That is, if a site isn't ready to use DMARC, it
shouldn't.


> 5. DMARC policy record
> 
> Paragraph 2: Again, "matches perfectly with the DNS" is an inaccurate
> characterization. If the query requirement matched perfectly with the
> DNS, DNS would have a way to determine the Administrative Domain without
> resorting to suffix lists and such. Just strike the sentence; this isn't
> relevant here anyway.

-08 doesn't have this language.



> 7.1 Verifying External Destinations
> 
> Paragraph 3: "verification steps SHOULD be taken" These steps are to
> protect another domain from attack. It needs to be a MUST.

6.1 in -08.

Given the problems with the search for org domain, a SHOULD is as far as
is practical here.

I'd suggest noting that that's a reason this can't be a MUST.



> 8. Policy Discovery
...

5.6.3 in -08


> Second-to-last paragraph: "If the RFC5322.From domain does not exist in
> the DNS" is basically changing what RFC5321/5322 allow. This isn't the
> place to be making fundamental changes to the behavior of email.

It isn't meant to be.

-08 text says:

 "If the RFC5322.From domain does not exist in the DNS, Mail
   Receivers
   SHOULD direct the receiving SMTP server to reject the message.  The
   choice of mechanism for such rejection and the implications of those
   choices are discussed in Section 9.3."

I suggest removing it.  Although a common anti-abuse mechanism, it's out
of scope for DMARC.


> 9. Domain Owner Actions

5.5 in -08

> Last paragraph doesn't seem like it fits. Suggest it be removed.

While I could imagine a better place for it in the doc, having a /terse/
pointer like this to some 

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

[Murray S. Kucherawy]

Colleagues,

draft-kucherawy-dmarc-base is nearing IESG conflict review, and it's been
pointed out that a review from back in April has not been properly attended
to.

Could I get the WG (forgive me, co-chairs!) to comment on this so that I
can see what changes might be appropriate here?  Having this resolved
before the telechat in the first week of January would be truly delightful.

Note that some amount of this may have already been addressed (it was about
-04; -08 is current, and at least the ABNF issue Jim raises will be handled
in -09), so please at least check -08 when considering your responses.

The posting:
http://www.ietf.org/mail-archive/web/dmarc/current/msg00764.html

Thank you!

-MSK
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc