Hi Steve,
After reading the recent mails it seems that I should have submitted the
draft on the gsoc website.
I shall do the same immediately :)
Aditya
On Wed, Mar 16, 2016 at 10:04 PM, Aditya Divekar
wrote:
> Hi Steve,
>
> I went ahead and drafted a rough proposal as you advised.
> I've in
Regarding my previous mail,
I have implicitly assumed that the testing would involve the use of
examples which do not have a pre-existing valid ARC chain in them i.e. the
test examples would not be containing mails which have multiple ARC set of
headers, and that the ARC chain would be first initia
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.
Aditya Divekar writes:
> Yes, in that case the arc verification would need to be postponed to after
> the entire code for the header generation has been written. I'll need to
> rethink the milestones a bit, since this testing part would have to be
> added at the end, and things will change qui
Hi Steve,
> The problem is how do you get such a message? The easiest way is if
> you have implemented the creation functions for the ARC-* fields.
>
> Then you can check that you can roundtrip your own fields (create and
> verify). Of course you will eventually need to test against other
> imp
Aditya Divekar writes:
> > > 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 doe
> 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 A
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 resul
Hi Steve!
> This should be trivial to do with the Python email package, too. I
> don't really see that a separate module would be useful, since we'll
> want to extract a fixed set of headers (ARC- and DKIM-specified). Of
> course it should be factored into a separate function (or perhaps a
> ge
Aditya Divekar writes:
> We need to generate a private and a public key for the signing purposes.
> For testing purposes, and while working on the code, I can probably
> generate the keys locally using the openssl tool.
In production, these keys are a *site* resource. I see no reason why
we n
Hi Steve!
Now going back to the implementation, the message needs to be signed after
its headers have been cooked, since they are included in some of the
signatures below.
So after the message headers have been cooked, and before the message has
been enqueued by the switchboards onto the various q
11 matches
Mail list logo
