Path: utzoo!utgpu!watserv1!watmath!att!ucbvax!ucsd!brian
From: brian@ucsd.Edu (Brian Kantor)
Newsgroups: comp.mail.sendmail
Subject: Re: No '250 Ok' sendmail problem
Message-ID: <15277@ucsd.Edu>
Date: 10 Jul 90 15:12:18 GMT
References: <39824@mips.mips.COM> <7516@gollum.twg.com>
Organization: The Avant-Garde of the Now, Ltd.
Lines: 44

In fact, some mailers can be configured to immediately return the '250
OK' after receipt of the '.' ending the DATA transmission, thus
indicating that they have successfully enqueued the message.  Others
may wait until the local delivery or forwarding has taken place.  I
maintain that the first is the more correct way to go, as it avoids
long waits on locked files or reluctant nameservers.

I believe Sun modified their sendmail to do the former.  I think
sendmail 5.64 still does it the old way, although I'll admit I haven't
checked.

I have noticed that it's possible to make local delivery really slow in
various ways and stall a sendmail's ACK in this way.  If the sending
sendmail is set too impatient (i.e., the 'violates protocols' timeout is
set to something impractical, like a minute), the sender will time out
and resend the message on the assumption that the channel was lost.

The cures for this are to have the sender be a whole lot more patient
(I think 15 minutes is the minimum you should use), and for the receiver
to make sure he hasn't done something in the rulesets that are called
during message receipt that might cause large delays, such as lookups
into a slow nameserver.

Of course, the most common cause for this to occur is a looping rule -
if a receiving sendmail gets a rule stuck in a loop, you'll never get the
ack.  This is particularly common in the 'R' and 'S' rules that are
called to process header lines; since they get invoked while the
message DATA is happening, it'll look like the message itself is the
problem whereas what is really happening is that the majority of the
message is still sitting in the TCP stream and sendmail is stuck on a
header line up at the front of the message.  Eventually the sender
gives up, closes the connection, the receiver gets a SIGPIPE, and it
all happens all over again on the next try.  See if the sendmail on the
receiving system is accumulating a lot of processor time.

This is where being able to turn on debugging from the tcp connection is
invaluable.  Unfortunately, because of a security hole associated with
the debug command (remember the Morris worm?), a lot of misguided
manufacturers have disabled the debug command instead of fixing the
hole.  If you have one of these castrated sendmails you'll have to find
the looping rule the hard way.

Hope that helps.
		- Brian