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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Dec 2014 13:30:10 -0800

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

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Dec 2014 14:30:13 -0800

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.

>     From: Jim Fenton <fenton at bluepopcorn.net>
>     To: "dmarc at ietf.org" <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 authentication pedagogy seems useful to me, in
an authentication-related spec...

> 10.1 Extract author domain

6.6.1 in -08

> "Such messages SHOULD be rejected": 

looks like it's been removed.

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

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

> I also
> wonder if some operating systems have trouble with filenames containing
> the "!" character. 

If they are, they already need to be able to resolve the issue.

> 14.1 Data Exposure Considerations
> 
> Last paragraph: what's an "unexpected Mail Receiver"?
> 
> 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?

> 14.2 Report Recipients
> 
> Some potential exists for report recipients to perform traffic analysis:
> to obtain metadata about the receiver's traffic. In addition to
> verifying compliance with policies, receivers need to consider that
> before sending reports to a third party.

+1

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 19 Dec 2014 14:34:29 -0800

> 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

---

From: Jim Fenton <[email-masked]>
Date: Sat, 20 Dec 2014 23:18:57 -0800

Hi, Dave -

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

[2.4 Out of Scope]
> That's a distinct semantic increment over anything SPF or DKIM do on

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

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.]
> handle special cases.  That is, if a site isn't ready to use DMARC, it

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

+1

> an authentication-related spec...

The paragraph I was referencing (having to do with "mailto" URIs) is not
in -08.
>> 10.1 Extract author domain
5.6.1, actually
> looks like it's been removed.
Yes, it has.
> The text's use of the word 'corresponds' handles the mapping to org

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?
> Filename labeling is generally considered useful.  Why wouldn't it be

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.

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.
> If they are, they already need to be able to resolve the issue.

I suppose. Seems like there might be other choices that would be less
likely to cause an issue, but I suspect that ship has sailed already.
>> 14.1 Data Exposure Considerations
Now section 8.1
>> Last paragraph: what's an "unexpected Mail Receiver"?

That's now paragraph 5, and I now think it's clear enough.
> 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".
>> before sending reports to a third party.
-Jim

---

From: "Stephen J. Turnbull" <[email-masked]>
Date: Mon, 22 Dec 2014 00:38:06 +0900

> DKIM, which operate at the domain level, so this bullet isn't really

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.

---

From: Dave Crocker <[email-masked]>
Date: Sun, 21 Dec 2014 08:22:56 -0800

On 12/20/2014 11:18 PM, Jim Fenton wrote:
> 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

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.

...

> do not contain an appropriate DKIM signature can be affected by DMARC

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

> 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 a new query mechanism.

People often do not understand the benefit of re-using an existing
mechanism rather than defining a new one, especially when the mechanism
involves a deployment and operation of a global infrastructure.  (cf,
DKIM vs. IIM...)

> follow a different procedure, or not do this at all? 

When the receiver has some basis for knowing that it's ok to deviate
from this portion of the specification.

d/

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 22 Dec 2014 10:44:04 -0500

> 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

---

From: Franck Martin <[email-masked]>
Date: Mon, 22 Dec 2014 12:40:36 -0600 (CST)

----- Original Message -----
> From: "Scott Kitterman" <[email-masked]>
> To: [email-masked]
> Sent: Monday, December 22, 2014 7:44:04 AM
> Subject: Re: [dmarc-ietf] Jim Fenton's review of -04
> 

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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 22 Dec 2014 14:02:28 -0500

On Monday, December 22, 2014 12:40:36 PM Franck Martin 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.
> > 
> 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.
> 
> 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

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 22 Dec 2014 20:11:08 +0100

+1

/rolf

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 Dec 2014 11:16:01 -0800

>> temporary error in SPF or DKIM processing prevents a full evaluation."

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/

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 22 Dec 2014 11:39:28 -0800

> 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

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 22 Dec 2014 20:47:11 +0100

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

> 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

---

From: Franck Martin <[email-masked]>
Date: Mon, 22 Dec 2014 13:53:30 -0600 (CST)

----- Original Message -----
> From: "Dave Crocker" <[email-masked]>
> To: "R E Sonneveld" <[email-masked]>, "Scott Kitterman" <[email-masked]>
> Cc: [email-masked]
> Sent: Monday, December 22, 2014 11:16:01 AM

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.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 22 Dec 2014 15:18:21 -0500

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

