In playing around with opendkim today, I've discovered that it incorrectly
caches the results of the LDAP queries. The whole point of using LDAP is
to get live results. Is there some way to disable this broken behavior?
Here's an example. On my first email, I did not have the DKIMIdentity
value correct in LDAP, so opendkim got on results back. You can see it
correctly queries LDAP:
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=2 SRCH base=""
scope=2 deref=0 filter="(DKIMIdentity=testuser1_at_zre-ldap002.eng.vmware.com)"
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=2 SRCH
attr=DKIMSelector
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=2 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=3 SRCH base=""
scope=2 deref=0 filter="(DKIMIdentity=zre-ldap002.eng.vmware.com)"
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=3 SRCH
attr=DKIMSelector
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=3 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=4 SRCH base=""
scope=2 deref=0 filter="(DKIMIdentity=testuser1_at_.eng.vmware.com)"
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=4 SRCH
attr=DKIMSelector
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=4 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=5 SRCH base=""
scope=2 deref=0 filter="(DKIMIdentity=.eng.vmware.com)"
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=5 SRCH
attr=DKIMSelector
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=5 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=6 SRCH base=""
scope=2 deref=0 filter="(DKIMIdentity=testuser1_at_.vmware.com)"
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=6 SRCH
attr=DKIMSelector
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=6 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=7 SRCH base=""
scope=2 deref=0 filter="(DKIMIdentity=.vmware.com)"
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=7 SRCH
attr=DKIMSelector
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=7 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=8 SRCH base=""
scope=2 deref=0 filter="(DKIMIdentity=testuser1_at_.com)"
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=8 SRCH
attr=DKIMSelector
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=8 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=9 SRCH base=""
scope=2 deref=0 filter="(DKIMIdentity=.com)"
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=9 SRCH
attr=DKIMSelector
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=9 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=10 SRCH base=""
scope=2 deref=0 filter="(DKIMIdentity=testuser1_at_\2A)"
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=10 SRCH
attr=DKIMSelector
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=10 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=11 SRCH base=""
scope=2 deref=0 filter="(DKIMIdentity=\2A)"
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=11 SRCH
attr=DKIMSelector
May 3 18:07:37 zre-ldap002 slapd[30673]: conn=1605 op=11 SEARCH RESULT
tag=101 err=0 nentries=0 text=
May 3 18:07:37 zre-ldap002 opendkim[10149]: CA83A242BC8: no signing table
match for 'testuser1_at_zre-ldap002.eng.vmware.com'
On my second email, after I've fixed this issue, opendkim doesn't even
bother to check LDAP:
May 3 18:11:06 zre-ldap002 opendkim[10149]: 182C6242BC8: no signing table
match for 'testuser1_at_zre-ldap002.eng.vmware.com'
i.e., if using an LDAP table, LDAP should always be consulted, regardless
of what the previous result was.
Thanks,
Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
Received on Fri May 04 2012 - 01:16:37 PST