------- 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: [email protected] ReportedBy: [email protected] CC: [email protected] 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. o...@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 -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