I'm confused.  If DKIM does not verify and align and SPF does not pass and 
align then the DMARC result is fail and the policy IS applied.  I must be 
reading you wrong because I think that's the opposite of what you wrote.

I bring it up because it appears (in the postfix-users discussion) that 
possibly a large mail provider (doesn't matter which, really) may be applying 
DMARC fail policy (to reject in this case) when the underlying SPF/DKIM checks 
do not reach a definitive result due to transient DNS errors.

As I read -08 what to do in that case is undefined.  There's a dangling pointer 
to 5.6.3.  It's dangling because nothing in that section addresses the 
question of how to handle DKIM/SPF temporary errors.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 22 Dec 2014 12:27:12 -0800

On 12/22/2014 11:39 AM, Kurt Andersen wrote:
> 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/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 00:49:04 -0500

> question of how to handle DKIM/SPF temporary errors.
5.6.3's final paragraph makes it clear that the action taken is at the
discretion of the mail receiver, and gives two examples of non-destructive
ways to handle that case.  Do we need to say more than that?

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 01:11:55 -0500

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

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

> handle special cases.  That is, if a site isn't ready to use DMARC, it

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

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

> I suggest removing it.  Although a common anti-abuse mechanism, it's out

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.

> an authentication-related spec...

+1.

> The text's use of the word 'corresponds' handles the mapping to org

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

> Filename labeling is generally considered useful.  Why wouldn't it be

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

> > Last paragraph: what's an "unexpected Mail Receiver"?

Reworded.

> How is that a DMARC-specific 'exposure' consideration?

DMARC creates the exposure.  If A sends mail to B which forwards to C and
then to D, D can send reports back to A, revealing the forwarding
relationship from C to D.

Reworded to accommodate.

> > before sending reports to a third party.

Added.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 01:25:57 -0500

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

> DKIM, which operate at the domain level, so this bullet isn't really

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

Added.

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

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

> are other ways to get the information that is encoded into the filename.

Like what?

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

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 01:32:44 -0500

On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman <[email-masked]>
wrote:

> there

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

---

From: Franck Martin <[email-masked]>
Date: Wed, 24 Dec 2014 01:13:24 -0600 (CST)

----- Original Message -----

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "Scott Kitterman" <[email-masked]>
> Cc: [email-masked]
> Sent: Tuesday, December 23, 2014 10:32:44 PM

> On Mon, Dec 22, 2014 at 10:44 AM, Scott Kitterman < [email-masked] >
> wrote:

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 02:20:30 -0500

On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin <[email-masked]>
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:
> 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

---

From: Franck Martin <[email-masked]>
Date: Wed, 24 Dec 2014 01:40:37 -0600 (CST)

----- Original Message -----

> To: "Franck Martin" <[email-masked]>
> Cc: [email-masked], "Scott Kitterman" <[email-masked]>
> Sent: Tuesday, December 23, 2014 11:20:30 PM

> On Wed, Dec 24, 2014 at 2:13 AM, Franck Martin < [email-masked] >
> wrote:

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

> 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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 02:54:59 -0500

On Wed, Dec 24, 2014 at 2:40 AM, Franck Martin <[email-masked]>
wrote:

> ------------------------------
>
> *From: *"Murray S. Kucherawy" <[email-masked]>
> *To: *"Franck Martin" <[email-masked]>
> *Cc: [email-masked], "Scott Kitterman" <[email-masked]>
> *Sent: *Tuesday, December 23, 2014 11:20:30 PM
> *Subject: *Re: [dmarc-ietf] Jim Fenton's review of -04
>
>> it. I'll settle for 2)
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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Dec 2014 03:50:27 -0500

On December 24, 2014 12:49:04 AM EST, "Murray S. Kucherawy" <[email-masked]> wrote:
>> As I read -08 what to do in that case is undefined.  There's a
>dangling
>> pointer

No.  That's specifically about DNS errors related to DMARC record retrieval.  My issue is what to after successfully retrieving the DMARC record if one of SPF/DKIM doesn't pass and align (DMARC fail) and the other of SPF/DKIM returns a DNS error. 

5.6.2 appears to me to promise that is explained in 5.6.3 and it's not. 

Personally, I think rejecting mail based on temporary DNS errors is something the draft should discourage. 

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Dec 2014 04:04:51 -0500

On December 24, 2014 1:32:44 AM EST, "Murray S. Kucherawy" <[email-masked]> wrote:
>> are DNS errors that caused me to review -08 to see what it says on
>the
>> matter.
>>
>> My reading of 5.6.3 though is that it only discusses DNS errors in
>the
>> context

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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Dec 2014 04:09:49 -0500

>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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Dec 2014 07:22:41 -0800

On 12/23/2014 10:11 PM, Murray S. Kucherawy wrote:
> 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/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 10:43:40 -0500

On Wed, Dec 24, 2014 at 4:09 AM, Scott Kitterman <[email-masked]>
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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 10:46:42 -0500

On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman <[email-masked]>
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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 24 Dec 2014 10:50:16 -0500

> DMARC spec means it has to be documented somewhere else, for the folk

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

---

From: Franck Martin <[email-masked]>
Date: Wed, 24 Dec 2014 10:17:14 -0600 (CST)

----- Original Message -----

> To: "Dave Crocker" <[email-masked]>
> Cc: [email-masked]
> Sent: Wednesday, December 24, 2014 7:50:16 AM

> On Wed, Dec 24, 2014 at 10:22 AM, Dave Crocker < [email-masked] > 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.

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?

---

From: Franck Martin <[email-masked]>
Date: Wed, 24 Dec 2014 10:21:43 -0600 (CST)

----- Original Message -----

> Sent: Wednesday, December 24, 2014 7:46:42 AM

> On Wed, Dec 24, 2014 at 4:04 AM, Scott Kitterman < [email-masked] >
> 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.
> 

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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 24 Dec 2014 08:23:54 -0800

On 12/24/2014 7:50 AM, Murray S. Kucherawy wrote:
> 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/

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 24 Dec 2014 16:50:32 +0000

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

I agree with this position. M3AAWG is actually about to publish a
recommendation
to deal with protecting parked domains which includes something like this,
although
it is separate from DMARC itself and can't address the issue of a truly
NXDOMAIN
condition.  

I think that we have to leave NXDOMAIN handling to the discretion of
receivers.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Dec 2014 12:14:27 -0500

> see applied to resolve this?

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

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Dec 2014 11:05:21 -0600

>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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 24 Dec 2014 17:48:17 -0500

> see applied to resolve this?

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

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

---

From: Franck Martin <[email-masked]>
Date: Wed, 24 Dec 2014 19:22:21 -0600 (CST)

----- Original Message -----
> Sent: Wednesday, December 24, 2014 2:48:17 PM
What about pointing it may be a security issue to let these messages through?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Dec 2014 00:02:41 -0500

>    a permanent DNS error is left to the discretion of the Mail Receiver.

I think it pretty much says what's there, but is a lot more clear about
it.  I also think the second sentence is a bit convoluted, so I reworked it
into this.  Does it match what you're trying to say?

                <t> Messages for which SPF and/or DKIM evaluation encounters
                    a temporary DNS error have not received a definitive
                    result for steps 3 and/or 4 above.  When such an
evaluation
                    is done in conjunction with an aligned identifier,
                    completion of the DMARC algorithm is not possible.
                    In this case, receivers can either skip DMARC for this
                    message due to incomplete evaluation, or they can
arrange
                    to defer handling of the message in the hope that the
                    temporary error will be resolved when the message is
                    retried.  In any case, Receivers cannot apply DMARC
                    policy and reject or quarantine the message because the
                    DMARC evaluation is incomplete.  When otherwise
                    appropriate due to DMARC policy, receivers MAY send
                    feedback reports regarding temporary errors. </t>

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Dec 2014 00:06:27 -0500

> 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

---

From: "John Levine" <[email-masked]>
Date: 25 Dec 2014 05:13:06 -0000

>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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Dec 2014 01:04:08 -0500

On Wednesday, December 24, 2014 19:22:21 Franck Martin wrote:
> > > > apply DMARC policy and reject or quarantine because the DMARC
> > > > evaluation
> > > > is
> > > > incomplete.
> > > 

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

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

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Dec 2014 01:08:12 -0500

On Thursday, December 25, 2014 00:02:41 Murray S. Kucherawy wrote:
> >    DNS error have not received a definitive result for steps 3 and/or 4
> > 
> > above.
> > 
> a temporary DNS error have not received a definitive result for steps 3
> and/or 4 above.  When such an evaluation

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Dec 2014 21:43:29 -0500

> 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

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Dec 2014 21:46:48 -0500

> 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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 25 Dec 2014 19:15:04 -0800

On 12/25/2014 6:46 PM, Murray S. Kucherawy wrote:
> 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/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 25 Dec 2014 23:30:32 -0500

> 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/AAAA 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

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 25 Dec 2014 22:54:52 -0600

On December 25, 2014 8:43:29 PM CST, "Murray S. Kucherawy" <[email-masked]> wrote:
>> I don't think it does.  What I was trying to say is that if you
>already
>> got an
>> one gets a DNS error, you already have a definitive result.  I don't
>think
>> your

I believe that covers it.

>> 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),

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

