Path: utzoo!attcan!telly!lethe!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!piet
From: piet@NIC.EU.net (Piet Beertema)
Newsgroups: comp.mail.sendmail
Subject: sendmail 5.6[45] problems; clues anyone?
Message-ID: <2059@mcsun.eu.net>
Date: 21 Dec 90 21:24:24 GMT
Organization: European Unix systems User Group
Lines: 81

Ever since I upgraded from sendmail 5.61 to 5.64 a while ago I've
had problems with it. First it dumped core whenever the frozen
config was used; I traced it back to apparent messing up of the
malloc and posted some workarounds for it in this newsgroup.

Now, since a couple of days I had a consistent problem: whenever
the frozen config was used, weird things happened, like the smtp
server announcing itself not with "HOME=/" instead of the hostname
and e.g. the From: in the header being replaced by garbage. This
happened after a minor change in sendmail.cf, which in itself is
correct and does what it is expected to do.
I then switched to running without frozen config, but obviously
that causes quite some additional load on the system; especially
on a host like mcsun.EU.net (for those who don't know: roughly
speaking mcsun is for Europe what uunet is for the USA) that's
not really a good idea.

Hoping that the problem would be cured in sendmail-5.65/IDA-1.4.2
I installed that version today, only to discover that the problem
was still there. I haven't dug deep into it yet, but this is clear:
looking with 'strings' at the frozen config files produced by 5.61
and 5.6[45] there is a striking difference: in the 5.61 frozen
config strings of the config file can be found *after* the (saved)
environment items, whereas in de 5.6[45] frozen config parts of
the config file can be found *before* the (saved) environment items.
If it is assumed that the config starts at that point, it is clear
that the environment items have become a part of the config, which
in turn explains why environment items appear instead of the hostname
or in the header as described above. I think it can therefore be
safely assumed that the malloc() structure has been messed up before
the frozen config is written, which is what I found when I started
with 5.64; alas, the workarounds that I made don't help here.

If anyone has a clue I'd appreciate to hear it.



Another point is that I found that 5.65 had a workaround for the
problem with syslog() that a lot of systems have (HCX/BSD, HP-UX,
SunOS 4.0.3/4.1 all have it): give syslog() a very long string and
you'll get a coredump. The workaround in 5.65 is just truncate the
reported string. This may be acceptable for a lot of sites, but for
central (mail)hosts and gateways it's important that *all* addresses
processed show up in the (sys)logging. Here's a better workaround
that does precisely that; it spreads long strings over several log
lines, non-terminal reports being marked with "(cont'd)"; replace
the logdelivery routine in deliver.c with this one:

logdelivery(stat)
	char *stat;
{
	extern char *pintvl();
# ifdef LOG
# define LOGSPLIT 200
	register char *p, *q;

	/*
	** Split up long To: lines, since the buffer in
	** syslog() on various systems isn't large enough.
	*/
	p = CurEnv->e_to;
	while (strlen(p) >= LOGSPLIT) {
		if ((q = index(p + LOGSPLIT, ',')) != NULL) {
			syslog(LOG_INFO, "%s: to=%.*s(cont'd), delay=%s, stat=%s",
				CurEnv->e_id, q - p + 1, p,
				pintvl(curtime() - CurEnv->e_ctime, TRUE),
				stat);
			p = q + 1;
		} else
			break;
	}
	syslog(LOG_INFO, "%s: to=%s, delay=%s, stat=%s", CurEnv->e_id,
		p, pintvl(curtime() - CurEnv->e_ctime, TRUE), stat);
# endif /* LOG */
}


------------------------------------------------------------------------------

-- 
	Piet Beertema, EUnet-NIC, Amsterdam   (piet@mcsun.EU.net)