jackv@turnkey.tcc.com (Jack F. Vogel) (09/28/90)
I have a question that I hope someone out there might enlighten me on. In the 5.61 as well as 5.64 code deliver.c just before it calls the routine getmxrr() it is setting the resolver options as follows: _res.options &= ~(RES_DEFNAMES | RES_DNSRCH) /* XXX */ Notice the illuminating comment :-}. My question is why one would want to do this, it means that the default domain name is not appended to a fully unqualified hostname, nor is a search performed. I would think one WOULD want these options on, is there something I am missing here?? Any ideas welcome. -- Jack F. Vogel jackv@locus.com AIX370 Technical Support - or - Locus Computing Corp. jackv@turnkey.TCC.COM
rickert@mp.cs.niu.edu (Neil Rickert) (09/28/90)
In article <1990Sep27.201736.4938@turnkey.tcc.com> jackv@turnkey.TCC.COM (Jack F. Vogel) writes: > >I have a question that I hope someone out there might enlighten me on. >In the 5.61 as well as 5.64 code deliver.c just before it calls the >routine getmxrr() it is setting the resolver options as follows: > > _res.options &= ~(RES_DEFNAMES | RES_DNSRCH) /* XXX */ > >Notice the illuminating comment :-}. My question is why one would >want to do this, it means that the default domain name is not appended >to a fully unqualified hostname, nor is a search performed. I would >think one WOULD want these options on, is there something I am missing >here?? Firstly most versions of 'sendmail.cf' have already processed the host name with the $[ ... $] which should have fully qualified it already. ---- Secondly, assume my default domain is CS.NIU.EDU Assume, moreover, that there is an MX record in the domain server data base: * IN MX 0 some.host.somewhere. Now suppose I am mailing to 'jackv@turnkey.tcc.com'. If that statement is not present in deliver.c, the resolver tries qualifying in the domain:- turnkey.tcc.com.cs.niu.edu Bingo. It matches the MX wildcard record. The mail is successfully delivered to the wrong place. Not a real good idea. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
Craig_Everhart@TRANSARC.COM (09/28/90)
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