Gordon Messmer wrote:
... when mail servers connect to courier's
smtpd and send RCPT commands with invalid users (or any other error),
smtpd starts tarpitting them -- after each failed command, it waits for
an increasingly long period of time before it replies and reads more
commands.
This looks like a very plausible explanation to what's happening.
If tarpitted = MAXDAEMONS because of a storm of garbage, courier
would end up with no free resources to deal with anything else,
legitimate or garbage.
This feature of courier prevents dictionary attacks against
your system. In your case, the mail servers sending you backscatter
continue to send commands for a long period, which means that it takes a
long time for courier to free up slots for new connections. What you're
seeing is not a bug in courier.
In this case this feature turns against me and everybody else except
the spammer. What is hitting me is more or less innocent servers
bouncing spam (not 100% innocent because they shouldn't have accepted
that spam in the first place, but misconfigured != malicious). So
tarpitting them wastes their resources and mine, especially mine,
without achieving any desirable effect, e.g. slowing down the spammer.
I'll risk earning myself an RTFM reply and ask: is there a way to
configure tarpit=off?
Z
11 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Saturation DDoS
