RE: Mail Data termination

["Murray S. Kucherawy" <msk@xxxxxxxxxxxxx>]

> -----Original Message-----
> From: owner-ietf-smtp@xxxxxxxxxxxx [mailto:owner-ietf-smtp@xxxxxxxxxxxx] On Behalf Of John C Klensin
> Sent: Tuesday, August 16, 2011 6:14 PM
> To: Hector Santos; Keith Moore
> Cc: SM; ietf-smtp@xxxxxxx
> 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