[Mailman-Developers] Basic workflow of the ARC implementation

[Aditya Divekar]

> 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.


>  > 4. 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-
1. A message is passed to the function which does not have any previous ARC
headers. In this case the verification is not performed.
2. 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