> --On Friday, 23 May, 2008 07:58 -0400 Hector Santos
> <[EMAIL PROTECTED]> 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
