Alright, I *think* I've made some progress.
> In dkimcheck_validate(), shoudn't this:
>
> stat = ad ? *(enum spf_status *)ad : MGSPF_PASS;
>
> Be in fact something more like this (not tested, not even built)
>
> stat = ad ? ad->dkim_status : MGSPF_PASS;
>
> And same problem in acl_print_dkim(). Of couse, ad being an union, it
> should not makeany difference, but how knows how the compiler builds it?
Adjusting those appears to have made the strlen I reported earlier sane
at both points. However, stepping through dkimcheck_validate shows me
that:
Breakpoint 1, dkimcheck_validate (ad=0x28512318, stage=AS_DATA,
ap=0xbf5f98b8, priv=0x286acd00) at dkimcheck.c:249
249 result = (priv->priv_dkimstat == DKIM_STAT_OK);
(gdb) s
250 break;
(gdb) p ad->dkim_status
$7 = MGSPF_PASS
(gdb) p priv->priv_dkimstat
$8 = 0
(gdb) p priv->priv_dkim
$9 = (DKIM *) 0x0
on a message without a signature. priv_dkim|dkimstat are correct 0/NULL
(as there is no header that is a signature that validates), but this
(dkimcheck.c ~ 248ish)
switch (stat) {
case MGSPF_PASS:
result = (priv->priv_dkimstat == DKIM_STAT_OK);
break;
is always the final destination. I'm wondering if milter-greylist.c's
#ifdef USE_DKIM
priv->priv_dkim = NULL;
priv->priv_dkimstat = DKIM_STAT_OK;
is passing all the way through unmodified. Indeed, if I set:
#ifdef USE_DKIM
priv->priv_dkim = NULL;
priv->priv_dkimstat = DKIM_STAT_NOSIG
that is exactly what happens (I get a NOSIG match in greylist.conf). So
the ACL not matching is not a bug, it works just fine. What appears to
be the problem is that our two friends priv_dim and priv_dkimstat are
never populated with the results from the results of dkim_verify (or the
results from the call are erroneously 0), so they remain the default
all the way through. Breaking at the various dkimstat_* shows them never
changing from NULL|a pointer and 0.
So, when there is no signature and priv_dkim is NULL,
dkimcheck_eom's line:
priv->priv_dkimstat = dkim_eom(priv->priv_dkim, &testkey);
is never called (which is correct). However, NOSIG is never set or
returned at any point. On mail with a signature the same thing happens.
We see it hit dkimcheck_eom, but being null it gets to the above line.
So, dkimcheck_header's line:
priv->priv_dkim = dkim_verify(dkim_ptr, priv->priv_queueid,
NULL, &priv->priv_dkimstat);
is what I think is failing. I pushed through mail with a faulty
signature to see.
Breakpoint 1, dkimcheck_header (name=0x2882c380 "DKIM-Signature",
value=0x2882c38f
"v=1;a=rsa-sha256;c=relaxed/relaxed;d=gmail.com;s=gamma;h=domainkey-signature:mime-version:received:received:in-reply-to:references:date:message-id:subject:from:to:content-type:content-transfer-encodin"...,
priv=0x288c0700) at dkimcheck.c:152
152 if (priv->priv_dkim == NULL) {
(gdb) s
160 if (priv->priv_dkimstat != DKIM_STAT_OK)
(gdb) s
163 priv->priv_dkim = dkim_verify(dkim_ptr,
priv->priv_queueid,
(gdb) s
165 syslog(LOG_NOTICE, "%p %d", priv->priv_dkim,
priv->priv_dkimstat);
(gdb) p priv->priv_dkim
$3 = (DKIM *) 0x28643600
(gdb) p priv->priv_dkimstat
$4 = 0
This is probably why checking dkimcheck_* never showed anything but NULL
(or a pointer) and 0 (OK).
JohnMessage
Re: [milter-greylist] DKIM and ACL syntax
2010-09-17 by John Wood
Attachments
- No local attachments were found for this message.