-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of John C
Klensin
Sent: Tuesday, August 16, 2011 6:14 PM
To: Hector Santos; Keith Moore
Cc: SM; ietf-smtp(_at_)imc(_dot_)org
Subject: Re: Mail Data termination
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.
That's always been my understanding as well, and I don't see the ambiguity
being claimed. I've never encountered the reading of the SMTP specs that's
being argued here, either in a client or a server.
One of the more ubiquitous MTAs out there has a feature called "connection
caching" where it will keep some fixed number of outbound SMTP connections
around, cycled using an LRU method, in case a new message arrives that is
routed to a recent destination to avoid the cost of making a new connection and
doing the initial SMTP negotiation. That means this MTA would connect, do
HELO/EHLO, MAIL, RCPT, DATA, dot, and then wait for more mail to come in (or
for the cached connection to expire). With this interpretation, that means
only the last (n-1) messages are ever actually delivered while the connection
is held open, and the nth message goes missing if the connection is somehow
terminated without QUIT.
A client that implements this could still reasonably expect its mail to be
delivered because it is breaking a rule about terminating sessions, not
terminating transactions. And, most importantly, it at least got the post-DATA
status code so it knows if the message got accepted or not. It's certainly
broken, but it will still work.
The real concern with that is the case where the server following this logic
replies 250 after DATA, so the client thinks the mail went through, but then
for network reasons the connection dies before QUIT is received, so the server
throws away the mail. SMTP has always held that the client is responsible for
retrying delivery until the server gives a 250 or 5xx back after DATA, at which
point the server is now responsible for the message. Any server violating that
tenet seems seriously damaged to me.
-MSK