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