Leigh S. Jones, KR6X wrote:
To sum up what has been said on this issue thus far,
some believe that it's inefficient to wait until the target of
the spammer has been identified to send the 511, while
others believe it's nice to be able to identify the user
who has been targeted in the logs in order to ease the
facilitation of whitelists whenever needed. No one
has mentioned that usually the response from two
or three RBL's will take a little bit of time anyway.
Meanwhile, it's more efficient to allow the sending
server to continue the conversation with the receiving
server until the RBL response comes back.
I insinuated that point in the original post. :-)
Meanwhile, the delay presents a bit of a defacto tarpit for the
spammer.
That's dubious. One of the problems with tar pitting is that it takes up
resources on the server - at least a TCP connection, plus whatever
listens on it. If you're going to tar pit, the way forward is to jam the
3-way TCP hand-shake and wedge the connection half open. That takes no
resources on the server (not even a TCP connection), and it stops the
sender from re-using that connection until TCP times out. And there is
very much a finite number of TCP connections you can have open at any
one time - especially on a malware infested Windows zombies usually used
for spamming.
No one has mentioned that it's necessary to wait until
the possible spammer identifies his target to know
whether the target has him whitelisted.
Whitelists aren't really practicaly on big setups. You need to block a
lot before they even get as far as talking TCP. If you can manage a
decent job with that, RBLs can prune enough of what's left for
spamassassin and virus scanners to be able to cope with the minute
amount of mail that is actually deliverable. It is not all that uncommon
to see the spam:ham ratio of around 250:1. When you have a system
handling mail for half a million domains, well, you get the idea.
Gordan
9 messages in net.sourceforge.lists.courier-usersRe: [courier-users] RBL Check - When?
