> > You'll be automatically blocked for a day if you send us more than > > a (low) amount of non-existant recipients (which easily happens if... > > nice concept, should be quite practical against dictionnary
Exactly, this was the prime reason for coming up with it, because I was just sick of watching those guys essentially taking a dump of our email configuration without us being able to do something about it. > attacks. Have you implemented that by yourself, or was it already > a feature of your MTA ? And what kind of blocking art, if I may > ask: 4xx, 5xx or even iptable rule? It's a custom modification to sendmail-8.12.10. My recent conversion of the previous berkeley-db based approach to a central MySQL db for storing the records of violating IP addresses is now in field trial on two of our mail servers. If nothing goes wrong I should have all of them on the new code by the weekend, and I'll then also publish the code. Just as a quick summary: - the modification triggers an insertion of a record into the database with an expiration date and some detail information which comes in handy for later analysis. It also kicks the current session out with a 421 error (this is RFC compliant behavior). Timeout and thresholds are configurable. - the normal configuration file does all the rest. The check_relay function uses a map (backed with the same MySQL table) to determine whether the incoming call should be blocked, and if so, it is rejected using standard sendmail mechanisms. - there's support for whitelist entries that will never be blocked (but sessions will still be dropped upon violation of the criteria) > I'll try to setup the same kind of system for our servers > (qmail-vmailmgr & qmail-ldap based). Don't know these, but what you need are these components: - some place to wedge into your mail server where it counts the number of failed recipients. Perhaps (as sendmail does) it already has a feature to throttle (insert sleeps/delays) when exceeding a specific amount of failed recipients. That's a very good place to do more than just complain. - some generic way of performing a map-/table-lookup for incoming connections, whether those should be allowed to proceed. - we also use LDAP based mail routing internally, but I deliberately decided against putting these records into LDAP because LDAP sucks at write performance, and there can be potentially tons of inserts if one of the guys with a distributed spam network starts a mailing. This was the prime design decision to use MySQL for this purpose. Cheers, Markus -- VIA NET.WORKS (Schweiz) AG Riedstrasse 1, CH-6343 Rotkreuz, Switzerland Telefon: +41 41 798 2121 / Fax: +41 41 798 2122 Markus Wild, Manager Engineering, e-mail: [EMAIL PROTECTED] ---------------------------------------------- [EMAIL PROTECTED] Maillist-Archive: http://www.mail-archive.com/swinog%40swinog.ch/
