From: Murray S. K. <ms...@se...> - 2007-10-31 20:44:26
|
- Add dkim_getdomain() accessor function - The policy callback now takes an additional boolean parameter indicating whether or not the query to be executed should be an MX or a TXT (per draft-ietf-dkim-ssp-01) - Build-time fixes for Solaris - Build-time fixes in _FFR_ANTICIPATE_SENDMAIL_MUNGE, _FFR_SELECTOR_HEADER |
From: Chris B. <cbe...@co...> - 2007-10-31 22:03:29
|
On Wed, Oct 31, 2007 at 01:44:21PM -0700, Murray S. Kucherawy wrote: > - The policy callback now takes an additional boolean parameter indicating > whether or not the query to be executed should be an MX or a TXT > (per draft-ietf-dkim-ssp-01) After looking a bit more at this, the draft says to query MX only to see if the domain exists. It appears that libdkim is doing a bit more than that if this MX query returns NOERROR. Since an MX lookup is not going to return you any valid policy record, should: if (qstat == NOERROR) in dkim_get_policy() be: if (!use_mx && (qstat == NOERROR)) ? Imagine a domain that doesn't have a policy record (gmail.com). The current code does this: 4.4 part 2) TXT lookup _ssp._domainkey.gmail.com -- returns NXDOMAIN. 4.4 part 3) MX lookup on 'gmail.com' is done to see if MX exists -- returns NOERROR, and policy, handling are set to the defaults (p=unknown, h=process) 4.4 part 4) Immediate parent is a TLD, so algorithm terminates. susp=false, policy=unknown, handling=process are returned.. Is that correct or should policy/handling be 'none' and 'none' ? - Chris |
From: Murray S. K. <ms...@se...> - 2007-10-31 23:28:17
|
On Wed, 31 Oct 2007, Chris Behrens wrote: > After looking a bit more at this, the draft says to query MX only to > see if the domain exists. It appears that libdkim is doing a bit more > than that if this MX query returns NOERROR. Since an MX lookup is > not going to return you any valid policy record, should: > > if (qstat == NOERROR) > > in dkim_get_policy() be: > > if (!use_mx && (qstat == NOERROR)) > > ? > > Imagine a domain that doesn't have a policy record (gmail.com). > > The current code does this: > > 4.4 part 2) TXT lookup _ssp._domainkey.gmail.com -- returns NXDOMAIN. > 4.4 part 3) MX lookup on 'gmail.com' is done to see if MX exists > -- returns NOERROR, and policy, handling are set to the > defaults (p=unknown, h=process) > 4.4 part 4) Immediate parent is a TLD, so algorithm terminates. > susp=false, policy=unknown, handling=process are returned.. > > Is that correct or should policy/handling be 'none' and 'none' ? I think what you're suggesting is right only because "buf" won't contain anything useful in the MX lookup case. Done for Beta2. |
From: Chris B. <cbe...@co...> - 2007-11-01 05:31:13
|
On Wed, Oct 31, 2007 at 04:28:07PM -0700, Murray S. Kucherawy wrote: > On Wed, 31 Oct 2007, Chris Behrens wrote: [...] > > if (qstat == NOERROR) > > > > in dkim_get_policy() be: > > > > if (!use_mx && (qstat == NOERROR)) [...] > > I think what you're suggesting is right only because "buf" won't contain > anything useful in the MX lookup case. Yeah, I meant to comment on that fact. > > Done for Beta2. Thnx! - Chris |
From: Hirohisa Y. <um...@gm...> - 2007-11-01 17:23:44
|
Hi, With 2.4.0.Beta1, I found following: 1. t-test76.c is missing. 2. I could not find a knob for _FFR_PARSE_TIME in site.config.m4.dist 3. t-test75 tells that _FFR_PARSE_TIME is not yet ready to get timezone info. e.g. $ TZ=America/Phoenix ./t-test75 passes. $ TZ=America/Los_Angeles ./t-test75 fails. I attach a log Regards. -- end Hirohisa Yamaguchi um...@gm... |
From: Murray S. K. <ms...@se...> - 2007-11-01 18:01:17
|
On Fri, 2 Nov 2007, Hirohisa Yamaguchi wrote: > 1. t-test76.c is missing. Already fixed for Beta2. > 2. I could not find a knob for _FFR_PARSE_TIME in site.config.m4.dist Fixed. > 3. t-test75 tells that _FFR_PARSE_TIME is not yet ready to get timezone info. > e.g. > $ TZ=America/Phoenix ./t-test75 > passes. > $ TZ=America/Los_Angeles ./t-test75 > fails. > > I attach a log It's odd that strptime() with a format that includes timezone conversion would result in a structure that's based on local time zone rather than GMT. As near as I can tell, the "%z" (timezone in -HHMM format) conersion isn't happening but strptime() gets the rest of the conversion right. I'll investigate further but I may have to roll my own conversion function. |
From: Murray S. K. <ms...@se...> - 2007-11-01 18:11:52
|
On Thu, 1 Nov 2007, Murray S. Kucherawy wrote: > As near as I can tell, the "%z" (timezone in -HHMM format) conersion > isn't happening but strptime() gets the rest of the conversion right. > I'll investigate further but I may have to roll my own conversion > function. Ah, doing this in a portable fashion is more complicated than I thought. For now, don't use _FFR_PARSE_TIME. I'll mark it as "incomplete" in the FEATURES file. |