Yes, this is doable I guess. But with Declude in place, Postfix isn't really doing much for me. My point was that this functionality should have been put into Imail to begin with. Perhaps the next version of Imail will add tarpitting controls. Merak, as well as many others I am sure, have had this for some time. And I believe it is one of the biggest contributing factors to the growth of spam on the internet.
Thanks for the info though. -- Scot ----- Original Message ----- From: "Tom Baker|Netsmith Inc" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, November 15, 2003 5:46 PM Subject: RE: [Declude.JunkMail] Dictionary attacks and Postfix > > Little OT for this list, but anyone using postfix as a gateway should have > this setup by now! > > > > http://www.smartbusiness.net/imail/ > > Use the above utility to export your userlist from IMAIL to a test file > every few minutes. > > I have attached (Imailexport.zip) an example of what I use to export my > userlist and FTP it up to my postfix box. I have the .cmd file scheduled to > run every 3 minutes to keep it up to date. > > On the postfix box I have a script in crontab that runs every minute.. > ( attached as postfix-import.sh.txt). > On postfix box I created a user 'imail' which the 'imailusers.ftp' file > contains the login info for. > > *Note: the postfix script calls /usr/bin/win2unix which probably doesn't > exist. It's a quick script I wrote to remove the cr/lf whatever windows has > that unix doesn't use. There are lots of examples out there on how to do it > also. > > Once you have the above in place you end up with > /etc/postfix/to_relay_recipients.map > Which hash's to to_relay_recipients.map.db > And postfix now has an up-to-date list (within 5 minutes) of all the users > and aliases that IMAIL has. > > Then edit your /etc/main.cf with > relay_recipient_maps = hash:/etc/postfix/to_relay_recipients.map > > And enjoy the saved BW & CPU cycles of not having to deal with all those > annoying bounces. > > > Then if you want to help against dictionary attacks write a script to watch > /var/log/maillog and once a treshhold is crossed of 'unknown user in relay > recipient table' from a single IP blacklist it. (either via another .map or > an ipfw rule) > > > > -----Original Message----- > From: Scot Desort [mailto:[EMAIL PROTECTED] > Sent: Saturday, November 15, 2003 3:37 PM > To: [EMAIL PROTECTED] > Subject: [Declude.JunkMail] Dictionary attacks and Postfix > > Over the last week, as we moved one of our larger email domains over to our > Declude server. I have been doing ad-hoc research of our IMAIL and Declude > logs looking for patterns in email coming in. > > When we first started to investigate anti-spam solutions, I was leaning > towards a gateway server sitting in front of Imail, similar to IMGATE. I > built my own Postfix box and basically configured it very similarly to > imgate. Initially, we listed many RBL's in Postfix. But it became clear that > Postfix (without the use of an external scanner like SpamAssassin) was > becoming a problem because a message would be rejected if it failed only ONE > RBL test, since there is no native method to use cumulative scoring with > RBL's without using something like SpamAssassin. As we all know, rejecting > on the basis of a single RBL failure yields a very high FP rate. > > As time progressed, we removed many of the RBL's from Postfix. We still have > Postfix sitting in front of Imail, but it's primary purpose is to do some > attachment filtering (.exe, .pif, .scr etc), as well as the equivalent of > Declude's REVDNS, MAILFROM and IPNOTINMX tests. > > Now that we have Declude running, the usefulness of the Postfix gateway > seems limited. And in actuality, it might be increasing our total email > volume entering Imail. This is because Postfix acts as a front end > gateway/relay server for a domain. Since Postfix does not have access to the > Imail user database, it accepts ALL incoming email to a domain that it > handles relay for. Now, if I understand spammers (or more specifically, > email address harvesters), they are in the business of selling email > addresses. The cleaner their databases are, the more money they make. So, > one of these harvesters sends a dictionary attack to one of the domains that > our Postfix server relays for. Postfix sees the domain as a relay domain, > and accepts EVERY single incoming email address for that domain. As far as > the harvester is concerned, Postfix has now validated every single email > address in the attack. Now, Postfix does it's thing, and forwards the email > to Imail. Now Imail processes each message and rejects those addressed to > invalid mailboxes. But at this point, it's too late. The harvester has > closed his SMTP connection to Postfix and as far as he is concerned, every > single one of the addresses is valid. Imail simply bounces the bad messages, > which is obviously a waste of time since the bounce address is most likey > invalid also. > > While Postfix may be reducing a small percentage of email from reaching > Imail when it fails some of it's own tests, it is my belief that Postfix is > actually increasing the amount of email being sent to Imail by validating > every email address coming into it as part of a dictionary attack. I think > Ipswitch needs to add dictionary attack prevention to Imail. MerakMail does > this, and the control they give you over the process looks pretty good > (http://www.merakmail.com/Knowledgebase/261.htm). I was shocked to find out > that Ipswitch did not include this functionality when version 8 was > released. For us, dictionary attacks represent the highest volume of > incoming email to our servers. > > To combat the lack of this functionality, one could do some cumulative > analysis on your Imail logs, identifying the IP addresses that are sending > the most email to invalid email addresses, and adding those addresses > manually to your Imail kill file. I suspect that this would yield some > relief. But I think the key is detection while the attack is occurring. A > kill file doesn't help you when a harvester gets a nice, shiny new IP > address that is not in your kill file and not on 5 RBLs. But detection > during the attack would auto-blacklist that IP for you without any > intervention, and thus immediately decrease the email entering Imail. > > I could be wrong. Perhaps I don't have a full understanding of how address > harvesting works. Perhaps the harvesting software is "smart" enough to know > that if 100% of the attacked addresses are accepted, that there must be a > relay server in front of the true destination server, and it voids the > attack? Does anyone have any thoughts on my theories? If I am wrong with my > logic, please let me know. I think I am going to do some MX record changes > this week and remove Postfix from one of the domains. It may take a very > long time for me to notice any change in the email volume, as the harvesters > clean their databases with my new Imail rejects in the SMTP envelope. > > The issue for me is not so much whether or not the Imail-accepted messages > are later caught as spam. It's the fact that these attacks eat up bandwidth, > consume so much of the resources of Imail, and therefore, the resources of > Declude. Even if Declude catches 99% of them, look at all of the work Imail > and declude had to do, when the incoming IP could have been blocked right at > the start when the attack began. It's just not practical (nor necessary with > today's technology) to have to maintain Imail IP blacklists manually. > > </end_of_rant> > > -- > Scot > > > > --- > [This E-mail was scanned for viruses by Declude Virus > (http://www.declude.com)] > > --- > This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, > just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe > Declude.JunkMail". The archives can be found at > http://www.mail-archive.com. > > --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.