Thanks,

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Fri, 26 Dec 2014 22:06:20 -0800

On 12/23/2014 10:25 PM, Murray S. Kucherawy wrote:
> 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.
>  
>

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.

> 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
> That refers to the aggregate and detailed reports ("rua" and "ruf"),
> not IODEF and AFRF.

Ah, thanks.

-Jim

---

From: Franck Martin <[email-masked]>
Date: Sat, 27 Dec 2014 17:48:03 -0800

> On Dec 25, 2014, at 8:30 PM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> On Thu, Dec 25, 2014 at 10:15 PM, Dave Crocker <[email-masked] <mailto:[email-masked]>> wrote:
> 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/AAAA 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 <http://examples.com/> instead of example.com <http://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?

---

From: "John Levine" <[email-masked]>
Date: 28 Dec 2014 03:25:44 -0000

>the inbox can be trusted by end users to be valid.

Now, wait a minute.  DMARC can tell you that a message is probably not
a phish with an exact match From: domain, but it can't tell you that a
return address is "valid" for any but the most uselessly nitpicky
definition of valid.  (Consider a message From:
[email-masked], with SPF that makes DMARC p=reject happy.)

One can conclude with great confidence that a From: domain that
doesn't exist is not an exact match phish of anything, which tells me
that it's none of DMARC's business.

