Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!TRANSARC.COM!Craig_Everhart
From: Craig_Everhart@TRANSARC.COM
Newsgroups: comp.mail.sendmail
Subject: Re: sendmail resolver options
Message-ID: <Ub0q1ur0BwwOAOznsx@transarc.com>
Date: 28 Sep 90 14:38:50 GMT
References: <1990Sep27.201736.4938@turnkey.tcc.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 37

It can really screw up if the name *is* fully-qualified in the presence
of wildcarded MX records.  Thus, sending mail to foo@encore.com, in the
presence of a local wildcard for *.tcc.com, you might wind up sending
mail to ``foo@encore.com.tcc.com'' via whatever your local MX target is.

You can really divide the world into two classes, and maybe sendmail
should do this by some config option.
  - class A: no ``default'' domain used by the resolver defines any
wildcard records (MX or otherwise;
  - class B: at least one of the ``default'' domains used by the
resolver defines a wildcard record.
Thus, if you have the ordinary tree-walk default domains on, a lookup
from foo.turnkey.tcc.com will use default domains ``turnkey.tcc.com''
and ``tcc.com''.  If either of these has any wildcard records, you're in
class B; else, in class A.

Now, in class B, you have to avoid stumbling on these wildcards when you
have a fully-qualified name already.  Classically, the wildcards are for
the MX attribute, so that's why sendmail here turns off the resolver's
search.  This indeed means you don't get that defaulting even when you
want it, but it keeps sendmail from creating long non-existent domains
via the wildcard.

In class A, you don't need sendmail to turn off the resolver's search.

Note that you should probably save, disable, and restore the searching
when you encounter a CNAME record and look up its value as a new name,
but that's not directly relevant here.

Do newer sendmail versions have some option to enable or disable this? 
It seems well-nigh impossible for sendmail to determine, dynamically,
whether it's operating in a class-A or class-B environment, given the
gazillions of possibilities for the set of ``default domains'' used by
the resolver's search algorithm (for whatever version of the resolver it
happens to be linked with).

		Craig