#153 duplicate dkim auth_result sections

[t_mk1]

It may be that this reflects multiple valid signatures in the original message, but I do not think that it is valuable in DMARC:

  <record>
    <row>
      <source_ip>13.24.16.15</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>tomki.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>tomki.com</domain>
        <result>fail</result>
      </spf>
      <dkim>
        <domain>tomki.com</domain>
        <result>pass</result>
      </dkim>
      <dkim>
        <domain>tomki.com</domain>
        <result>pass</result>
      </dkim>
    </auth_results>
  </record>

[t_mk1]

potential patch

[Juri Haberland]

I think this patch is invalid - as I understand the DMARC RFC it is valid to have multiple dkim sections in one auth_result section, as the RFC states in Appendix C: DMARC XML Scheme:

<!-- This element contains DKIM and SPF results, uninterpreted
        with respect to DMARC. -->
   <xs:complexType name="AuthResultType">
     <xs:sequence>
       <!-- There may be no DKIM signatures, or multiple DKIM
            signatures. -->
       <xs:element name="dkim" type="DKIMAuthResultType"
         minOccurs="0" maxOccurs="unbounded"/>
       <!-- There will always be at least one SPF result. -->
       <xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
                   maxOccurs="unbounded"/>
     </xs:sequence>
   </xs:complexType>

Notice the maxOccurs="unbounded" in the element named dkim.

[A. Schulze]

the initial patch was wrong. Attached a corrected version.
Tomki confirmed the results are usable now.

[Juri Haberland]

And still I think my objection is valid - or do I misunderstand the problem?
Is it just to suppress dkim results that are equal? Or is it to suppress multiple dkim results in general?
If the latter, IMHO the RFC is definite.
If the first, than we should seek the reason for multiple equal results. If the fact that they occure is not alterable, we should live with multiple equal results as they are allowed by the RFC.

[Juri Haberland]

After studying the patch I have no objections anymore. This patch supresses duplicate results - different results for the same domain are still reported.

[Murray S. Kucherawy]

Will follow up on this for 1.3.3 or 1.4.0.

[Murray S. Kucherawy]

Patch applied for 1.4.0.