OT: Tarpitting, secondary MXes, and rate limiting

[Kelson <ke...@speed.net>]

In light of the recent discussion on secondary MXes, we're experimenting 
with using a dummy low-priority MX to draw off some of the spam 
targetting our primary.  The first phase was just pointing it at a 
machine that didn't accept mail.

For phase 2, I installed a tarpit/teergrube script on that machine.  It 
took a while for anything but IP addresses to start showing up in the 
logs, but what I found was surprising: nearly every connection was sent 
from "<>" to an invalid user! (The exception looked like actual spam.)

After a little digging, I think I know why: it's because we've enabled 
rate limiting and connection limiting on our primary.

We get a ridiculous number of bounces to and probes for random forged 
accounts.  Many of the systems sending these are not well-behaved: 
they'll open up as many simultaneous connections as they can, and 
they'll resend with delays as short as one second.  So they quickly run 
into our connection and rate limits (hooray for Sendmail 8.13!)...and 
immediately start hammering the secondary.  And when they hit the limits 
on the secondary, they start hitting the tarpit.

I'll be turning it off over the weekend -- if nothing else, I have to 
make adjustments to turn off tarpitting in the (unlikely, I hope) event 
that both real servers go down -- but it does make me wonder whether 
rate limiting and dummy MXes are really compatible ideas.

It really surprises me how long some of these servers will stay 
connected just to deliver an invalid bounce.  And these aren't the ones 
I really *wanted* to tarpit anyway (though they're annoying enough in 
their own right).

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>

Re: OT: Tarpitting, secondary MXes, and rate limiting

[Kelson <ke...@speed.net>]

Menno van Bennekom wrote:
> I can't see the incompatibility between the rate-limiting and the dummy
> mx, but maybe if you turn the dummy mx into a tarpit you can make life too
> difficult for legitimate (but very fast?) bouncers. Is that what you mean?

Yes, I meant compatibility in a general sense -- as in are the ideas, 
when used together, effective or counterproductive?

> Probably your domain is used a lot by spammers as spoofed reply-to..

Oh, yeah!  Randomly-generated username plus our domain name.  Why us? 
No idea.  Probably the single-dictionary-word domain name.  It adds up 
to a zillion bounces, a ton of probes, and several bogus complaints a week.

What I'm seeing with the tarpit is that of the connections that stick 
around long enough to issue FROM and RCPT, nearly all look like the DSNs 
and probes above.  Since a lot of these "senders" tend to saturate the 
rate limits we impose, it seems likely that they're tying up the max 
number of connections we allow on our primary, cascading to the 
secondary and then to the dummy.  (Or they could be targetting the 
low-priority MX, spammer-style.)

On one hand, I want to tie up *spammers'* resources, not people checking 
their own incoming mail.  On the other hand, they *are* hammering us 
with bogus bounces and excessive (and often repeated) probes to the 
point where I consider it an abuse of *our* resources, so I don't feel 
*too* bad.

My main concern is that this could happen, on occasion, with a legit 
sender.  If for some reason a site tries to open too many simultaneous 
connections, they'll get sucked into the tarpit instead of waiting and 
trying again.

-- 
Kelson Vibber
SpeedGate Communications <www.speed.net>

Re: OT: Tarpitting, secondary MXes, and rate limiting

[Menno van Bennekom <mv...@xs4all.nl>]

> In light of the recent discussion on secondary MXes, we're experimenting
> with using a dummy low-priority MX to draw off some of the spam
> targetting our primary.  The first phase was just pointing it at a
> machine that didn't accept mail.
>
> For phase 2, I installed a tarpit/teergrube script on that machine.  It
> took a while for anything but IP addresses to start showing up in the
> logs, but what I found was surprising: nearly every connection was sent
> from "<>" to an invalid user! (The exception looked like actual spam.)
>
> After a little digging, I think I know why: it's because we've enabled
> rate limiting and connection limiting on our primary.
>
> We get a ridiculous number of bounces to and probes for random forged
> accounts.  Many of the systems sending these are not well-behaved:
> they'll open up as many simultaneous connections as they can, and
> they'll resend with delays as short as one second.  So they quickly run
> into our connection and rate limits (hooray for Sendmail 8.13!)...and
> immediately start hammering the secondary.  And when they hit the limits
> on the secondary, they start hitting the tarpit.
>
> I'll be turning it off over the weekend -- if nothing else, I have to
> make adjustments to turn off tarpitting in the (unlikely, I hope) event
> that both real servers go down -- but it does make me wonder whether
> rate limiting and dummy MXes are really compatible ideas.
>
> It really surprises me how long some of these servers will stay
> connected just to deliver an invalid bounce.  And these aren't the ones
> I really *wanted* to tarpit anyway (though they're annoying enough in
> their own right).
>
> --
> Kelson Vibber
> SpeedGate Communications <www.speed.net>
>
I can't see the incompatibility between the rate-limiting and the dummy
mx, but maybe if you turn the dummy mx into a tarpit you can make life too
difficult for legitimate (but very fast?) bouncers. Is that what you mean?
Probably your domain is used a lot by spammers as spoofed reply-to..
Or are you bouncing spam-mails and viruses yourself?
This could give you more bounces because of bouncing of the false reply-to
address. Personally I hate bounces, it makes the bouncing mailserver an
almost open-relay for spammers and viruses. Most viruses come to us
because of bouncing mail-servers that attach the complete virus(!) and
bounce it to our spoofed address. The least they could do is just send the
first 1024 bytes or so.. I think you can configure that in any mailserver.
If I reject mail I do so at the MTA level (also checking
recipient-addressess) and viruses and spam are not bounced. My mailservers
do not send any bounces, so I'm not causing your bounce problem ;-)

Menno van Bennekom