--On Wednesday, August 11, 2010 10:19 -0700 Dave CROCKER
<dhc(_at_)dcrocker(_dot_)net> wrote:
"Long delays after the<CRLF>.<CRLF> is received can
result in timeouts and duplicate messages. Deferring
detailed message analysis until after the SMTP
connection has closed can result in non-delivery
notifications, possibly sent to incorrect addresses. A
receiver-SMTP MUST carefully balance these two
considerations, i.e., the time required to respond to
the final<CRLF>.<CRLF> end of data indicator and the
desirable goal of rejecting undeliverable or
unacceptable messages at SMTP time."
I like this text. I think it reflects current operational
realities quite nicely.
Although we can't offer a precise algorithm, because we don't
know enough and because network variances make this
problematic to do at all, the draft text doesn't provide any
assistance beyond "thar be dragons". At the least, we should
try to offer tradeoffs, factors, and may even (sudder) a
heuristic.
For example, a delay time of up to 2 seconds is probably
pretty safe.
Dave,
In the spirit of my recent response to Murray, let me suggest
that, if one wants in-depth guidance here, it would be
appropriate to construct a separate document that contains a
real analysis of the situation, the tradeoffs involved, some
numbers and the basis for them, etc. Squeezing that into 5321
would almost certainly be too complex and might have to wait,
while a separate document could presumably be moved through the
system on its own merits. If one could get consensus for the
recommendations that would be great. Even if it could not,
publishing it as some insights into the subject would be useful.
The second option would not exist if one wanted to fold the
whole picture into 5321bis. If such a document existed, Ned's
suggestion would apply symmetrically: a reference to Craig's
analysis for the "duplicates" part and a reference to the new
document for the "blowback, SMTP-time analysis, and tradeoffs"
one.
john