--On Friday, 23 May, 2008 07:58 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
Hi,
I am wondering if writing a I-D or BCP is worth the effort
here and your comments are welcome.
Basically, with the advent of larger emails and the direction
of mail sophisticated mail receivers performing DATA
pre-response callouts to process the message before
determining what the response code will be, there is a greater
potential for client timeout issues, duplicate resends and
messages and of course, wasteful bandwidths and overheads.
...
Hector,
I'm not quite sure what you are proposing here. Examples:
* If the client sends SIZE with a big number, it should
wait longer?
* If the client knows that it is sending a big payload,
it should wait longer.
I'm pretty sure this is what Hector is talking about.
* The server should advertise, presumably as part of a
an extension announcement, "I'm a little slow, so, if
you send a lot of stuff, give me extra time".
Something else?
Clearly nothing in SMTP today prevents a client from using a
longer timeout if it thinks that is justified. On the other
hand, for a pair of SMTP implementation connected to the
Internet with decent broadband connections (or better) 10
minutes is a very long period of time unless one of them is
bogged down for other reasons. So I wonder if longer timeouts
alone would solve the problem or whether some sort of clunking
or restart facility would be a better solution.
Well, not only do we have an option to increase the client wait time based on
message size (STATUS_DATA_RECV_PER_BLOCK_TIME), we also have an option to
increase it based on number of recipients (STATUS_DATA_RECV_PER_ADDR_TIME) and
on size*recipient (STATUS_DATA_RECV_PER_ADDR_PER_BLK_TIME).
As for their utility, our experience has been that this is one of those things
that's rarely needed, but when it is needed you REALLY need it, because without
it you have to choose between crap client performance or large messages being
duplicated. Accordingly, I think writing it down somewhere makes quite a bit of
sense.
Ned