hubert@bogachiel.ms.washington.edu (Steve Hubert) (01/26/89)
Some time in between version 5.52 and 5.61 of sendmail there were two new lines added to deliver.c that are causing me trouble, and I don't understand why they are there. If I comment them out it seems to work correctly but I don't want to do that since I don't know why they were added. The two lines that have been added are the following two: _res.options &= ~(RES_DEFNAMES | RES_DNSRCH); /* XXX */ _res.options |= RES_DEFNAMES | RES_DNSRCH; /* XXX */ The problem that these lines are causing me is this. There is a call to getmxrr() in between the line that explicitly turns off RES_DEFNAMES (use default domain name) and RES_DNSRCH. When I get to this getmxrr() call I don't always have a fully qualified name. I might have a hostname with no domain extension at all. This ought to be fine since the host is in the same domain as the default domain. When I comment out the turning off of this resolver option it seems to work fine. By the way, I am using Bind 4.8 for name service and resolver code. Here is a specific example. Mailing from host hilbert.ms.washington.edu to user@bogachiel (which is also in the domain ms.washington.edu). The default domain on hilbert is ms.washington.edu. This results in a call to getmxrr() with an argument of bogachiel, not bogachiel.ms.washington.edu. If the DEFNAMES option is left turned on it works fine but with it commented out it fails with stat=Host unknown. So the question is, what are those two lines there for? And what does the comment /* XXX */ mean? That looks ominous, sort of like a skull and cross bones or something. Can you think of anything bad that might happen if I comment those lines out? Steve Hubert hubert@bogachiel.ms.washington.edu University of Washington
csg@pyramid.pyramid.com (Carl S. Gutekunst) (01/26/89)
In article <1201@uw-entropy.ms.washington.edu> hubert@bogachiel.ms.washington.edu (Steve Hubert) writes: >Some time in between version 5.52 and 5.61 of sendmail there were two >new lines added to deliver.c that are causing me trouble, and I don't >understand why they are there.... > > _res.options &= ~(RES_DEFNAMES | RES_DNSRCH); /* XXX */ > _res.options |= RES_DEFNAMES | RES_DNSRCH; /* XXX */ Your analysis of these is correct. Their purpose is to force the resolver to assume no default domain; i.e., your sendmail.cf must assemble a fully quali- fied domain name before you call the [IPC] mailer. This rules out the use of short local names. Karl Kleinpaste and I were debating the pros and cons of it. Karl is a domain purist, so at Ohio State his sendmail.cf always canonicalizes to FQDNs, no matter where the mail is going. So Karl didn't even notice the above lines, and if anything they are a Good Thing for him since they catch errors in the sendmail.cf. Here at Pyramid, we have lots of naive users: sales, marketing, upper manage- ment, the usual. :-) Many users don't like seeing "pyrpressure.pyramid.com" when all they were trying to do was send mail to the person at the next desk; they'd rather see the local name "pyrpressure". When that hits the resolver with the above flags turned off, the resolver notices that there is no '.' in the name, and promptly slings it back with a "no such host" error. This is particularly annoying for me, since by this time I've already checked the name against a list of known local hosts. So I commented the lines back out. Note: sendmail 5.59, which is identical to 5.61 expect for security fixes, has these lines commented out. It's what practically everyone has been running for a couple of years. So I find it difficult to believe commenting them out is catagorically wrong. I would say that anything that breaks an existing, work- ing sendmail.cf *is* catagorically wrong. And this change does do that. >So the question is, what are those two lines there for? Karl and I decided it was Keith Bostic's way of telling everyone to use FQDNs. :-) :-) :-) >And what does the comment /* XXX */ mean? That looks ominous, sort of like >a skull and cross bones or something. That is pretty close. That particular notation is even in some V7 code, and its all over in the BSD kernel. Means something that is highly questionable, or uncertain. <csg>
brian@ucsd.EDU (Brian Kantor) (01/26/89)
Go ahead and comment those lines out. Left in, they break nearly every sendmail.cf file in existance, except those which happen to live in an environment where the domain names can be easily canonicalized to their fully-qualified domain name before you call the resolver, or where users type the whole FQDN. Sendmail 5.60 had this and other brokenness in it; apparently only this remains broken in 5.61 - at least, as far as my testing has shown to this point. I'll know more after USENIX is over and I can resume testing. Brian Kantor UCSD Postmaster UCSD Office of Academic Computing (619) 534-6865 UCSD B-028, La Jolla, CA 92093 USA brian@ucsd.edu BRIAN@UCSD ucsd!brian
vixie@decwrl.dec.com (Paul A Vixie) (01/27/89)
# _res.options &= ~(RES_DEFNAMES | RES_DNSRCH); /* XXX */ # _res.options |= RES_DEFNAMES | RES_DNSRCH; /* XXX */ As others have pointed out, these are safe if you canonicalize to FQDMs before you call the resolver. Carl says that these are ugly in received mail, and I agree. But I have stuff in my Mlocal's final rewrites to rip everything out that does not need to be there -- which includes not only the domain name but the host name as well, since we have the same aliases everywhere. So I can leave this in. Others may want to consider the same approach. -- Paul Vixie Work: vixie@decwrl.dec.com decwrl!vixie +1 415 853 6600 Play: paul@vixie.sf.ca.us vixie!paul +1 415 864 7013