#122 Canonicalization wrong with 32k or more empty lines

v2.8.2
open
5
2009-06-02
2009-05-22
No

I was investigating a case of a broken mail message with lots of empty lines in the body. It turns out that once the number of empty lines exceeds about 32k lines, the dkim-milter-2.8.2 claims the signature is not valid, while Mail::DKIM claims the signature is still valid. To test the hypothesis, I prepared and signed (with Mail::DKIM) two messages, which differ only in the number of empty lines - one has slightly less than 32k empty lines, the other has 33000 empty lines. The signature on the shorter message validates, while the longer one fails, as can be seen by the Authentication-Results header field.

I suspect the problem lies in the canonicalization code, although I haven't investigated the details.

Attached is a tar with both test message.

Discussion

  • Mark Martinec

    Mark Martinec - 2009-05-22

    tar file with two test messages

     
  • Anonymous - 2009-05-26
    • assigned_to: nobody --> sm-msk
     
  • Anonymous - 2009-05-26
    • status: open --> pending
     
  • Anonymous - 2009-05-26

    Both of your test cases pass for me with dkim-milter-2-8.2 built on FreeBSD 6.2 or 7.0 (amd64).

     
  • Anonymous - 2009-05-27

    Someone else tested the same files on Linux (2.8.2), NetBSD (2.8.3.dev) and OpenBSD (2.6.0) and both passed in each of those places as well.

     
  • Mark Martinec

    Mark Martinec - 2009-05-27
    • status: pending --> open
     
  • Mark Martinec

    Mark Martinec - 2009-05-27

    Thank you for testing! Perhaps it is an issue with a Postfix milter protocol support. I'll check it out when I find a little time.

     
  • Anonymous - 2009-05-27
    • status: open --> pending
     
  • Mark Martinec

    Mark Martinec - 2009-06-02

    Hmm, I don't know. I tried it now with genuine sendmail on FreeBSD 7.2, with 2.8.2 from ports, and it is
    consistent with my first claim. Also, sending 1fail.txt and 1good.txt to autoresponder at sa-test@sendmail.net
    (using mini_sendmail just to make sure it gets there intact; then retried with a command line sendmail -i
    submission) gives the same result, for one the autoresponder claims 'DKIM signature confirmed BAD',
    the other is 'DKIM signature confirmed GOOD'. I guess I'll need to look at debugging features.

     
  • Mark Martinec

    Mark Martinec - 2009-06-02
    • status: pending --> open
     
  • Mark Martinec

    Mark Martinec - 2009-06-02

    Ok, I have enabled the KeepTemporaryFiles and am now looking at a diff of temporary files of a body of each message, as produced by a 2.8.2 verifier. Besides the obvious fact that one file contains more empty lines than the other (as intended), there is one notable difference in the initial double CR near the beginning of a canonicalized body.

    resulting from 1good.txt:
    test^M^J
    ^M^J
    ^M^J
    ...

    resulting from 1fail.txt:
    test^M^J
    ^M^M^J
    ^M^J
    ^M^J
    ...

     
  • Murray S. Kucherawy

    I just tried this with both 2.8.2 and 2.8.3 on FreeBSD and can't reproduce this; I never get a double CR in the temporary files thus produced.

    The only difference is that I'm using FreeBSD 6.2-RELEASE, and I didn't get it from ports.

     
  • Murray S. Kucherawy

    OK, I see it with 2.8.3 when signing, but not when verifying.

     
  • Murray S. Kucherawy

    The problem appears to occur during signing when a CRLF is split across calls to dkim_body(). Working on a patch now.

     
  • Murray S. Kucherawy

    More details: The problem appears to occur when CRLFs are split across calls to dkim_body(), but it's not specific to signing. Interestingly, there's already a unit test which covers this case and it wasn't failing, so the counting of blank lines within a message is also involved (the unit test didn't do that).

     
  • Mark Martinec

    Mark Martinec - 2009-07-10

    Previous signatures have expired, here are new samples.

     

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

Sign up for the SourceForge newsletter:





No, thanks