--On Friday, 16 September, 2005 12:38 +0100 Paul Smith
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:
BUT, the consensus here is that you should NOT accept the
message and then send back a bounce later. So, you need to
analyse it at place of entry if possible.
Paul and others,
FWIW, at least part of what you are seeing as consensus involves
a number of us sitting back in astonishment that this discussion
has gone on as long and as far as it has. It would not be
correct for you to weight
-- a few postings from people who have expressed concern
about scaling, about large-scale production operations,
and about the whole idea of trying to use continuation
responses as keep-alives
against
-- the much larger volume of comments, repeated with
variations by the same group of people, that seem to
support these general ideas,
and conclude that the latter group has consensus.
What it, and the circa 70 messages on this subject in the last
three days, has mostly convinced me of is that we aren't going
to make any further progress on 2821bis without a WG to moderate
these sorts of suggestions and discussions. I have neither the
time nor the inclination to try to wade through all of the
messages of this type and try to figure out where we actually
are.
Just imagine for one second impact on world mail
infrastructure if average delay for ordinary mail trip will
change from few seconds today to few minutes tomorrow.
If it meant all the spam stopped as well, everything would be
much better... ;)
If spam accounts for 80% of email, then reducing that by using
more rigorous filters, even if they take longer is surely a
good thing. It will mean a bigger CPU load on the server
(where the most impact is), more open, idle, sockets on the
client, and less traffic on the Internet.
Prior experience indicates that it will merely increase the
amount of traffic the spammers attempt to send out, the number
of zombies they try to "recruit", and so on. The spam situation
is an adaptive system and the spammers have repeatedly
demonstrated that they are extremely adaptable. So, before you
propose a change that would slow down the mail system and cost
considerable resources, please think first about possible
counterattacks and then, whether you can figure out the
counterattack or not, about what we have done to ourselves if
the spammers do figure out such a counterattack, even one that
relies on brute force.
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.
2-3 or even 10 minutes is normal delay but only if average
delay is of order of few seconds.
Yes, the average being a few seconds is fine, and I don't have
any problem with that (our spam filter can sort out 99% of
email in less than 10 seconds, usually 2 or 3), BUT there are
occasional big messages, which can take a minute or so (most
of the time being spent in the virus scanner IME).
That is why the timeouts need to be longer than 30-60 seconds
(AS RFC 2821 SAYS). The timeout doesn't specify the average
time that a message can take before acceptance, but the
maximum time.
Setting the timeout too small just means that the client needs
to resend the message unnecessarily, which adds more load to
everything (client, server AND infrastructure) than the client
just waiting a bit longer because of a more sensible timeout.
regards,
john