It's been quiet on this list for a while. If you can't remember why you're on it, removal info is at the bottom.
I'm dedicating more time to TarProxy now, so hopefully it won't be so many months between messages. On Wed, 2004-02-18 at 19:38, Rene Bartsch wrote: > Hi, > > three days ago I've sent the following suggestions to the ASSP-ML. > > Maybe there are some interesting points for you: > > > ------------------------- snip ---------------------------------------------- > > I've just considered the cases we have to handle: > > 1st ASSP: > > ASSP needs a traffic shaper (is this possible in Perl without causing high > load? Otherwise we have to implement a interface to a system included one). > > For recognition of spammers we should implement two mechanisms: > > 1.) Check if a remote-SMTP tries to contact a lot adresses which do not exist This is definitely in the works. > 2.) setting up random addresses with common usernames for the domains. That > way we get honeypots to analyze spam mails. From that we can create md5sums > for Razor and Vipul, which we can use to filter mails from trusted > remote-SMTPs (e.g. big providers). That should fit well with what's being built now. > Behaviour: > > 1.) Trusted hosts - which means white-listed ones or hosts providing fixed IP, > SPF (and in future DNSsec) should not have any restrictions. Yup, > 2.) Unknown hosts and hosts from 1.) which deliver more than 25% spam mail > should be throttled to a speed which is still usable for Email but slows down > things. Yup, > 3.) Verified Spammers (RBL, honeypots, ...) should be throttled to 500 > Bytes/sec and tar-pitted for 72 hours (by tuning SMTP-headers). ...and Yup. Right now the design allows each session to have its own unique parameters (effective bps, tarpitting behavior, etc.), but I don't know if that is going to be useful. I tend to mentally categorize sessions into three groups similar to those you mention above, and odds are that's how a default implementation is going to behave (replacing all the numbers above with configurable values). If anyone has a different take on this (as in, "more categories that good,unknown,evil"), I'd love to hear it. > 2nd Honeypot-Client: > > The Honeypot client should run on workstations as a daemon and emulate a open > SMTP-relay. As workstations usually have dynamic IPs, the spammers cannot > blacklist them ;-) Hahaha! So they strike themself (If you fight an enemy, > never waste your own resources but use his!). > It should throttle any incoming connection on port 25 to 500 Bytes/second and > tar-pit it like described for ASSP. But as spammers test the open relays, the > single mails - lets say 20 per 180 seconds from a remote host, should not be > restricted but sent and hashed with md5sum for Vipul and Razor. ...and report the sender IP to TarProxy, of course :) What honeypots exist that can be used for this? - Marty -- Marty Lamb Martian Software, Inc. mlamb at martiansoftware dot com ---- : The tarproxy-list mailing list is archived at : http://www.mail-archive.com/tarproxy-list%40martiansoftware.com/ : : To unsubscribe from this list, follow the instructions at : http://www.martiansoftware.com/contact.html : : TarProxy's project page can be found at : http://www.martiansoftware.com/tarproxy
