RE: odkim.sign and odkim.validate

From: Murray S. Kucherawy <>
Date: Mon, 2 Apr 2012 04:52:46 +0000

> -----Original Message-----
> From: [] On Behalf Of ????? ????????
> Sent: Sunday, April 01, 2012 12:11 PM
> To:
> Subject: odkim.sign and odkim.validate
> the documentation of of opendkim.conf(5) for Mode is written, that it
> has to be either "s"(open dkim only signs messages), "v" (opendkim only
> verifies messages) or "sv" (both verify and sign). In my configuration
> I have several MTAs connected to the same opendkim, and a setup.lua,
> which takes different actions based on {daemon_name}: sometimes it only
> signs messages, sometimes opendkim only verifies messages and sometimes
> opendkim shall both sign and verify the messages. To my understanding
> the setup.lua script should be something like:
> local mtaname = odkim.get_mtasymbol(ctx, "{daemon_name}") if mtaname == "sm-80" then
> odkim.sign(ctx, "aegee")
> odkim.verify(ctx)
> elseif mtaname == "sm-localhost" then
> odkim.sign(ctx, "aegee")
> else
> odkim.verify(ctx)
> end
> return nil
> Okay, now what role has the switch "Mode" in the configuration file for
> opendkim, when the logic of singing/verifying is solely in the
> setup.lua file?

To do what you're trying to do with the setup script, you should be in "sv" mode. The absence of one or the other mode flag is an optimization to the rest of the code when you know your filter will never do one or the other, but in your case it could do either, so your Mode setting should enable both.

> I had problems with setup.lua, when it makes both explicitly verify and
> sign actions, but I am not 100% sure, that making sign and verify at
> the same time is the reason. In the provided opendkim/setup.lua.sample
> file, the action is either only sign or only verify, but why is it not
> possible to do sometimes only one of the actions, sometimes both (for
> an email, that is supposed to be forwarded to another server).

The example file is only an example, and a fairly simple one at that. There's no reason you couldn't do both, except maybe some bugs we haven't encountered yet.

> The milter log reported me "Broken pipe" and I was not able to check it
> deeper.

Sounds like it crashed. Did it leave a core dump? A stack trace or steps to reproduce that condition would be very helpful.

> Moreover I found in the documentation of libopendkim:dkim_getsighdr_d
> (called from opendkim.c) that it is not possible to make verify and
> dkim_getsighdr_d with the same context.

That function is only ever used with a signing handle to extract the signature to be added to a message. It is not used in verify contexts, because you already have the signature. Accordingly, passing a verify handle to that function always returns an error.

> Finally, the documentation of KeyTable says, that it is possible to
> write as third value either the file, where the key is stored, or the
> key itself. If I have a key in the format:
> ABC1
> EFG2
> Provided that I want to put as third value in a KeyTable the above key,
> and not the file containing the key, how shall I format the KeyTable
> file:
> KEY-----\nABC1\nEFG2\n-----END RSA PRIVATE KEY----- or
> A\nEFG2 or
> A or in a different way? In anycase,
> adding
> a test under opendkim/tests, where the key is described withing the
> KeyTable would allow first to see an example how it works (, and second
> to test if it works).

The KeyFile's third parameter is described as follows:

        If the third value starts with a slash ("/") character, or "./" or "../",
        then it is presumed to refer to a file from which the private key should
        be read, otherwise it is itself a PEM-encoded private key or a base64-encoded
        DER private key; ...

For a flat file, you can't use PEM format because the newline characters are significant both to the flat file and to the PEM format. Your next choice is to use base64-encoded DER, which is the stuff between the BEGIN and END lines with all the newlines removed. This is probably your best bet. So the third example you have above is what you should try, and it should work.

Received on Mon Apr 02 2012 - 04:52:54 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:20:38 PST