Re: [Mailman-Developers] Basic workflow of the ARC implementation
Aditya Divekar writes:
Depending on the message, if it has previous Authentication Results added as a header, that can be extracted too. The entire message can be parsed, and then all the possible headers involved in the authentication process, ie. DKIM signature, Authentication results, ARC headers, can be extracted. If not found, a suitable flag can be set for them. ie. example
- if no previous arc headers were found, a flag can be set. This can later be used in deciding the flow of the mail such as the "i" tag value, whether we need to perform ARC authentication for the previous ARC headers, and other fields that depend on the occurrences of any previous ARC set.
This is all already in the message or msg_data objects, except for the value of "i" itself. So I'm not sure what you're saying. My point is merely that any header field mentioned in any of the relevant RFCs that can be validated must be validated to conform to ARC.
Okay.! So we need to only include the ARC Headers and forward the message to the subscribers, and leave it upto their MTAs to do the needful.
Yes.
I have come up with the following probable milestones for the project. -
Looks good. I have a couple of comments.
(The project has been divided into milestones on the basis of the separate modules that will be created. Each module is a milestone).
I'm not sure you will need so many separate modules; each verification depending on existing standard can probably be kept to a single function, unless you can't get all relevant information from the upstream modules. But it doesn't hurt to separate them now, and think about combining them later, if that's convenient for you.
- ARC Authentication Result - spf verification code completed. tests passed. merge request created.
- ARC Authentication Result - dkim verification code completed. tests passed. merge request created.
- ARC Authentication Result - dmarc verification code completed. tests passed. merge request created.
- ARC Authentication Result - arc verification code completed. tests passed. merge request created.
How do you propose to create tests for #4?
- ARC Authentication Result - generate AAR from the previous milestones code. tests passed. merge request created.
- ARC Message Signature code completed. tests passed. merge request created.
- ARC Seal code completed. tests passed. merge request created.
- Generate the ARC set of headers from the previous milestones code, and prepend them to the message. tests passed. merge request created.
*As you mentioned, branch coverage will be the aim behind all the tests for each module (Branch coverage would mean considering all possible scenarios of the workflow).
Notes -
I've broken down the AAR set into different milestones, since each method will require the use of different functions and packages. (ie. spf, dkim, dmarc, arc).
Regarding milestone 8, separate modules will be responsible for generating the components of the ARC header set, and these can be combined at the end for getting the complete ARC set. This will be useful for testing purposes.
We need to perform the dmarc testing manually since the gs.dmarc package only provides the dmarc policy query functionality. The gs.dmarc package can be used to query the dmarc record of the RFC5322.From domain. Then we can verify using the aspf and adkim relaxed/strict tag values and the spf/dkim results whether the dmarc authentication is a pass or fail, as given in the RFC7489 draft (dmarc draft). Is there a better alternative to this in your knowledge?
No.
I would like your opinion on these milestones, and if possible your ideas can be merged with these to come up with a better list :)
No, your list is workable and basically similar to mine, except for the ordering comment on #4. I think we should develop your ideas first, then compare.
Steve
Stephen Turnbull writes: This is all already in the message or msg_data objects, except for the value of "i" itself. So I'm not sure what you're saying. My point is merely that any header field mentioned in any of the relevant RFCs that can be validated must be validated to conform to ARC.
By extraction I meant that the message could be parsed to get back a tuple of "headers, body" where the headers would be returned as lists containing the name and value. And then all the required headers could be used for the authentication purposes. But since we will be receiving a processed mail from Mailman (msg_data), as mentioned, the parsing won't be required.
I'm not sure you will need so many separate modules; each verification depending on existing standard can probably be kept to a single function, unless you can't get all relevant information from the upstream modules. But it doesn't hurt to separate them now, and think about combining them later, if that's convenient for you.
Yes, I meant to refer to separate functions here actually. By modules I meant that the code for each would be independent, and can be implemented as processes that the mail through. Creating separate functions would help in debugging processes. Sorry for the slip.
- ARC Authentication Result - arc verification code completed. tests passed. merge request created.
How do you propose to create tests for #4?
Here, we could consider a few scenarios- headers. In this case the verification is not performed.
- A message is passed to the function which does not have any previous ARC
- A message containing a valid ARC chain is passed to the function. In this case the verification is performed and the most recent ARC Seal is tested for authenticity, which can be checked in the test.
This would get difficult if we are dealing with cases where the previous ARC chain is longer than 1 or 2, since it would involve extracting all the ARC headers in the message ( tricky, since all the headers have the same "tag", i.e. - all the headers would be named the same - "ARC Message Signature:", "ARC Seal:", and can be differentiated only on the basis of the "i" value ), since the most recent ARC Seal will sign over all these, and hence we need them for the verification process.
Here, a case could occur (if possible) where the message contains a broken ARC chain, i.e. the last MTA did not add its ARC set of headers. This would happen if it is assumed that not all MTAs are enforcing ARC. It is not clear from the draft to me if in this case the arc verification would have to be performed, since the draft assumes that all the intermediaries participate in the ARC system. According to me since the chain is broken, it would not be required to verify the ARC headers. I would like to know how you think this case can be handled.
Thanks
Aditya
participants (2)
-
Aditya Divekar -
Stephen J. Turnbull