Carl S. Gutekunst wrote:
Tony Hansen wrote:
On the flip side is this:
4.5.3.2.6. DATA Termination: 10 Minutes.
This is while awaiting the "250 OK" reply.
There's a world of difference between the obligation of the server to
emit a timely response, and the obligation of the client to not give up
early.
Dave, unfortunately I'm not good at the normative references, but I am
long on experience here. My observation at Postini was that most clients
give up after a much shorter time. 5 minutes was common, but some were
as little as 30 seconds.
We seen an average of 3-5 minutes for the problematic reports issues.
As a result, duplicates were such a staggering huge problem. To mitigate
that, Postini computed a SHA-1 hash for every message, and if there was
any evidence that the receiver had sent the 250 OK, but the sender never
got it, the hash was saved in a database. If the sender resent the
message, the proxy (knowing it had already been delivered) quietly ate it.
+1.
We had to do two things:
- Socket drop detection to about the DATA scripts
- Read the socket buffer for any QUIT command.
So if there evidence of the QUIT in biffer, the accepted payload was
queued for delivery. We always had a dupe checker so retransmits were
never an issue.
But this lead to an issue regarding a 821/2821/5321 feature we enabled
which I call the NO-QUIT-CANCEL SMTP requirement.
Once the 250 was determined as the response for the sender, the
message was immediately queued for delivery. The receiver did not
require the QUIT to cancel the message which was probably already routed.
So in view, SMTP has a silly QUIT requirement which was modeled after
single-threaded process mentality and POST SMTP only processing.
So while the 1988 RFC 1074 touches based with the synchronization gap
between <crlf>.<crlf> and the receiver reply code, SMTP also has a
time gap between the receiver 250 and the sender QUIT command.
Because of the unavoidable use and growth of MTA adding DATA
processing scripts, many of my sysops turn off the NO-QUIT-CANCEL
requirement.
--
Sincerely
Hector Santos
http://www.santronics.com