[Top] [All Lists]

RE: Mail Data termination

2011-08-17 00:14:59

-----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 
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.


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