obh@ulrik.uio.no (Ole Bj|rn Hessen) (07/03/90)
In deliver.c, the following code is found:
/*
** Call the mailer.
*/
if (ctladdr == NULL)
ctladdr = &e->e_from;
#ifdef NAMED_BIND
_res.options &= ~(RES_DEFNAMES | RES_DNSRCH); /* XXX */
#endif
The resolver options says that gethostbyname should not try to search
for hostname in local domain or parent domain, neither append local
domain if host is a single-component name.
The context of the code implies that the macro $[ host $] doesn't
expand to host.local-domain while rewriting sender addresses.
Since this code only executes while delivering a letter, you
may get a bit surprised and baffled by this inconsistency between
mail delivery mode and sendmail test mode (-bt).
Anybody care to comment on the reality on this code?? Any why there's
a lot of 'XXX's :-) Are people depending on this code?? I didn't really
like this code, so I commented it out.
Ole Bjorn.
obh@gollum.uio.noandy@jhunix.HCF.JHU.EDU (Andy S Poling) (07/07/90)
In article <1990Jul3.020637.28385@ulrik.uio.no> obh@ulrik.uio.no (Ole Bj|rn Hessen) writes: >In deliver.c, the following code is found: > > /* > ** Call the mailer. > */ > > if (ctladdr == NULL) > ctladdr = &e->e_from; >#ifdef NAMED_BIND > _res.options &= ~(RES_DEFNAMES | RES_DNSRCH); /* XXX */ >#endif > >The resolver options says that gethostbyname should not try to search >for hostname in local domain or parent domain, neither append local >domain if host is a single-component name. > >The context of the code implies that the macro $[ host $] doesn't >expand to host.local-domain while rewriting sender addresses. Actually, this code has nothing to do with the $[...$] macro. That's taken care of elsewhere. >Since this code only executes while delivering a letter, you >may get a bit surprised and baffled by this inconsistency between >mail delivery mode and sendmail test mode (-bt). > >Anybody care to comment on the reality on this code?? Any why there's >a lot of 'XXX's :-) Are people depending on this code?? I didn't really >like this code, so I commented it out. I think I know why this was done. First let's assume that you've handed deliver() an FQDN - which you should have by using the $[...$] macro somewhere in your sendmail.cf. If that's true, then there's no need to go tacking on additional domain names when trying to get MX's and their addresses. In fact, it's potentially possible to get the wrong information if you use RES_DEFNAMES | RES_DNSRCH and you happen to have local subdomains with certain names. At best, you're going to cause extra, useless queries to your neighborhood nameserver by commenting out that line. -Andy -- Andy Poling Internet: andy@gollum.hcf.jhu.edu Network Services Group Bitnet: ANDY@JHUNIX Homewood Academic Computing Voice: (301)338-8096 Johns Hopkins University UUCP: uunet!mimsy!aplcen!jhunix!andy
jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) (07/10/90)
In article <1990Jul3.020637.28385@ulrik.uio.no> obh@ulrik.uio.no (Ole Bj|rn Hessen) writes: >In deliver.c, the following code is found: >... >#ifdef NAMED_BIND > _res.options &= ~(RES_DEFNAMES | RES_DNSRCH); /* XXX */ >#endif > >The resolver options says that gethostbyname should not try to search >for hostname in local domain or parent domain, neither append local >domain if host is a single-component name. I figured it's because it assumes the nameserver will do the parent search for the resolver via recursion, so we shouldn't bother with it. As for appending the local domain name, is it assuming that either the nameserver or the config file will supply it? >The context of the code implies that the macro $[ host $] doesn't >expand to host.local-domain while rewriting sender addresses. > >Since this code only executes while delivering a letter, you >may get a bit surprised and baffled by this inconsistency between >mail delivery mode and sendmail test mode (-bt). There definitely may be a difference in behavior between the parsing canonicalization and the delivery hostname lookup. I don't see why the flags shouldn't be disabled throughout execution, and just let the nameserver handle the whole thing in all cases. >Anybody care to comment on the reality on this code?? Any why there's >a lot of 'XXX's :-) Ditto. (Are you out there Eric?) ------------------------------------------------------------------------------- Peter Jeffe ...uunet!cs.utexas.edu!ibmchs!auschs!sandino.austin.ibm.com!jeffe first they want a disclaimer, then they make you pee in a jar, then they come for you in the night
obh@ulrik.uio.no (Ole Bj|rn Hessen) (07/10/90)
|> excerpt from deliver.c, nameserver code, search for XXX >Actually, this code has nothing to do with the $[...$] macro. That's taken >care of elsewhere. Yes, I know. Perhaps my english is confusing? What I meant was that _res.option is a global variable and thereby affects the expansion of the $[ $] macro. The header is expanded in the smtpdata routine while this option is set, and that is not what I think it should be like. >I think I know why this was done. First let's assume that you've handed >deliver() an FQDN - which you should have by using the $[...$] macro >somewhere in your sendmail.cf. If that's true, then there's no need to go >tacking on additional domain names when trying to get MX's and their >addresses. Right, this option should not be set when sendmail looks up MX records. Neither when sendmail tries to open connections to recipient host. For reasons of consistency, I think that sendmail should revert to default behaviour immediately after the connection has been confirmed. I suggest it should be reset after smtpinit in deliver.c Ole Bjorn. message(Arpa_Info, "Connecting to %s (%s)...", MxHosts[0], m->m_name); if ((rcode = smtpinit(m, pv)) == EX_OK) { register char *t = tobuf; register int i; #ifdef NAMED_BIND _res.options |= RES_DEFNAMES | RES_DNSRCH; /* XXX */ #endif /* NAMED_BIND */ /* send the recipient list */
paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) (07/11/90)
jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) writes:
(text deleted)
Speaking of inconsistencies, I get NXDOMAIN when querying for austin.ibm.com.
I suppose it's appropriate that folks who use bogus domain names can't
receive mail.
/pbp
--
Paul Pomes
UUCP: {att,iuvax,uunet}!uiucuxc!paul Internet, BITNET: paul@uxc.cso.uiuc.edu
US Mail: UofIllinois, CSO, 1304 W Springfield Ave, Urbana, IL 61801-2987jf@ap.co.umist.ac.uk (John Forrest) (07/11/90)
I'm not sure what all the fuss about this is. We havn't imported v5.64 yet - we use 5.61 - but the same code regarding resolver options being turned off was in 5.61, so it is hardly a change. John Forrest, Dept. of Computation, UMIST. PS. I had to change the 5.61 code to get it to work in our environment (we run the nameserver, but just on our workstation cluster, since we don't have TCP access to the outside world). To be compatable in the UK, we had to be able to resolve something like cs.notts to cs.notts.ac.uk, even though we only know about notts.ac.uk and I've no idea if cs.notts.ac.uk is valid. We then had to decide to send it to somewhere that knows about ac.uk (or notts.ac.uk). Wildcard MX'ing did not fullfil this criterea - well it's sort of all or nothing, since we had many such problems, so I ammended sendmail to do it. Perhaps I should register the changes (they are all dependent on #define options)? But I'm not sure how to do it!
fletcher@cs.utexas.edu (Fletcher Mattox) (07/12/90)
paul@uxc.cso.uiuc.edu (Paul Pomes - UofIllinois CSO) writes: >jeffe@sandino.austin.ibm.com (Peter Jeffe 512.823.4091) writes: > >(text deleted) > >Speaking of inconsistencies, I get NXDOMAIN when querying for austin.ibm.com. >I suppose it's appropriate that folks who use bogus domain names can't >receive mail. My offers to provide mail forwarding on cs.utexas.edu have consistently gone unanswered. So I'll repeat that offer here. If anyone at IBM can be bothered to register the domain (and I can help with that too, if you want), I'll be more than happy to provide mail forwarding. Just drop me a note. Please. I'm sooo tired of explaining to folks why their mail to austin.ibm.com fails. Fletcher
gmp@rayssd.ssd.ray.com (Gregory M. Paris) (07/13/90)
Please note the quoted text below in reference to the following line from sendmail's deliver.c. /* _res.options |= RES_DEFNAMES | RES_DNSRCH; /* XXX */ In article <1990Jul10.151028.20873@ulrik.uio.no> obh@ulrik.uio.no (Ole Bj|rn Hessen) writes: > _res.option is a global variable and thereby affects the expansion of the > $[ $] macro. The header is expanded in the smtpdata routine while this option ... > >somewhere in your sendmail.cf. If that's true, then there's no need to go > >tacking on additional domain names when trying to get MX's and their > >addresses. ... > Right, this option should not be set when sendmail looks up MX records. > Neither when sendmail tries to open connections to recipient host. I think it's overkill to turn of RES_DEFNAMES and RES_DNSRCH to avoid silly MX lookups. I commented out the above code and instead added a single line change to getmxrr which tacks a dot onto each MX hostname. This solution avoids affecting $[$] by turning off two _res.options and also keeps the resolver from tacking stuff onto the end of MX host names. I've been using this change for a couple months now and it works just fine. -- Greg Paris <gmp@quahog.ssd.ray.com> {uiucdcs,uunet}!rayssd!gmp Princess Di is wearing a new dress.