Also, as others have observed, there are plenty of reasons one might
reject a message before doing DMARC validation (Spamhaus DROP, say)
and it does not seem productive to attempt to compile a list of them.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 28 Dec 2014 11:36:41 -0800

Murray, et al,

On 12/25/2014 8:30 PM, Murray S. Kucherawy wrote:
> 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.

When informed, serious participants have a basic difference in their
understanding of the scope of a specification, it's difficult to ensure
proper focus for the work.  It makes interpretations amongst the larger
community likely to be problematic.

So I think this exchange is important to pursue as a matter of
clarifying basic principles...

Good wg charters help understanding of what is in scope but also what is
out of scope.

A specification needs to do the same.  Otherwise, it's content can
wander randomly and -- typically -- defeating the efficacy of the spec.

I think the DMARC spec is somewhere between good and excellent at
stating its scope, which is offered as:

> However, there has been no single widely
>    accepted or publicly available mechanism to communication of domain-
>    specific message handling policiies for receivers, or to request
>    reporting of authentication and disposition of received mail.

So while there is obviously the larger goal of fighting abuses, it is
the publication mechanism of DMARC that is the focus.

But more explicit detail is also provided:

> DMARC allows domain owners and receivers to collaborate by:
> 
>    1.  Providing receivers with assertions about domain owners' policies
> 
>    2.  Providing feedback to senders so they can monitor authentication
>        and judge threats
> 
>    The basic outline of DMARC is:
> 
>    1.  Domain owners publish policy assertions about domains via the
>        DNS.
> 
>    2.  Receivers compare the RFC5322 From: address in the mail to the
>        SPF and DKIM results, if present, and the DMARC policy in DNS.
> 
>    3.  These receivers can use these results to determine how the mail
>        should be handled.
> 
>    4.  The receiver sends reports to the domain owner or its designee
>        about mail claiming to be from their domain.

So, we ought to be able to take any proposed technical point for the
spec and ask whether the above sufficiently informs whether to include
or exclude the point.

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

The presence of a multi-valued From: isn't explicitly ok or not ok,
given the above.

