At 13:32 14/09/2005, Harald Tveit Alvestrand wrote:
If you're saying that Postfix can't handle that, so that it NEEDS to have
the timeout there set to 30 seconds or less, then all I can say is Hmmm...
I'm saying that if the average time for a transaction (which is under the
control of the receiving MTA) increases, there will be a definite impact -
which will be most keenly felt by high-volume sites.
So, RFC 2821 needs to be adjusted so that the post-DATA timeout is set to
less than 30 seconds? If that's what you're saying is necessary, then
that's what the standard should say... Currently it says 10 minutes!
Really, you have to decide, is the biggest problem felt by high volume
sites the spam and viruses that their servers have to deal with and the
corresponding support, hassle, customer dissatisfaction etc, OR is it their
servers sitting with some idle sockets waiting for a response.
I'd argue that the biggest problem is the spam and viruses - that's the
problem we're trying to sort out
*IF* high volume email producers got their act sorted out, and had SPF or
similar for all their domains, AND hit down *hard* on any of their users
sending spam and viruses, then the rest of us might not need to have spam
filters that mean that their servers have a few idle connections for a bit
longer than they'd like...
Linux servers should be able to handle many thousand outgoing connections
at once. The idle ones take up negligible resources.
I hear lots of people saying 'you shouldn't have long delays', and 'you
shouldn't do accept and bounce later' - but what should you do then, just
drive users away from SMTP email by sending lots of spam and viruses into
their mailboxes?
Paul VPOP3 - Internet Email Server/Gateway
support(_at_)pscs(_dot_)co(_dot_)uk http://www.pscs.co.uk/