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