On 2010-02-26 at 20:10 +0100, Sven Hartge wrote: > 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.
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. Tom, thoughts? -Phil -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
