[5257] in Kerberos
Re: MAIL LOOP: kerberos IV installation problem
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Wed May 24 11:01:51 1995
To: kerberos@MIT.EDU
Date: 24 May 1995 14:48:12 GMT
From: jik@cam.ov.com (Jonathan I. Kamens)
In article <199505240536.WAA00516@btw.CyberSAFE.COM>, dennisg@CyberSAFE.COM (Dennis Glatting) writes:
|> Having inflicted a similar annoyance I'll tell you what I
|> learned. The Kerberos list is tied to a database. When a
|> message is sent to kerberos@mit.edu the MIT mailer
|> queries the database to expand the list.
This is not entirely accurate. MIT is running sendmail. Admittedly, it's
sendmail with some local hacks, but it's still by and large plain sendmail.
The kerberos@mit.edu list is nothing more than a sendmail alias (well,
actually, a number of aliases which are all included in the actual "kerberos"
alias, to work around record size limitations in dbm); while technically, you
might call dbm a "database", that seems like a bit of an overstatement.
When a message is sent to kerberos@mit.edu, sendmail on the MIT mailhub tries
to resolve all of the host names of all of the members of the list. That
host-name resolution, and not some sort of "database query" to get the
contents of the list, is what takes a while.
Newer versions of sendmail have a sendmail.cf option which can be set to tell
sendmail not to resolve host names until delivery. However, the version of
sendmail that MIT is running is not new enough to support this option.
Yes, MIT could upgrade to a newer version of sendmail, but they'd have to
integrate all of their local changes into the new version, and they don't have
unlimited resources to embark on such a project.
Yes, MIT could install some sort of list manager such as MajorDomo. But
again, they don't necessary have the manpower resources to do that;
furthermore, it's not obvious that they have the hardware resources either.
I just checked the mailer logs of our mailhub, which is where all messages
posted to comp.protocols.kerberos get gatewayed into kerberos@mit.edu, and I
see there that the longest delivery delay for such a message since May 20
(which is when the log file was last turned over; I don't feel like digging
through the old compressed logs to get statistics going back earlier, and I
don't think it's necessary anyway) was eight minutes and fifty-one seconds.
There are mailers on overloaded machines nowadays which take that long which
to accept a message to a *single* recipient, let alone to an entire mailing
list, so it seems unreasonable for people to be setting their timeouts to
anything less than that.
I'm not even sure that timeouts are really what's causing this problem,
because I find it hard to believe that the version of sendmail that MIT is
running would accept and deliver a message without receiving the '.' from the
sender to indicate that the message data has ended.
Oh, and by the way, people who read comp.protocols.kerberos rather than
kerberos@mit.eu haven't had to deal with this, because the gateway from the
mailing list to the newsgroup automatically drops empty messagse on the floor
:-).
--
Jonathan Kamens | OpenVision Technologies, Inc. | jik@cam.ov.com
