The introduction of DKIM added _ to the permitted chars, so those components will pass.
.cindex "UTF-8" "in domain name"
Lots of discussion is going on about internationalized domain names. One
camp is strongly in favour of just using UTF-8 characters, and it seems
.cindex "UTF-8" "in domain name"
Lots of discussion is going on about internationalized domain names. One
camp is strongly in favour of just using UTF-8 characters, and it seems
-that at least two other MTAs permit this. This option allows Exim users to
-experiment if they wish.
+that at least two other MTAs permit this.
+This option allows Exim users to experiment if they wish.
If it is set true, Exim's domain parsing function allows valid
UTF-8 multicharacters to appear in domain name components, in addition to
If it is set true, Exim's domain parsing function allows valid
UTF-8 multicharacters to appear in domain name components, in addition to
-letters, digits, and hyphens. However, just setting this option is not
-enough; if you want to look up these domain names in the DNS, you must also
+letters, digits, and hyphens.
+
+.new
+If Exim is built with internationalization support
+and the SMTPUTF8 ESMTP option is in use (see chapter &<<CHAPi18n>>&)
+this option can be left as default.
+.wen
+Without that,
+if you want to look up such domain names in the DNS, you must also
adjust the value of &%dns_check_names_pattern%& to match the extended form. A
suitable setting is:
.code
adjust the value of &%dns_check_names_pattern%& to match the extended form. A
suitable setting is:
.code
This test is omitted for PTR records. These occur only in calls from the dnsdb
lookup, which constructs the names itself, so they should be OK. Besides,
This test is omitted for PTR records. These occur only in calls from the dnsdb
lookup, which constructs the names itself, so they should be OK. Besides,
-bitstring labels don't conform to normal name syntax. (But the aren't used any
-more.)
-
-For SRV records, we omit the initial _smtp._tcp. components at the start.
-The check has been seen to bite on the destination of a SRV lookup that
-initiall hit a CNAME, for which the next name had only two components.
-RFC2782 makes no mention of the possibiility of CNAMES, but the Wikipedia
-article on SRV says they are not a valid configuration. */
+bitstring labels don't conform to normal name syntax. (But they aren't used any
+more.) */
#ifndef STAND_ALONE /* Omit this for stand-alone tests */
if (check_dns_names_pattern[0] != 0 && type != T_PTR && type != T_TXT)
{
#ifndef STAND_ALONE /* Omit this for stand-alone tests */
if (check_dns_names_pattern[0] != 0 && type != T_PTR && type != T_TXT)
{
- const uschar *checkname = name;
int ovector[3*(EXPAND_MAXN+1)];
dns_pattern_init();
int ovector[3*(EXPAND_MAXN+1)];
dns_pattern_init();
-
- /* For an SRV lookup, skip over the first two components (the service and
- protocol names, which both start with an underscore). */
-
- if (type == T_SRV || type == T_TLSA)
- {
- while (*checkname && *checkname++ != '.') ;
- while (*checkname && *checkname++ != '.') ;
- }
-
- if (pcre_exec(regex_check_dns_names, NULL, CCS checkname, Ustrlen(checkname),
+ if (pcre_exec(regex_check_dns_names, NULL, CCS name, Ustrlen(name),
0, PCRE_EOPT, ovector, nelem(ovector)) < 0)
{
DEBUG(D_dns)
0, PCRE_EOPT, ovector, nelem(ovector)) < 0)
{
DEBUG(D_dns)