At 10:49 15/09/2005, Tony Finch wrote:
If you want to add keepalives, write an ESMTP service extension.
Unfortunately, the 'critics' of the the 'keepalive' discussion here don't
seem to understand the problem..
In an ideal world, we wouldn't NEED keepalives..
In an ideal world, SMTP client users would read RFC 2821 and use the
timeouts recommended therein, or at least understand the reason for them
and maybe set shorter, but still reasonable timeouts (eg 3-5 minutes)
Yes, we could write an ESMTP service extension, but no one would implement
it on the client side, because the timeouts specified in RFC 2821 are
sufficient that no keepalive would be needed..
However, people override the defaults set in their SMTP client software,
and set the timeouts to very low values (30-60 seconds is not uncommon,
even though the standard recommends 10 minutes)
Sometimes the server NEEDS to take longer than the very short non-standard
timeout allowed by these client to decide whether to accept the message or not.
So, unfortunately there needs to be a solution which works. I really don't
think an SMTP service extension would solve the problem - the problem is
system administrators who decide they know better than the standards and
set low timeouts. These administrators would also turn off any 'keepalive'
SMTP service extension, rendering it useless.
As I've mentioned before, the only workable solution I can think of that
doesn't involve a 'keepalive' of some sort involves double transmission of
the messages that would cause a timeout. This can't possibly be more
efficient for the client than just waiting a bit longer (which is precisely
why RFC 2821 specifies the long timeout periods).
I wonder how many system administrators who have set short timeouts have
actually looked at how many unnecessary re-sends are taking place because
Paul VPOP3 - Internet Email Server/Gateway