Hello,
Thanks for the detailed answer. Now somehow both signing and verifying
work, I do not know why yesterday they have not worked. Putting the
private key directly in the keysTable dataset works too (and I do not
know why previously it has not worked). opendkim has not created core
files, even if I set "ulimit -c unlimited" before running opendkim, or I
do not know where the core files shall be.
Anyway, here is a patch fixing two compiler warnings (dkim_mail_parse
wants parameters of type u_char):
diff --git a/opendkim/opendkim.c b/opendkim/opendkim.c
index 1d2ac51..3379fea 100644
--- a/opendkim/opendkim.c
+++ b/opendkim/opendkim.c
_at_@ -12291,8 +12291,8 @@ mlfi_eoh(SMFICTX *ctx)
hdr = dkimf_findheader(dfc,
conf->conf_identityhdr, 0);
if (hdr != NULL)
{
- char *user;
- char *domain;
+ u_char *user;
+ u_char *domain;
status = dkim_mail_parse(hdr->hdr_val,
&user, &domain);
_at_@ -12301,7 +12301,7 @@ mlfi_eoh(SMFICTX *ctx)
snprintf((char *) identity,
sizeof identity,
"%s_at_%s",
- user == NULL ? "" : user,
+ user == NULL ? "" :
(char*)user,
domain);
idset = TRUE;
}
On 02.04.2012 06:52, Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-bounce_at_lists.opendkim.org] On Behalf Of ????? ????????
>> Sent: Sunday, April 01, 2012 12:11 PM
>> To: opendkim-users_at_lists.opendkim.org
>> 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:
>>
>> -----BEGIN RSA PRIVATE KEY-----
>> ABC1
>> EFG2
>> -----END RSA PRIVATE KEY-----
>>
>> 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:
>>
>> A mydomain.org:L1024:-----BEGIN RSA PRIVATE
>> KEY-----\nABC1\nEFG2\n-----END RSA PRIVATE KEY----- or
>> A mydomain.org:L1024:ABC1\nEFG2 or
>> A mydomain.org:L1024:ABC1EFG2 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.
>
> -MSK
>
>
Received on Mon Apr 02 2012 - 19:40:05 PST