At 14:08 15/09/2005, Bogdan Tomchuk wrote:
> Unfortunately, the 'critics' of the the 'keepalive' discussion here don't
> seem to understand the problem..
Don't you think that requirement of mandatory keep-alive support in RFC
will create, in consequence, extremely powerful source of DOS?
No. No one is proposing that a keep-alive allow a reply to be delayed
beyond the RFC 2821 suggested timeout values.
If people think the RFC 2821 timeout values are too long, then that needs
to be discussed as well - but no one here has said they need changing!
> 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
Can you give some real world example?
The real world example IS anti-spam and anti-virus software.
If you don't see spam as a big problem that needs solving, then you're
living in a different world to the rest of us..
NB I do not consider any anti-spam system as such example.
That's like saying 'I don't believe you can get from Europe to the USA in
less than 10 hours - show me how you can do that, and I don't consider air
travel as an example'. It's arbitrarily disqualifying what you know is the
> I wonder how many system administrators who have set short timeouts have
> actually looked at how many unnecessary re-sends are taking place because
> of it.
Can you precise me what do you consider to be "short timeouts" ?
Anything less than 2 or 3 minutes IMHO, or less than 10 minutes according
to RFC 2821.
Paul VPOP3 - Internet Email Server/Gateway