On 29 June 2010 14:52, Naresh V <nareshov_at_gmail.com> wrote:
> On 29 June 2010 14:34, Naresh V <nareshov_at_gmail.com> wrote:
>> On 29 June 2010 14:29, Naresh V <nareshov_at_gmail.com> wrote:
>>> On 29 June 2010 09:57, Naresh V <nareshov_at_gmail.com> wrote:
>>>> On 29 June 2010 01:52, Murray S. Kucherawy <msk_at_blackops.org> wrote:
>>>>> On Tue, 29 Jun 2010, Naresh V wrote:
>>>>>>
>>>>>> Jun 29 00:16:44 staging opendkim[16994]: 00A174B022B error reading signing
>>>>>> table
>>>>>
>>>>> I think I see a logic issue that might be causing this. Try this and let me
>>>>> know what it says, which will hopefully confirm my theory:
>>>>>
>>>>> 1) ./opendkim -Q
>>>>>
>>>>> 2) You will be prompted for a data set name; paste your SigningTable
>>>>> definition, "dsn:pgsql:..."
>>>>>
>>>>> 3) Enter "naresh.ve_at_example.com/1"
>>>>>
>>>>> 4) Paste the result.
>>>>>
>>>>> 5) Enter "example.com/1"
>>>>>
>>>>> 6) Paste the result.
>>>>>
>>>>
>>>> Here it is:
>>>>
>>>> [root_at_staging opendkim-2.1.1]# opendkim -Q
>>>> opendkim: enter data set description
>>>> csl:entry1[,entry2[,...]]
>>>> file:path
>>>> refile:path
>>>> db:path
>>>> dsn:<backend>://[user[:pwd]_at_][port+]host/dbase[/key=val[?...]]
>>>> lua:path
>>>>> dsn:pgsql://opendkim_at_localhost/odkim/table=signingtable?keycol=fromheader?datacol=keyname
>>>> opendkim: enter `query/n' where `n' is number of fields to request
>>>>> naresh.ve_at_example.com/1
>>>> opendkim: dkimf_db_get(): record not found
>>>> opendkim: enter `query/n' where `n' is number of fields to request
>>>>> example.com/1
>>>> opendkim: dkimf_db_get() returned -1
>>>> opendkim: enter `query/n' where `n' is number of fields to request
>>>>> quit
>>>> opendkim: invalid query `quit'
>>>>
>>>
>>> I ran the milter-daemon and sent a test mail again, I still get the
>>> error reading signingtable though - but I see:
>>>
>>> Jun 29 14:23:52 staging postgres[445]: [2-1] LOG: statement: SELECT
>>> keyname FROM signingtable WHERE fromheader = 'naresh.ve_at_example.com'
>>>
>>> in the postgres logs (I enabled log-to-syslog for postgres)
>>>
>>> And then, I opened a -Q session as asked above (with -u opendkim too)
>>> and got the same results as above with the following corresponding
>>> postgresql logs:
>>>
>>> Jun 29 14:28:17 staging postgres[494]: [2-1] LOG: statement: SELECT
>>> keyname FROM signingtable WHERE fromheader = 'naresh.ve_at_example.com'
>>>
>>> (same thing: no corresponding statement log for "WHERE fromheader =
>>> 'example.com'")
>>>
>>
>> Isn't the milter-daemon supposed to query example.com if it doesn't
>> find an entry for naresh.ve_at_example.com?
>>
>> (as mentioned in http://www.opendkim.org/opendkim.conf.5.html
>> (SigningTable section):
>> For all other database types, the full user_at_host is checked first,
>> then simply host, then user_at_.domain (with all superdomains checked in
>> sequence, so "foo.example.com" would first check
>> "user_at_foo.example.com", then "user@.example.com", then "user@.com"),
>> then .domain, then user_at_*, and finally *.)
>>
>
> In a opendkim -Q session, querying 'example.com/1' first (and not
> 'naresh.ve_at_example.com/1') returns the datacol that's present in the
> actual table. And subsequent queries error out.
>
>
> [root_at_staging ~]# opendkim -Q -u opendkim
> opendkim: enter data set description
> csl:entry1[,entry2[,...]]
> file:path
> refile:path
> db:path
> dsn:<backend>://[user[:pwd]_at_][port+]host/dbase[/key=val[?...]]
> lua:path
>> dsn:pgsql://opendkim_at_localhost/odkim/table=signingtable?keycol=fromheader?datacol=keyname
> opendkim: enter `query/n' where `n' is number of fields to request
>> example.com/1
> `example'
> opendkim: enter `query/n' where `n' is number of fields to request
>> naresh.ve_at_example.com/1
> opendkim: dkimf_db_get() returned -1
> opendkim: enter `query/n' where `n' is number of fields to request
>> example.com/1
> opendkim: dkimf_db_get() returned -1
> opendkim: enter `query/n' where `n' is number of fields to request
>>
>
> Corresponding postgresql statement logs:
>
> Jun 29 14:45:30 staging postgres[717]: [2-1] LOG: statement: SELECT
> keyname FROM signingtable WHERE fromheader = 'naresh.ve_at_example.com'
> Jun 29 14:49:39 staging postgres[755]: [2-1] LOG: statement: SELECT
> keyname FROM signingtable WHERE fromheader = 'example.com'
> Jun 29 14:51:48 staging postgres[799]: [2-1] LOG: statement: SELECT
> keyname FROM signingtable WHERE fromheader = 'example.com'
>
> (
> [root_at_staging ~]# ps faux | grep dkim
> root 798 0.0 0.3 55840 1792 pts/2 S+ 14:51 0:00 |
> \_ opendkim -Q -u opendkim
> root 810 0.0 0.1 61132 716 pts/3 S+ 14:53 0:00 |
> \_ grep dkim
> postgres 717 0.0 0.7 155800 4080 ? Ss 14:45 0:00 \_
> postgres: opendkim odkim 127.0.0.1(54345) idle
> postgres 718 0.0 0.5 155416 2684 ? Ss 14:45 0:00 \_
> postgres: opendkim odkim 127.0.0.1(54346) idle
> postgres 799 0.0 0.8 155800 4088 ? Ss 14:51 0:00 \_
> postgres: opendkim odkim 127.0.0.1(55900) idle
> opendkim 719 0.0 0.4 86836 2076 ? Ssl 14:45 0:00
> /usr/sbin/opendkim -x /etc/opendkim.conf -u opendkim
> )
>
Hi again,
A colleague and I jumped around a bit with in the code:
http://pastie.org/1023515
On an initial hunch that a query for "example.com" isn't being made
after an unsuccessful query for "naresh.ve_at_example.com", we made the
above changes to track things in the logs:
http://pastie.org/1023517
opendkim doesn't seem to log the second "recursive query" (lookup
example.com on not finding an entry for naresh.ve_at_example.com) whereas
it seems to log both with postgresql.
Received on Tue Jun 29 2010 - 15:37:25 PST