John C Klensin wrote:
This is _not_ a standards problem, at least IMO.
I guess the point is the CS holding time is "unnatural" from a
receiver point of view and if the insight was available long ago, I
believe it would have changes a quite few things, including a
consideration in receiver loading limits to take into account that
capacity limits cause by caused by the increase use of CS clients
deliberated slowing down the receivers.
If RFC5322 stated:
A 5 minute idle time is required after a transaction was
complete in order
to allow the sender the opportunity to start a new transaction.
Then we have a different story because now both client and server
designers are in sync with SMTP client/server high scale throughput
modeling.
But it doesn't not say that. It does say to allow for new transaction
but I don't think most presumed that a client will deliberate wait X
time at this point because of their (client side) queuing problem is
easily solved with other client-side only solutions with the same end
result without impacting SMTP server designs or causing any new SMTP
implementation considerations, including considerations that further
goes against its recommendations.
For example, I already added an operator option to lower the Idle Time
after the first transaction is completed to a default 1 minute.
It changes the design picture when the discovery of client with CS
behavior is highlighted.
While I don't think this warrant any immediate concern, the day
5321bis does opens up, I think you should be ready for discussion
regarding timeouts among other related things regarding
multi-transaction sections. :)
--
Sincerely
Hector Santos
http://www.santronics.com