Re: [dmarc-ietf] dmarc and forwarding

[Kurt Roeckx <[e-mail]>]

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