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