The original question was (shortened):
Michael> our domain is dtro.e-technik.th-darmstadt.de (I know it's too
Michael> long. We had no choice except for the heading dtro). Our
Michael> super-domain nameserver maintains an MX-Entry
Michael> "*.th-darmstadt.de. IN MX 240 ...".
Michael> If I use sendmail.mx, the TCP-Mailer calls the resolver
Michael> routines, which obviously use the standard resolution
Michael> sequence derived from my domain name. This results e.g. for a
Michael> mail to umiacs.umd.edu in
Michael> umiacs.umd.edu.th-darmstadt.de. --> matches *.th-darmstadt.de
Michael> Result: the mail doesn't go where it was meant to go to. The
Michael> result is even worse for mails within *.th-darmstadt.de. If I
Michael> send mail to rs1.hrz.th-darmstadt.de, the domain name
Michael> sequence is applied as above resulting in
Michael> rs1.hrz.th-darmstadt.de.th-darmstadt.de and that is a totally
Michael> invalid address.
According to most of the responses, I could summarize by simply quoting
e.g. Matt Crawford <firstname.lastname@example.org>
Wildcard MX records are evil. This is a common example of why they
And I convinced the administrator "above" to discard the wildcard
entry as soon as some entries that were supposed to be matched by that
wildcard have been made. Nevertheless, I got some useful Information
First of all, the problem IS known, as can be seen from the berkeley
sources (email@example.com (Steve D. Miller)):
* Use query type of ANY if possible (NO_WILDCARD_MX), which will
* find types CNAME, A, and MX, and will cause all existing records
* to be cached by our local server. If there is (might be) a
* wildcard MX record in the local domain or its parents that are
* searched, we can't use ANY; it would cause fully-qualified names
* to match as names in a local domain.
# ifdef NO_WILDCARD_MX
n = res_search(host, C_IN, T_ANY, (char *)&answer, sizeof(answer));
n = res_search(host, C_IN, T_CNAME, (char *)&answer, sizeof(answer));
And according to firstname.lastname@example.org (Mark Andrews):
What Sun did was compile sendmail with NO_MX_WILDCARD defined.
You can get around the problem two (three with your sol'n) ways.
1. Ask Sun for a sendmail.mx that is NOT compiled with
NO_MX_WILDCARD. They do have such a beast accordind to
Sun Australia, I didn't get it as I was able to get rid
of the offending wild card.
2. On the deliver line (only) append a dot after the host in the
$@ part of the ruleset. You don't need is when doing
$[ $] matching as sendmail does NOT attempt to expand
the name only to do CNAME conversions. [see below. mnl]
Piete.Brooks@cl.cam.ac.uk cleared things up by providing the algorithm
used to expand wildcards:
* Wildcard MX records DON'T do what most people expect.
* The general rule is, don't use them !
* The Alogirithm is:
IF there is ANY sort of RR for the machine
THEN IF there is an MX for it
THEN use those in order
ELIF there is a A record (or records)
THEN use it (/them)
ELIF there is a wildcard MX record
THEN use it
* So ANY sort of RR takes precidence over a wildcard MX record.
* The above means that if the host is NOT registerted, then it will be routed
* as you want.
* If it IS registered (which I assume all your hosts are) the MX record
* will be ignored.
And finally, if someone can't get rid of a wildcard for lack of authority
for the upper domain, email@example.com (Mark Baranowski)
provided the following "fix":
Wild-card MX records will cause you plenty of grief unless you fix
the following line in sendmail.main.cf:
R$*<@$*.$+>$* $#ddn $@ $2.$3 $:$1<@$2.$3>$4 firstname.lastname@example.org
R$*<@$*.$+>$* $#ddn $@ $2.$3. $:$1<@$2.$3>$4 email@example.com
Notice the dot.
The dot stops the resolver from trying to stick all MX'ed hosts inside your
domain. Someone at Sun should get a clue!
I thank everyone who took the trouble to respond:
Lutz Brunke <firstname.lastname@example.org>
email@example.com (Steve D. Miller)
firstname.lastname@example.org Dale Carstensen
"Andy Wilcox" <email@example.com>
firstname.lastname@example.org (Mark Andrews)
"Matt Crawford" <email@example.com>
firstname.lastname@example.org (Mark Baranowski)
Michael N. Lipp ! Institut fuer Datentechnik ! Phone: 49-6151-163776
! Merckstr. 25 ,----------' Fax: 49-6151-164976
! D-6100 Darmstadt ! E-Mail: (email@example.com)
! (Germany) ! firstname.lastname@example.org
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:15 CDT