IDA Sendmail 5.59 bugs and fixes (LONG)
Chet Ramey
chet at pirate.CWRU.EDU
Thu Sep 29 04:50:35 AEST 1988
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 at cwjcc.CWRU.EDU
| Chet Ramey chet at cwjcc.CWRU.EDU chet at alpha.CES.CWRU.EDU
|
| Just another jerk takin' pride in his work...
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list