--On Wednesday, August 11, 2010 10:19 -0700 Dave CROCKER
<[email protected]> 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
