Subject: Re: [dmarc-ietf] dmarc and forwarding

From: Kurt Roeckx <[email-masked]>
Date: Wed, 5 Feb 2014 01:59:28 +0100

On Sat, Feb 01, 2014 at 12:04:43PM +0800, Roland Turner wrote:
> "Non-participating" MLMs (RFC 6377) are outside DMARC's scope.

This draft does not update the RFC 6377 requirements for
mailinglists, but I do think it changes the requirements.  But it
also seems to contain the posibility to override this somehow,
but it's all outside the scope of DMARC.

> >it might see that SPF has a pass, but it's going to say that it
> >doesn't allign with the header from. What is unclear to me is what
> >the result of that should be. Is it just going to ignore this SPF
> >result?
> 
> DMARC is going to ignore it, yes.
> 
> >Will it result in an SPF fail even though it was really a pass?
> 
> No, DMARC does not alter SPF. If SPF passes, it does so with or
> without DMARC being present. What DMARC does do is decide when to
> make use of an SPF pass; in particular it only does so when the SPF
> domain and 5322.From domain are aligned. Note that a DMARC
> implementation therefore has to deal with two separate
> interpretations of an SPF result:
> 
>  * The domain name and result from the authentication mechanism itself;
>    this is the auth_results section of an aggregate report.
>  * The relevance of the underlying results to a DMARC policy
>    evaluation; this is the policy_evaluated section of an aggregate
>    report. Any time the SPF domain is unaligned a fail will appear
>    here, even if SPF passed (and therefore shows a pass in the
>    auth_results section).

>From what I understand, I have received very few aggregate report
that gets all the results correct.  There always seems to be
something wrong with it.  And I think the draft isn't helping in
making things clear because it just documents the format.

As I understand it, in the case of the mails you send to this
list, you should receive the following:
    <auth_results>
      <dkim>
        <domain>ietf.org</domain>
        <selector>ietf1</selector>
        <result>pass</result>
      </dkim>
      <dkim>
        <domain>rolandturner.com</domain>
        <selector>20120325</selector>
        <result>fail</result>
      </dkim>
      <spf>
        <domain>ietf.org</domain>
        <scope>mfrom</scope>
        <result>pass</result>
      </spf>
    </auth_results>

I'm just going to guess that the results you get back contain all
kinds of wrong information, but I hope you at least get some that
are more or less correct.

I think that because none of those that pass are alligned it
should then result in:
        <policy_evaluated>
          <disposition>none</disposition>
          <dkim>fail</dkim>
          <spf>fail</spf>
        </policy_evaluated>

Possibly it could have an reason there added.

What is unclear to me is what happens when either dkim of spf
would pass and the policy_published contains p=reject.  Should it
be:
        <policy_evaluated>
          <disposition>reject</disposition>
          <dkim>pass</dkim>
          <spf>fail</spf>
        </policy_evaluated>

Or:
        <policy_evaluated>
          <disposition>none</disposition>
          <dkim>pass</dkim>
          <spf>fail</spf>
        </policy_evaluated>

Please note that the draft seems to indicate that it should
contain the value from p or sp, but that if you override it
it can contain some other value.  So I can read that even if you
accept it because dkim says pass that the disposition should be
reject.  And I have to guess that's not really the intension.

> Note further that DMARC is also selective about its use of DKIM,
> except that the DKIM d= must match from 5322.From domain exactly
> (merely being aligned isn't enough). The same two interpretations
> must therefore be understood and they appear in the same two places
> in the aggregate report as above.

I'm not sure I understand what you're saying here.  As I
understand it, there is a strict and relaxed way for that?

> >So in the end DMARC will say your mail is not authentic,
> 
> Not exactly: DMARC doesn't make determinations about authenticity,

DMARC seems to talk a lot about authentication, including in it's
name, so I fail to understand that.

Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 5 Feb 2014 09:54:08 -0800

> name, so I fail to understand that.

Neither DKIM nor SPF, upon which DMARC is built, purport to claim
authenticity over the content of the message as a whole, so DMARC isn't
claiming that either.  Rather, it is claiming authenticated use of the
domain you see in the From: field of the message; it goes no further.

-MSK

---

From: Roland Turner <[email-masked]>
Date: Fri, 07 Feb 2014 14:35:58 +0800

> but it's all outside the scope of DMARC.

I do not understand this paragraph or its relevance to the quoted sentence.

> something wrong with it.

It would be very helpful for you to share those so the relevant issues 
can be identified and addressed.

> And I think the draft isn't helping in

Would you care to propose specific improvements?

>          <domain>ietf.org</domain>

I suspect that this conversation would proceed more quickly if you 
provided real examples rather than hypothetical ones but yes, sure.

> are more or less correct.

Your guess is incorrect.

> Possibly it could have an reason there added.

As my published policy is none, there is no requirement for a reason.

A reason is only required if the published policy is quarantine or 
reject and neither mechanism yields a pass that DMARC can use but the 
receiver has decided to override that (e.g. because the forwarder is 
believed by the receiver to be trustworthy, or because the Domain Owner 
is believed by the receiver to not have control of their legitimate 
message streams).

>            <disposition>none</disposition>

None, obviously: an aligned domain has passed SPF. 
(draft-kucherawy-dmarc-base-02 
<https://datatracker.ietf.org/doc/draft-kucherawy-dmarc-base/?include_text=1> 
10.2 5)

> reject.  And I have to guess that's not really the intension.

No, that's the policy_published section.

> understand it, there is a strict and relaxed way for that?

Interesting, a misunderstanding on my part. Thank you.

- Roland

---

From: Roland Turner <[email-masked]>
Date: Tue, 18 Feb 2014 19:24:16 +0800

I meant to respond to this earlier:

On 01/31/2014 02:38 PM, Mike Jones wrote:
> Roland gave an excellent explanation of the reason for the alignment 
> requirement the DMARC specifies.  One point in his reply I will 
> disagree on though is that domains without a current spoofing problem 
> should not implement a DMARC quarantine or reject policy.  This thing 
> about spoofing is that one never knows when one will become a victim.  
> We often see domains that go periods of time without a spoofing issue 
> and then are hit hard on one day.  If the your domain has excellent 
> SPF and DKIM with a high overall DMARC pass rate, you have fully 
> analyzed your DMARC reports to understand the risk of failures due to 
> mailing lists or forwarding, and everything looks good then why not 
> protect yourself from future attacks with a DMARC quarantine or reject?

I may have overstated slightly, but as a practical matter there really 
is a bound below which p=quarantine/reject does more harm than good to a 
Domain Owner, not because smaller organisations are immune from spoofing 
but because there is a non-zero cost in monitoring and interpreting 
authentication failures and responding when appropriate. Whether this 
cost is borne as a monetary subscription to an authentication 
specialist, as yet another demand on the time of an IT guy who's already 
spread far too thinly, or simply in disruption to business when neither 
of the above is in place and something breaks, the cost isn't zero. If 
the expected benefit of protection (the likely - not worst case - impact 
of an incident multiplied by the probability of an incident - a number 
which is vanishingly close to zero for most organisations) is less than 
the cost of monitoring, interpreting and responding then quarantine and 
reject are harmful choices.

The challenge, of course, is where to draw the line. F500s are clearly 
in the cross-hairs, Alexa's top thousand (and some distance beyond) 
likewise. Somewhere a little further along this continuum however, is a 
point beyond which the costs of monitoring, interpreting and responding 
(or of disruption) exceed the benefit. My guess, although I admit that I 
have no credible quantitative model, is that this applies to a 
substantial majority of all domains which are used in 5322.From headers.

- Roland