------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=967
Summary: DKIM-mandated undocumented behaviour change
Product: Exim
Version: 4.71
Platform: All
OS/Version: All
Status: NEW
Severity: bug
Priority: medium
Component: Lookups
AssignedTo: nigel@???
ReportedBy: sven@???
CC: exim-dev@???
I use the following lookup to determine the ASN of an IP:
warn
set acl_c2 = ${extract{1}{\n}{${lookup
dnsdb{txt=${extract{4}{.}{$sender_host_address}}.${extract{3}{.}{$sender_host_address}}.${extract{2}{.}{$sender_host_address}}.${extract{1}{.}{$sender_host_address}}.asn.fh-giessen.de}}}}
log_message = ASN-LOOKUP: ${lookup
dnsdb{${extract{4}{.}{$sender_host_address}}.${extract{3}{.}{$sender_host_address}}.${extract{2}{.}{$sender_host_address}}.${extract{1}{.}{$sender_host_address}}.asn.fh-giessen.de}}
This so far worked fine, but since 4.71, the returned result is different
than before:
2010-02-26 19:31:48 H=[186.63.14.189] Warning: ASN-LOOKUP: 22927186.60.0.014
In 4.69 this would look more like this:
2010-02-26 19:31:48 H=[186.63.14.189] Warning: ASN-LOOKUP: 22927
The lookup from the command line returns three results which in 4.69 were
concatenated with \n.
oweh@skuld:~$ host -t txt 189.14.63.186.asn.fh-giessen.de
189.14.63.186.asn.fh-giessen.de descriptive text "22927" "186.60.0.0" "14"
I suspect the merge of the DKIM code in
f62bfb6fe50ab4abd1bba9eff5c458316d5322e5 to have created the problem, but
I am not fluent enough in C and the exim codebase to be able to debug or
fix it myself.
Phil Pennock added:
I think you're right as to the cause.
There's a bit of a problem here, in that the semantics demanded by DKIM
differ from what Exim did before.
RFC 4871:
----------------------------8< cut here >8------------------------------
3.6.2.2. Resource Record Types for Key Storage
[...]
Strings in a TXT RR MUST be concatenated together before use with no
intervening whitespace. TXT RRs MUST be unique for a particular
selector name; that is, if there are multiple records in an RRset,
the results are undefined.
----------------------------8< cut here >8------------------------------
However, if memory serves there is no DNS-level mandate that all TXT
strings always be interpreted this way. Some DNS client specifications,
such as SPF and DKIM, mandate this behaviour but it's in no way inherent
to DNS TXT records themselves. Tony Finch might correct me if I'm wrong
here.
So the new behaviour is correct for DKIM and sometimes correct for other
other protocols, but not correct for the general case and as such is a
regression.
Perhaps the best solution is to add a new pseudo search type for dnsdb,
just as there's "csa", "mxh" and "zns". Call the new one "txtconcat".
Revert to the previous behaviour for "txt", have dnsdb use txtconcat.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
