Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!nrtc-gremlin.arpa!mrose
From: mrose@nrtc-gremlin.arpa.UUCP
Newsgroups: mod.protocols.tcp-ip
Subject: Re: When to acknowledge SMTP messages
Message-ID: <26389.541414281@nrtc-gremlin.arpa>
Date: Fri, 27-Feb-87 03:58:28 EST
Article-I.D.: nrtc-gre.26389.541414281
Posted: Fri Feb 27 03:58:28 1987
Date-Received: Sat, 28-Feb-87 08:05:55 EST
References: <8702270038.AA00078@apolling.imagen.uucp>
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 18
Approved: tcp-ip@sri-nic.arpa

Hack.  Hack.  Hack.  Two things:

1.  As Jordan pointed out: as soon as the SMTP server queues the message for
    delivery (not actually delivers it), the server should send the success
    acknowledgement to the client.  Even if your host is single-threaded,
    the server can always deliver the mail *after* the SMTP connection is
    closed.

2.  Why hack SMTP?  I can find similar faults with interactions in FTP.
    And in just about any command/response application that you can run
    on top of TCP.  The correct solution is to add an *option* to TCP
    saying to use keep-alives.  Things like SMTP could use it, things like
    telnet (where a failure is obvious to any interactive user) don't have
    to use it.  With this solution, you only have to make a very small
    change to the way an application opens the network, instead of complicating
    the peer-to-peer protocol used by the application.  Keep it simple guys!

/mtr