--On Tuesday, August 16, 2011 20:20 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
OK, I don't think it is productive to repeat these semantic
difference of opinions of what section 4.1.1.10 says:
...
Hector, having either written those words or inherited them from
Jon Postel and RFC 821, maybe I should offer an opinion. It is
really important to remember that SMTP is stateful (see 2.3.6
among other things) and that the DATA command:
-- Is treated as atomic wrt that state model, with the
354 message being a special "go ahead" indicator, not a
command termination acknowledgement
-- Terminates the mail transaction in progress.
Mail transactions are initiated by a MAIL command (see Section
3.3) and extend until a QUIT or RSET is issued or a DATA command
completes, whichever comes first. I think the spec is very
clear about that -- if you disagree, point out where and,
preferably, supply text.
Note (also in Section 3.3):
The end of mail data indicator also confirms the mail
transaction and tells the SMTP server to now process the
stored recipients and mail data. If accepted, the SMTP
server returns a "250 OK" reply.
Note that it does not say "tentatively confirms pending the next
command" or any such thing. The server gets EOD (CRLF.CRLF),
treats it as confirming the transaction from the client's
standpoint, initiates processing of the message, and treats the
mail transaction as ended.
IMTO, no matter how you wish read this, NO QUIT means a
cancellation because otherwise the only other way to end a
SMTP session is for the client to close the socket connection.
QUIT immediately after the DATA command (and hence the mail
transaction) completes is just a signal to the server that the
client is initiating an orderly close. It has no effect on the
mail transaction because there isn't one open. When the server
receives it, the SMTP session is closed. QUIT (instead of
DATA) after one or more RCPT commands is another matter, but
that isn't the case we are discussing.
Similarly, having the client close the connection after EOD is
sent is, indeed, "a cancellation", but it is a cancellation of
the SMTP session... it has nothing to do with any mail
transactions. On the other hand, if the client closes the
connection prior to sending EOD, that inevitably cancels both
the mail transaction and the SMTP session... having the server
deliver anything would be a really bad idea and is clearly (I
believe) outside the spec.
So what this would indirectly suggest the SMTP specs
implicitly says:
There is two ways for a client to end a SMTP session:
QUIT or DROP THE LINE
That is true even though one of those choices is prohibited
unless the "operational necessity" provisions are invoked.
and that does not jive with the written words:
The sender MUST NOT intentionally close the transmission
channel until it sends a QUIT command,
It aligns perfectly well. A client that closes the transmission
channel without first sending a QUIT is in violation of the
spec. That doesn't mean it can't do it. Because it can do it
and, more important, because all sorts of other things can cause
a connection to be dropped, a server has to be prepared to deal
with a dropped connection and to clean up when it occurs.
I just don't see a problem there. Please point out what I'm
missing.
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.
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 a potential problem with that model, but it is
connected to EOD in progress, not to the situation you are
apparently concerned about. That issue is discussed in great
detail in RFC 1047.
john