However as we saw during the debate about this issue, having a
multi-valued from makes #2, above, significantly more complex and in
fact makes the semantics of DMARC more challenging.  So a decision to
simplify things by restricting DMARC's use to From: fields with only one
address has a direct benefit on the basic DMARC mechanism.

(For clarity, let's remember that this is not a change to RFC5322, in
that domains not asserting DMARC are still free to use multi-valued From:.)

And now let's look at the MX issue:  How does it related to the above
list of goal/scope statements?

IMO, it is entirely independent.

A From: field that does not support a reply can still be valid.   By way
of pressing this point further, note that an email address isn't just an
email address.  It is a unique identifier.  Hence it's possible that the
From: address could be meant solely to uniquely identify the author,
even without being able to directly reply to their address.

It would be an unusual case, of course, but there is nothing in DMARC
mechanism or semantics that requires that a reply reach the author and
hence there is no reason for DMARC to impose this particular restriction.

Note also the point I cited in the previous message:  Domains that do
not participate in DMARC are just as likely to want to assert the MX
requirement.  Hence it should be documented independently of DMARC.

> If the MX/A/AAAA test fails, then there's no policy to apply.  

I will claim that this is not a correct assessment.  If there is a DMARC
record for the domain, there is policy to apply.

> We [used
> to] reject on the basis that it's impossible for that message to
> legitimately exist.

Some/many sites apply that rule.  Some do not.  The MX/A/AAAA rule is
entirely independent of other anti-abuse mechanisms, and it should
remain independent.

> If the single-value From: test fails, then which domain's policy is to
> be applied is potentially indeterminate. 

Exactly.  And that's why the decision for DMARC constraints to simplify
From: makes sense.

d/

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 29 Dec 2014 15:26:26 +0000

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:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Thursday, December 25, 2014 11:55 PM
> To: [email-masked]
> >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...)
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Dec 2014 08:40:11 -0800

On 12/29/2014 7:26 AM, MH Michael Hammer (5304) wrote:
> "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:

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

---

From: [email-masked]
Date: Mon, 29 Dec 2014 08:50:51 -0800 (PST)

> can apply the advertised DMARC policy.

This looks good to me.

				Ned

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 29 Dec 2014 13:40:27 -0500

>> can apply the advertised DMARC policy.

Shouldn't it be cannot apply the advertised DMARC policy? 

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Dec 2014 11:32:27 -0800

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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 29 Dec 2014 14:38:43 -0500

>therefore cannot (yet) apply the advertised DMARC policy.

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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 29 Dec 2014 20:15:26 +0000

Still not quite correct...

> From: dmarc [mailto:[email-masked]] On Behalf Of Dave Crocker
> Sent: Monday, December 29, 2014 2:32 PM
> To: Scott Kitterman; [email-masked]
> 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
> 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.
> 
>      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

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 29 Dec 2014 15:21:46 -0500

On December 29, 2014 3:15:26 PM EST, "MH Michael Hammer (5304)" <[email-masked]> wrote:
>of
>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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Mon, 29 Dec 2014 20:32:39 +0000

> Sent: Monday, December 29, 2014 3:22 PM
> To: [email-masked]

DOH! I stand corrected.

> 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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 29 Dec 2014 13:57:35 -0800

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/

---

From: Steven M Jones <[email-masked]>
Date: Mon, 29 Dec 2014 13:59:39 -0800

On 12/29/2014 12:32 PM, MH Michael Hammer (5304) wrote:
>> [...]

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.

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 30 Dec 2014 13:39:58 +0000

> Sent: Monday, December 29, 2014 4:58 PM
> To: [email-masked]
> 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

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 30 Dec 2014 14:38:44 +0000

> From: dmarc [mailto:[email-masked]] On Behalf Of Steven M Jones
> Sent: Monday, December 29, 2014 5:00 PM
> To: [email-masked]
> >> From: dmarc [mailto:[email-masked]] 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).
> 

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 30 Dec 2014 08:01:36 -0800

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/

---

From: Franck Martin <[email-masked]>
Date: Tue, 30 Dec 2014 13:15:06 -0800

> On Dec 30, 2014, at 5:39 AM, MH Michael Hammer (5304) <[email-masked]> wrote:
> 
> 
> 
+1

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 31 Dec 2014 20:43:06 -0800

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 <[email-masked]>
wrote:

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