1. How to use the available message corpus to test the DKIM Verifier

Outlined here is just one of the possible way that the available Message Corpus can be used:

• Messages are placed in a text file all together and separated by a desirable token.

• Each message can then be extracted from the file with a script (a language of your choice).

• Each Message is sent to the verifier and the behavior can be checked based on the verification results.

• Message flow for test cases that already have the Signature embedded in the test message can be as shown below:

  • Script->Verifier->POP Server->Script (Popped Message send back to the executing or any other script for analysis)

2. Tag values in DKIM-Signature:

Sample DKIM-Signature with Authentication-Results header:

DKIM-Signature: a=rsa-sha1; q=dns; l=86; t=1128384795; x=-1019098854;
            c=nowsp; s=testing1234; h=Subject:From:To:Cc:Date:Content-Type:Content-Transfer-Encoding:MIME-Version:X-DKIM;
            d=dkim.org; i=mickey@dkim.org; z=From:mickey@dkim.org|
            Subject:GM=20-=20Very=20Promising=20Beginning;
            b=wWNzEWwZ21vpEuSOMmTxPPCVJxNu+o18FRKP/JfG7D8JQl0oZzpAHhybEn5S2cHWNF3TYpgj
            89Tn2vbvPAbpcg==;
Authentication-Results: testing.dkim.org; header.From=mickey@dkim.org; dkim=pass (message from dkim.org verified; );
 

3. Tag Values of a DKIM Key Record

Records are stored in DNS TXT RRs as selector._domainkey.example.com

4. Test Cases:

There are only a limited number of Signed Messages included in the tarball, ten to be precise. This will increase as users contribute further suggestions and ideas. The purpose of these test cases is to test some of the basic functionalities of the DKIM Verifier being tested. Following is a brief listing of the test messages available in the Message Corpus and how they could be tested.

1. Basic Test Case (Message: BasicTest_01)
   • This is just a basic test case with all the available Signature tags present and with none of the tags modified.
   • To test, just change the "To:" to the address of a user on your VERIFIER and ensure that the message is deemed to be "pass", an example given below:
   • Authentication-Results: <your_verifying_machine>; header.From=mickey@dkim.org; dkim=pass (message from dkim.org verified; );
2. Signed Message with c=simple (Message: Simple_02)
   • Signed message with c=simple.
   • To test, just change the "To:" to the address of a user on your VERIFIER and ensure that the message is deemed to be "pass", an example given below:
   • Authentication-Results: <your_verifying_machine>; header.From=mickey@dkim.org; dkim=pass (message from dkim.org verified; );
3. Signed Message with c=nowsp (Message: Nowsp_3)
   • Signed message with c=nowsp.
   • To test, just change the "To:" to the address of a user on your VERIFIER and ensure that the message is deemed to be "pass", an example given below:
   • Authentication-Results: <your_verifying_machine>; header.From=mickey@dkim.org; dkim=pass (message from dkim.org verified; );
4. Message with MIME attachment and c=simple (Message: MIMEsimple_04)
   • Signed message with MIME attachment and c=simple.
   • To test, just change the "To:" to the address of a user on your VERIFIER and ensure that the message is deemed to be "pass", an example given below:
   • Authentication-Results: <your_verifying_machine>; header.From=mickey@dkim.org; dkim=pass (message from dkim.org verified; );
5. Message with MIME attachment and c=nowsp (Message: MIMEnowsp_05)
   • Signed message with MIME attachments and c=nowsp.
   • To test, just change the "To:" to the address of a user on your VERIFIER and ensure that the message is deemed to be "pass", an example given below:
   • Authentication-Results: <your_verifying_machine>; header.From=mickey@dkim.org; dkim=pass (message from dkim.org verified; );
6. Message with Multiple DKIM Signatures (Message: MultipleSig_06)
   • The message in the file MultipleSig_06 has TWO DKIM-Signature headers (both valid).
   • There is no requirement as far as the author was able to determine on how multiple signatures must be handled.
   • Ensure though that the presence of multiple signatures does not break the verifier.
   • Determine the behavior of your verifier due to the presence of multiple signatures.
7. Message with the presence of the "v=" tag (Message: AddedVtag_07)
   • The draft states the following about the v= tag in the Signature:

   • v=

     Verifiers MUST ignore DKIM-Signature header fields with a “v=” tag. Existence of such a tag indicates a new, incompatible version of the DKIM-Signature header field.

   • The message present in the file "AddedVtag_07" is signed with the presence of the "v=" tag value set at "DKIM1".
   • The expected result is Authentication-Results: <your_verifying_machine>; header.From=mickey@dkim.org; dkim=neutral or fail; based on the Signing Policy
8. Multiple signed received headers (Message: MultipleReceived_08):
   • The draft states: "Signers choosing to sign an existing replicated header field (such as Received) MUST sign the physically last instance of that header field in the header field block. Signers wishing to sign multiple instances of an existing replicated header field MUST include the header field name multiple times in the h= tag of the DKIM-Signature header field, and MUST sign such header fields in order from the bottom of the header field block to the top."
   • The message "MultipleReceived_08" has a signature which signs on "TWO" received headers (bottom up).
   • Ensure that if either of these Received header is modified or deleted, your verifier reports other than a "pass" result based on your Signing Policy.
9. Existing Pre-Signed Header (Message: PreSignedHeader_09):
   • The draft states: "Signers MAY claim to have signed header fields that do not exist (that is, signers MAY include the header field name in the h= tag even if that header field does not exist in the message). When computing the signature, the non-existing header field MUST be treated as the null string.
   • The message "PreSignedHeader_09" contained in the tarball has been signed with a header field "X-DKIM" which does not actually exist in that message.
   • Ensure that the verifier is able to recognize this and gives a Authentication Results header similar to: Authentication-Results: <your_verifying_machine>; header.From=mickey@dkim.org; dkim=pass (message from dkim.org verified; );
10. Presence of Multiple Authentication-Results headers (Message: MultipleAuthRes_10)
    • The message file "MutlipleAuthRes_10" does NOT contain any DKIM Signature but carries two pre-existing invalid "Authentication-Results" headers.
    • There is no particular requirement on how multiple Authentication-Results headers should be handled.
    • Determine the behavior of your verifier with the presence of these multiple headers.

     

Last Modified:
Comments concerning this site should be sent to:
webmaster@testing.dkim.org