dkimpy

Any reason not to use python library's email module to represent message in DKIM object?

Asked by Jim Welch

Administering an MTA (qmail), I find myself wanting to inyspect outbound messages prior to DKIM signing. So I use the Python Library's email module to parse the message resulting in a message object upon which my inspection. Then I have to reassemble the message (using email.generator) to pass it to DKIM sign(), which in turn parses it again. It seems like it would be sensible to have the option to pass the message object to DKIM sign() as alternative to passing the flat message text.

Question information

Language:
English Edit question
Status:
Solved
For:
dkimpy Edit question
Assignee:
No assignee Edit question
Solved by:
Jim Welch
Solved:
Last query:
Last reply:
Revision history for this message
Stuart Gathman (stuart-gathman) said : 		#1

dkim doesn't parse the message body (other than low level things like collapsing whitespace for CanonicalizeBody). If there was a convenience API, it would still have to convert back to a flat file. The hash signed by dkim includes selected headers and the full body without regard to other formatting (e.g. MIME).

DKIM splits the message on '\n\n' into header and body. Header is split into header fields, and selected header fields are hashed after the any header canonicalization. Then canonicalization is applied to the body blob, if any, before hashing.

Revision history for this message
Jim Welch (genconc) said : 		#2

Thanks for this response.

I would be using the HeaderParser which yields the "payload" (the body) as an unparsed blob. So that doesn't seem to be a disincentive. However, upon closer inspection of the email.generator docs, I conclude that it would not be suitable for simple header canonicalization. In particular there's a footnote that says the Generator in some cases will collapse whitespace in headers.

So it seems my proposed feature would only be convenient if my need is to inspect only headers prior to signing and only if I have no requirement to do simple canonicalization or my MTA is the first signer.

All in all I don't see the proposal having wide enough applicability to merit further consideration.