#153 duplicate dkim auth_result sections

1.3.1
open
nobody
None
2016-12-18
2016-03-17
t_mk1
No

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>

Discussion

  • t_mk1

    t_mk1 - 2016-03-17

    potential patch

     
  • Juri Haberland

    Juri Haberland - 2016-05-10

    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.

     
    Last edit: Juri Haberland 2016-05-10
  • A. Schulze

    A. Schulze - 2016-05-25

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

     
    • Juri Haberland

      Juri Haberland - 2016-05-25

      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

        Juri Haberland - 2016-12-18

        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.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks