[Top] [All Lists]

Re: Mail Data termination

2011-08-16 21:51:47

At 9:14 PM -0400 8/16/11, John C Klensin wrote:

  Aside: there is a design characteristic here that I wish
        were different in SMTP.  I have wished it for any years,
        that has done me no good, and I can see no possible way
        to change it now, at least at a plausible level of
        effort.  SMTP does not anticipate a case in which a
        client opens a mail transaction, sends RCPT commands as
        needed, sends DATA and then changes its mind and wants
        to abort sending without having the message delivered.
        With SMTP as now defined (and as it has always been
        defined), it can do that _only_ by closing the
        connection prior to sending EOD.  While the use cases
        are few, that is just unsanitary, especially in a model
        in which we expect closing of an SMTP session to be
        preceded by a client-server handshake (i.e., sending
        QUIT).   In an alternate universe, we might have had
        EOD-and-deliver and EOD-and-abort, not just the first.
        But we are getting real close to 30 years after the time
        to make that choice differently.

If we did have this, it would probably now be used by spammers to probe the acceptability of various messages.

  > I can understood your position, very clearly, but in general,
  > I don't think this is a good way to do robust client/server
 communications (allowing drops to signal message transaction
 completion). It opens the door for unsureness.

 But, as I hope is clear from the above, no such thing happens.
 If the drop occurs after EOD, the mail (message) transaction is
 over already, completed by EOD.  If the drop occurs before EOD,
 the mail transaction and the SMTP session are abandoned and,
 because EOD wasn't received by the server, nothing is delivered.

There is of course a timing hole (as there always is): if the connection drops after the client sent EOF but before the client received a reply, then the client can't know if the server is processing the message or not.

Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
We adore chaos because we love to produce order.
                                 --M. C. Escher

<Prev in Thread] Current Thread [Next in Thread>