Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!sdd.hp.com!elroy.jpl.nasa.gov!ames!uhccux!munnari.oz.au!mel.dit.csiro.au!smart From: smart@mel.dit.csiro.au (Robert Smart) Newsgroups: comp.mail.sendmail Subject: Re: $h in IPC mailer line: meaning/use Message-ID: <1990Jul14.092440.7797@mel.dit.csiro.au> Date: 14 Jul 90 09:24:40 GMT References: <1990Jul12.040301.21074@mel.dit.csiro.au> <1990Jul12.114200.2911@cns.umist.ac.uk> Organization: CSIRO DIT (Melb.) Lines: 121 In article <1990Jul12.114200.2911@cns.umist.ac.uk> jf@ap.co.umist.ac.uk (John Forrest) writes: >|> >|> I would like to change deliver.c so that it >|> will only use MX records if there is no $h parameter. If there is a $h >|> parameter it will ignore the MXes and send the mail where I specify. > >I'm not sure the point of this, except for the feeling of power! Surely if >you want to relay through another node, you can change the .cf files >so that it does so explicitly in Rule 0. Thanks for the question. I would hate to have had to follow up my own followup. As I read the code you can't _force_ it to relay through another host: it will check the MX of the host and use that destination. There are several applications for being able to force the destination: (1) An MX is wrong. In Australia many destinations have MX records that the owner does not know about, and so does not try to make optimal. The most interesting case is where the MX points to me but I want to forward by TCP/IP. This will be because I used to be the right destination because I'd forward by X.25. It saves me money to start forwarding by TCP/IP asap, though the destination and the owner of the nameserver don't feel any urgency. (2) We have a machine that used to be our main machine but now most of our users are on another. I would like to have the MX for the old machine point to the new, so that most mail can be intercepted and delivered locally. This means that mail can continue to be delivered to those users even when the old machine goes down for a while. But I still have to get some mail on to the old machine, over-riding the MX. (3) It is a good idea to set up your gateway router so that outside calls to port 25 only come in to a few machines. This limits the number of machines for which you have to be very careful about bugs in your e-mail software. Consider a machine that is not accessable from outside. One way to do this is to have 2 MXs for the inside machine: one pointing to the inside machine and the other to you local mail gateway. Then every time mail is sent to the inside machine there will be an attempt to get directly to it, which will fail, followed by a successful delivery to the gateway machine. Some mail software isn't good at using secondary MXes, but even without that problem it seems like a nice idea to have all your MXes pointing to accessable machines, and use an over-ride MX facility to get from the gateway to the inner machines. However my previous implementation was not optimal or maybe even correct. While making changes to my mail system I noticed that I'd left a wildcard MX. Since I had NO_WILDCARD_MX set I deleted it, and forgot it. Then everything broke, and I thought it must be my code changes. I had fun watching stupid domain name requests while I figured it out. My changes to deliver.c now look like this: *** deliver.c Sat Jul 14 07:39:29 1990 --- deliver.c~ Fri Jul 13 14:24:46 1990 *************** *** 429,435 **** if (ctladdr == NULL) ctladdr = &e->e_from; #ifdef NAMED_BIND ! _res.options &= ~(RES_DEFNAMES | RES_DNSRCH); /* XXX */ #endif /* NAMED_BIND */ #ifdef SMTP if (clever) --- 429,435 ---- if (ctladdr == NULL) ctladdr = &e->e_from; #ifdef NAMED_BIND ! /* _res.options &= ~(RES_DEFNAMES | RES_DNSRCH); /* XXX */ #endif /* NAMED_BIND */ #ifdef SMTP if (clever) *************** *** 436,447 **** { rcode = EX_OK; #ifdef NAMED_BIND - #ifdef OPTMX - if (host[0] && host[0] != '[' && - strcmp( m->m_mailer, "[IPC]") == 0 && pv[1] == NULL) - #else if (host[0] && host[0] != '[') - #endif { expand("\001w", buf, &buf[sizeof(buf) - 1], e); Nmx = getmxrr(host, MxHosts, buf, &rcode); --- 436,442 ---- *************** *** 496,502 **** rcode = sendoff(e, m, pv, ctladdr); } #ifdef NAMED_BIND ! _res.options |= RES_DEFNAMES | RES_DNSRCH; /* XXX */ #endif /* NAMED_BIND */ /* --- 491,497 ---- rcode = sendoff(e, m, pv, ctladdr); } #ifdef NAMED_BIND ! /* _res.options |= RES_DEFNAMES | RES_DNSRCH; /* XXX */ #endif /* NAMED_BIND */ /* ------------------------------------------------------------ The key point is an important one: don't do MX lookups for smtp mailers other than [IPC]. I also don't do them when there is a parameter to [IPC] but that is optional. However doing them for non-TCP/IP SMTP mailers is really dumb. In particular it completely broke by xsmtp (SMTP over X.25) mailer. How did it work before? Well the RES_DEFNAMES|RES_DNSRCH searches made a silly address which matched the wildcard MX. The result of this silliness was ignored. When I removed the wildcard MX it would bounce mail with "No such host (Authoritative answer from nameserver)". The message line included the ultimate destination name so it looked like it was that name it was talking about: very confusing. Isn't mail administration fun. I think BSD 4.4 will come with at least 4 alternatives for MTA software: sendmail, MMDF, PP and the new replacement for sendmail that is in the works. That should help reduce the amount of confusion :-). Bob Smart