Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Message

Re: [milter-greylist] DKIM and ACL syntax

2010-09-17 by John Wood

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). 

John

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.