Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!ucbcad!ucbvax!SUMEX-AIM.STANFORD.EDU!MRC%PANDA
From: MRC%PANDA@SUMEX-AIM.STANFORD.EDU.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re:  ICMP messages
Message-ID: <12281523134.6.MRC@PANDA>
Date: Tue, 24-Feb-87 02:01:31 EST
Article-I.D.: PANDA.12281523134.6.MRC
Posted: Tue Feb 24 02:01:31 1987
Date-Received: Thu, 26-Feb-87 23:49:07 EST
References: <8702232051.AA15610@flash.bellcore.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 33
Approved: tcp-ip@sri-nic.arpa


     I am aware of two causes of the multiple-copies-of-the-same-message
bug that are caused by poor design of a version of the Unix SMTP server
that runs in all too many Unix hosts.

     When the end-of-message signal (<CRLF>.<CRLF>) is received, this
server spawns a program that appears to be called "sndmsg" to deliver the
message to all the recipients and it insists upon "sndmsg" running to
completion before it will return a success reply code to the SMTP client.

     The first problem happens when there are lots of recipients of this
message and the server's system is a bit loaded.  Many SMTP clients get
fed up if the server doesn't acknowledge the message within a reasonable
period of time (e.g. 5 minutes).  They decide the server is hung, nuke
the connection and try again later.

     Even if you don't believe in timeouts, you must recognize that not
all systems are pleased to have an SMTP stream waiting forever for a
hung SMTP server.

     The second problem will happen with ANY correctly-coded SMTP client.
Somewhere along the line, "sndmsg" runs into trouble.  The SMTP server
sends a 4xx series message with the extremely informative phrase "sndmsg
balks, try again later".  The message has been delivered to some recipients,
but not to others.  But since this is a "whole message failure", it gets
retried for everybody.

     I hope that we can see the extinction of this version of the Unix SMTP
server soon.  The server should NOT make the client wait while a message is
being delivered.  The "sndmsg balks" bug shows why this behavior is so
wrong-headed.  An acknowledgement should be sent as soon as the end of message
signal is received.
-------