Milter-greylist

> I thought that might be the case, however it doesn't explain what is 
> going on with dkim_verify when it sees a dkim header.
> 
> I'll try pushing a signed message through when DKIM_NOSIG is set. I 
> suspect that dkim_verify will not change priv_dkimstat and it will 
> still end up as NOSIG.

Actually, before I do that I think I see what is wrong with dkim_verify. 
Rather, it seems to work but watch (data details obscured):

Breakpoint 1, dkimcheck_header (name=0x2884bec0 "Received", 
    value=0x2884bec9 "from hostname.domain
(hostname.domain [111.11.111.111])\n\t(authenticated 
bits=0)\n\tby another.host.com (Sendmail version/Sendmail version) with ESMTP 
id o8HFnwdZ007274\n\t(version=TLSv1/SSLv"..., 
    priv=0x288bd800) 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) p priv->priv_dkim
$1 = (DKIM *) 0x0
(gdb) p priv->priv_dkimstat
$2 = 0
(gdb) s

(added by me)

165                     syslog(LOG_NOTICE, "%p %d", priv->priv_dkim, 
priv->priv_dkimstat);
(gdb) s
166                     if (priv->priv_dkim == NULL) {
(gdb) s
175             len = strlen(name) + strlen(value) + 2;
(gdb) s
176             if ((header = malloc(len + 1)) == NULL) {
(gdb) s
182             (void)snprintf((char *)header, len, "%s: %s", name, 
value);
(gdb) s
183             priv->priv_dkimstat = dkim_header(priv->priv_dkim, 
header, len + 1);
(gdb) p priv->priv_dkim
$3 = (DKIM *) 0x28719600

OK, so there's the handle 

(gdb) p priv->priv_dkimstat
$4 = 0

Yup..

(gdb) cont
Continuing.

and here comes the next header...

Breakpoint 1, dkimcheck_header (name=0x286f53d0 "X-DKIM", 
    value=0x286f53d7 "Header Blah Blah Blah", priv=0x288bd800)
    at dkimcheck.c:152
152             if (priv->priv_dkim == NULL) {
(gdb) p priv->priv_dkim
$5 = (DKIM *) 0x0

Handle.. lost? The comments for dkimcheck_header indicate that 
priv->priv_dkim is only null if a header has not been processed before. 
So it looks like every time dkimcheck_header fires it gets a null value 
for priv->priv_dkim. Are we losing the verify handles here?

John