[Mailman-Developers] Basic workflow of the ARC implementation

[Stephen J. Turnbull]

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.

 > 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 - arc verification code completed. tests
 > passed. merge request created.

How do you propose to create tests for #4?

 > 5. ARC Authentication Result - generate AAR from the previous milestones
 > code. tests passed. merge request created.
 > 6. ARC Message Signature code completed. tests passed. merge request
 > created.
 > 7. ARC Seal code completed. tests passed. merge request created.
 > 8. 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 -
 > 
 > 1. 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).
 > 
 > 2. 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.
 > 
 > 3. 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