Dave CROCKER wrote:
The substantive issue is the text:
"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. "
Does anyone suggest considering modification to any other text in the
document?
Does anyone have useful text to suggest for adding or changing?
I think its fine, but the only thing I can see is adding insights
requiring real timeout values seen in practice. Its not 10 mins.
"Practice has shown the recommended 10 minute timeout is not
common place and closer to 3-5 minutes. While receivers should
DATA processing needs make this process as fast as possible, it
SHOULD limit accumulated DATA processing time to less than
5 minutes."
My concern is that there would be codification to DISCOURAGE data
level processing and that quite frankly is unrealistic. So we embrace
it and provide insight for implementator.
Of course, a constant concern would be backward compatibility to
address legacy Operations. We are all for that.
However, any change proposal only applies to active systems that are
in position to adapt. So any new adjusted "guidelines" should be
proactive with new ideas to better address both new and old operations.
I can only see adding notes regarding how unrealistic a 10 minute
timeout is in practice for LEGACY systems.
New systems will mostly like adapt and adjust and add a 10 min timeout
as currently recommended by 5321.
--
Sincerely
Hector Santos
http://www.santronics.com