>Tail end of section 6.1 of 5321: > >"To avoid receiving duplicate messages as the result of timeouts, a > receiver-SMTP MUST seek to minimize the time required to respond to > the final <CRLF>.<CRLF> end of data indicator. "
That language is taken verbatim from 2821. In both RFCs the following sentence refers to RFC 1047. RFC 1047 describes a problem Craig Partridge observed when an SMTP server did lots of work after the dot, and the client gave up and went away in the meantime. The client assumed the delivery failed and it had to resend later, but the server eventually said OK, so the message got delivered twice. I believe this was a problem on CSNET when he wrote the RFC in 1988. It is my impression that MTAs have gotten someone more robust in the ensuing two decades. Is it still a problem now? For a while I used a very aggressive greylister which soft failed after the dot, kept a hash of the message, and wanted to see an exact copy with the same hash to let the message through. I stopped using it, but not because of SMTP problems. (A surprising number of ESPs reconstruct the message rather than retransmitting it, so the hash didn't match.) Anyone got actual experience with delays at the dot? It wouldn't be hard for me to stick a module into my SMTP daemon that inserts extra delays and see what breaks. R's, John
