----- Original Message ----- From: <[EMAIL PROTECTED]> > 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? Brad