On 2009-07-28 at 22:26 +0200, MarkdV wrote: > Just playing, when I ran into:
>
> # exim -d+resolver -be
> > ${lookup dnsdb{txt=_spf.google.com}}
> database lookup required for txt=_spf.google.com
> dnsdb key: _spf.google.com
> DNS name syntax check failed: _spf.google.com (TXT)
> lookup failed
>
> My guess is it doesn't like the underscore to start the name/label.
>
> Which seems like a bug because as far as I know underscores are only
> illegal in hostnames. And not all _names_ in a domain name are also
> _hostnames_. The name in an SRV record being the most well-known example.
The SRV record is indeed special-cased from this, by skipping over the
first two labels.
In fact, the underscore is also forbidden in mail-domains, which is
often of more interest to Exim.
Agreed though, that it's probably a bug that TXT record lookup, or in
fact lookups for anything except A/AAAA/MX, apply the syntax checks.
You can work around it with the "dns_check_names_pattern" option.
Adjust the regexp to remove the underscore restrictions.
However, the SPF record for a domain is always associated with the
domain itself (whether TXT or SPF); the _spf.google.com record exists to
be used in things like the TXT record for gmail.com:
gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"
and if you want to handle that, you need to use the Experimental SPF
support; anything you do with checks in Exim directly will be somewhat
fragile as you case referral chains -- handling recursive references
safely in Exim's syntax would be highly awkward (as in, I wouldn't like
to write such rules).
