chet@pirate.CWRU.EDU (Chet Ramey) (09/29/88)
I've finally gotten sendmail 5.59 with the IDA changes to work on some MicroVAXen running Ultrix 2.2 and Suns running SunOS 3.5, and here is a description of the changes I made to get it right: 1. The normal changes all of us who put 5.59 on Ultrix had to make to get that running in the first place -- IDA 5.59 has #ifdef sun all over the place; in most cases this can be changed to #if defined(sun) || defined(ultrix) and most of that battle is done. (You need 4.3 ndbm and bind 4.8 to fully utilize IDA sendmail; we had those already. The already-advertised fix to the Ultrix 2.2 /usr/include/arpa/inet.h is assumed as well.) 2. Lennert restored the old code in daemon.c:maphostname that called gethostbyname() to canonicalize host names because local names will not be canonicalized by a call to getcanonname() if there is not an alias for them (a CNAME record) in your name server database. That's all well and good (though not a real problem for us, since we do have such aliases in our name server), but since gethostbyname() queries for and returns only A records, hosts with only MX records (e.g. rayssd.ray.com, which is the host that brought this to our attention in the first place) don't get canonicalized. Here's why this is important for us: we try to resolve every mail transaction so we can deliver it via our internet connections, and fall back to using pathalias output only if that fails. Sendmail's $[ $] construct works pretty well for this (with one change, described in a second). Host names that don't get resolved this way get resolved from the pathalias output (either using IDA's keyed database lookup or shipping the mail off to smail and letting smail resubmit the mail to a "lower fork" of sendmail). Without using getcanonname(), these MX hosts don't get resolved to their MX forwarder, but to a UUCP path. This is unacceptable. My fix is to combine the two approaches. Change the code for getcanonname() so that it returns TRUE or FALSE depending on whether or not the name was found by the resolver, and change the res_search call there to query for class T_ANY (this has been discussed here previously). Then change maphostname() to call gethostbyname() first, then getcanonname() if that call fails. This works OK for our purposes. 3. Lennert "tentatively" fixed a bug that involves SMTP input shared between parent and child sendmails by turning off buffering for the reads. The basic idea is that the sendmail SMTP daemon forks another process to handle SMTP delivery after the daemon reads the MAIL From: command, and sleeps while the child processes the rest of the transaction and delivers the mail. Both parent and child read from stdin and share the same file descriptor, but not the same struct _iobuf, so the parent reads the same input the child has processed when it resumes execution after the death of the child (unless, of course, stdin is a terminal). His fix was to have them both run unbuffered. This doesn't work well, at least with Ultrix 2.2 and SunOS 3.5. What happens is that sendmail just forgets about the headers on the message coming in over the SMTP connection, and adds an entirely new envelope. The net result is messages in your mailbox with two sets of headers: the first contains the final Received: line, the From: line from the SMTP MAIL From: command, an Apparently-To: header constructed from the SMTP RCPT To: command, and an entirely new Message-ID: header; the second set has all the other Received: lines and the rest of the original headers, including the true From: line. The fix (at least it seems to have fixed the problem here) is to comment out the call to setbuf() in main.c, right before the call to smtp(). Note that these fixes just make IDA sendmail a "better 5.59"; we are still using our old sendmail.cf, and haven't totally bought into the IDA mail delivery philosophy. If and when we do, and if we have to make more fixes, those will be posted as well. Context diffs are available on request. Chet Ramey Andrew R. Jennings Computing Center, CWRU chet@cwjcc.CWRU.EDU | Chet Ramey chet@cwjcc.CWRU.EDU chet@alpha.CES.CWRU.EDU | | Just another jerk takin' pride in his work...