Re: Help with pgsql dataset for SigningTable and KeyTable

From: Naresh V <nareshov_at_gmail.com>
Date: Tue, 29 Jun 2010 21:01:21 +0530

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

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:19:47 PST