Hi Steve, As discussed in our earlier conversation, I went over the milestones again and made some changes. We would need to use the approach of creating our own examples in the milestone for the AS code (milestone 6, for testing) too, since the AS signs over the previous generated set of headers. This will however not be a problem since the AMS and AAR code should be already completed by that point thus enabling the creation of test example. And as said before, the second time this approach would be used in milestone 7. The reordering of the arc verification after the completion of the AMS and the AS should not be a problem since the AMS and AS code do not refer explicitly to the arc verification field in the AAR. Both of them use the AAR in their signing[1] as a whole field and are not concerned with its individual fields, and hence the addition of arc at a later stage should not create any problem. Also the examples used for testing by us in milestone 5 and 6 would not involve the `arc = ` field since the example mail will be consisting of the first instance of the ARC headers i.e. `i = 1`, and hence the arc verification test would not be performed (i.e. no `arc = ` field in the AAR), even after the code for it is inserted in its place, thus keeping the tests in milestones 5 and 6 valid.
Milestones - 1. ARC Authentication Result - spf verification code completed. tests passed. merge request created. 2. ARC Authentication Result - dkim verification code completed. tests passed. merge request created. 3. ARC Authentication Result - dmarc verification code completed. tests passed. merge request created. 4. ARC Authentication Result - generate AAR header from the previous milestones code. tests passed. merge request created. 5. ARC Message Signature code completed. tests passed. merge request created. 6. ARC Seal code completed. tests passed. merge request created. 7. ARC Authentication Result - arc verification code completed. tests passed. (The workflow is modified to make the mail pass through this function after milestone 3 [2] ). merge request created. 8. The mail is prepended with the complete set of ARC headers. Tests for checking the entire ARC set of headers passed. merge request created (tests). Comments on testing - 1. For spf testing - The spf library itself provides test examples, and mails can be extracted (i.e. the part before gmail adds its own authentication results) from gmail using the `Show Original` feature. These mails can be used for testing purposes. 2. For dkim testing - The dkim library provides testing examples, and similar to above, mails may be used from gmail. 3. For dmarc testing - The examples for this can be gathered from our gmail account. Any mail sent from yahoo's domain to a gmail account will have dmarc verification performed. A mail extracted so can be used for testing purposes by us. 4. Testing this would require testing of the format of the generated AAR against the official RFC7601 format for authentication results (since the values of the individual fields have already been tested above) i.e. keeping track of the delimiters, white spaces, and the correct prepending. The AAR header generated for an example mail from the above code can be used here, and tested against the format outlined in the ARC draft. 5. ARC Message Signature testing - We can generate the signature for a given example mail from the written code, and generate a signature using the same set of headers from the dkim package (keeping track of the implicit and explicit headers). The crucial part would be matching the signatures, i.e. the "b" tag, and matching the body hash, i.e. the "bh" tag. The "t" tag would differ since it depends on the exact time, and the "i","a","s","d", "h" tags can be checked manually. 6. ARC Seal testing - For this we could use the previously defined AAR and AMS, and the current AS code to generate a mail with the full ARC set of headers (the AS would sign over the AAR and the AMS generated in the previous milestones). An example mail could be then passed through the above code, and then can be used for testing purposes (Here we would need the approach of generating our example from the code as you mentioned). Here too, the "i", "a" , "s" , "d" , "cv " tags can be checked manually and the "t" tag would differ. Hence the crucial tag would be the "b" tag. 7. The code for the arc verification test is completed. We can now perform the arc verification test here. A fully cooked mail with the ARC headers can be prepared from the above code for the `pass` test . For a `fail` test, we can make some manual changes in the AS to invalidate it, and then perform arc verification on it. 8. Here the testing for the complete ARC set of headers would need to be performed. An example mail can be passed through the above entire code, and manually asserted in the test. (Since the individual fields would have already been tested, the main aim here would be testing that the ARC headers have been prepended correctly, in the correct order, and the format outlined in the draft is maintained). [1] The draft says that the AMS should include the AAR explicitly in the signing. Here <https://tools.ietf.org/html/draft-andersen-arc-02#section-5.1.2.2.1.2>, section 5.1.2.2.1.2 [2] The workflow of the mail can be handled through a handler function ( can be decided later). This can then be changed after milestone 7 to follow the required order. Thanks! Aditya. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org https://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9