----- Original Message ----- 

> Just thinking out loud.....
> The approach of tarpitting is to slow down the attacker without impacting
> your network or requiring additional resources on your end to deal with
> the cracker.  I *think* it does this by analyzing the volume of incoming
> SMTP requests from the same host.
> The approach of chkuser is to reduce the amount of incoming messages by
> denying unknown recipients before the message Data is transmitted.
> I would hate to see an expanded chkuser that requires extensive database
> activity to log/monitor/tarpit the username requests.  That's throwing
> more resources at a problem....
> I think its entirely appropriate to respond VERY slowly to an unknown
> username request.  HOWEVER, if I suddenly have a shortage of SMTPD daemons
> because they are left open to service the "chkuser tarpit", and that hurts
> my email service quality, then I haven't gained anything.  I would rather
> be fast at dumping chkuser denials and let them guess.
> I guess if there was a child daemon that could handle ALL of the chkuser
> tarpits (instead of keeping an SMTPD open) then we might have something
> really great.
> Sorry if I'm being too utopian, or too vague.  Just trying to contribute.
> D.

I thought on this whole ordeal for several hours and the best way I could
come up with is the following:

If so many invalid addresses in one connection then enter ip in tcpserver's
tcp.smtp file with a deny of IP. This will be removed every so many minutes
by a cron job. This way you could add a dely on how fast they could get the
addressess. Thi seems to be the least overhead way that I have come up with.
Any thoughts on this?


Reply via email to