[Mailman-Developers] Basic workflow of the ARC implementation

[Aditya Divekar]

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.