Hi Stephen,

Stephen J. Turnbull wrote:

I don't think it's a great idea to change the dkimpy library if you can avoid it. The design I had in mind would add a file for performing ARC operations such as generating fields, and for dkimpy to simply provide the functions for generating the signatures.

I have taken your suggestion, and started working on a separate branch to

generate the ams from the original dkimpy package. I've created a directory where I can add all the files to generate (or edit) the signature from the dkim library.

This probably requires some refactoring of dkimpy. It might also

require generalizing the canonicalization functions to handle the ARC-specific field sets if there are any hard-coded headers in the DKIM code. You might also look at the alternatives to see if they are better factored for this purpose.

Yes, some minor changes will be required I believe, like changing the default frozen headers to be signed or the tags to be added in the sign. Still, some of them can be circumvented by editing the generated signature in a separate file. And yes, I'll go through the other packages you suggested before to see if I am able to read them better than dkimpy.

I haven't done cross-host work before, but you will surely need a gitlab account eventually to file the merge request.

I will try to take a look at the code over the weekend. I did want to make the comments on the factoring of the code ASAP, before you do too much work.

I have actually just started working on the repo, and hence there are only

a couple of files that I have committed now. And yes, I've just pushed the files to github as of now, so that I am able to get your insight in the proceedings. I'll start working in gitlab soon once I'm able to come up with a sketch of things.

Thanks!

Aditya

Hi Stephen,

Stephen J. Turnbull wrote:

I don't think it's a great idea to change the dkimpy library if you can avoid it. The design I had in mind would add a file for performing ARC operations such as generating fields, and for dkimpy to simply provide the functions for generating the signatures.

I have taken your suggestion, and started working on a separate branch to

generate the ams from the original dkimpy package. I've created a directory where I can add all the files to generate (or edit) the signature from the dkim library.

This probably requires some refactoring of dkimpy. It might also

require generalizing the canonicalization functions to handle the ARC-specific field sets if there are any hard-coded headers in the DKIM code. You might also look at the alternatives to see if they are better factored for this purpose.

Yes, some minor changes will be required I believe, like changing the default frozen headers to be signed or the tags to be added in the sign. Still, some of them can be circumvented by editing the generated signature in a separate file. And yes, I'll go through the other packages you suggested before to see if I am able to read them better than dkimpy.

I haven't done cross-host work before, but you will surely need a gitlab account eventually to file the merge request.

I will try to take a look at the code over the weekend. I did want to make the comments on the factoring of the code ASAP, before you do too much work.

I have actually just started working on the repo, and hence there are only

a couple of files that I have committed now. And yes, I've just pushed the files to github as of now, so that I am able to get your insight in the proceedings. I'll start working in gitlab soon once I'm able to come up with a sketch of things.

Thanks!

Aditya