SUMMARY: wildcard MX-RR and

From: Michael N. Lipp (
Date: Sat Jun 08 1991 - 07:40:06 CDT


The original question was (shortened):

Michael> our domain is (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> "* IN MX 240 ...".

Michael> If I use, 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 in

Michael> --> matches *

Michael> Result: the mail doesn't go where it was meant to go to. The
Michael> result is even worse for mails within * If I
Michael> send mail to, the domain name
Michael> sequence is applied as above resulting in
Michael> and that is a totally
Michael> invalid address.

According to most of the responses, I could summarize by simply quoting
e.g. Matt Crawford <>

   Wildcard MX records are evil. This is a common example of why they
   are evil.

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
about MX-mailing.

First of all, the problem IS known, as can be seen from the berkeley
sources ( (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));
        # else
        n = res_search(host, C_IN, T_CNAME, (char *)&answer, sizeof(answer));
        # endif

And according to statsci! (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 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] 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)
                ELSE fail
        ELIF there is a wildcard MX record
        THEN use it
        ELSE fail

  * 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, (Mark Baranowski)
provided the following "fix":

  Wild-card MX records will cause you plenty of grief unless you fix
  the following line in


  R$*<@$*.$+>$* $#ddn $@ $2.$3 $:$1<@$2.$3>$4 user@any.domain

  to be:

  R$*<@$*.$+>$* $#ddn $@ $2.$3. $:$1<@$2.$3>$4 user@any.domain

                                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 <> (Steve D. Miller) Dale Carstensen
"Andy Wilcox" <>
statsci! (Mark Andrews)
"Matt Crawford" <> (Mark Baranowski)


Michael N. Lipp ! Institut fuer Datentechnik ! Phone: 49-6151-163776
                 ! Merckstr. 25 ,----------' Fax: 49-6151-164976
                 ! D-6100 Darmstadt ! E-Mail: (xdatmnlx@ddathd21.bitnet)
                 ! (Germany) !

This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:15 CDT