Actually there is only one SMTPD process running at any one time...It is the SMTP sender that you can adjust the number of processes to be used
Eric S ----- Original Message ----- From: "Len Conrad" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 02, 2003 5:51 AM Subject: Re: [IMail Forum] Anti Spam issues in Imail 8 > > >All along the spam consists of emails to unknown > >email addresses at our domain. > > This is the easiest for Imail to resist since the msgs are not received but > rejected after the RCTP TO: command. Your Imail box cannot keep up with > the attack? Probably not, because the attack would consume the limited > number of Imail SMTPD processes available, about 30 processes by default. > > You could try to outrun the attack by increasing the number of Imail SMTPD > processes, to offer more processes than the attack can consum, (this is how > IMGate does it). But you would have to increase to 200 or 400 Imail processes. > > In fact, "outrunning" the attack is about the only tactic available when > the attack is coming from so many IPs, making it hard to impossible to > block the IPs at TCP level. > > >As a first attempt we moved the domain for an > >hour or 2 to test it on the server running Imail > >8 and then moved it back to Exchange as we ran > >into a few problems. After we removed the domain > >off the IMAIL server, the logs show that email > >is still coming in to non-existing users of that > >domain. I assume the spam is being sent to the > >servers IP and not the domain anymore. > > The remote mail servers are using DNS to find the MX and A records of the > domain, and DNS will cache the A records for typically 1 day, so those mail > servers will keep sending to the old IP until the A records expire from > cache. > > >I had tonnes of these records in the log. To > >check how the mail server responds I sent an > >email to a nonexistent user at a nonexistent > >domain after creating necessary dns entries for > >it. It seems for all these junk mails coming in > >the mail server sends a reply back to each one > >of them > > If the user is unknown to IMail, Imail will return "550 unknown user" which > is not a new message, just an SMTP response code. > > >My questions > >a) Is there any way to delete these emails for a > >NonExistent domain > > The msgs are NOT received when Imail says "invalid user" so there's nothing > to delete. Imail is NOT sending back delivery failure notice messages. > > >b) Why does the mail server not do any > >validation / DNS blocklist search on these > >emails. > > You have to setup the anti-spam rules in Imail, but that won't work in this > case. Since the msgs are to invalid users, Imail is already effectively > doing the best it can, in the most efficient way, to reject the > attack. The "rule" that Imail is using is that it refuses mail to unknown > users on local domains. > > > It has been configured to do that and > >reports that in the log for another valid domain > >( everything from Reverse DNS, MAIL FROM, > >HELO/EHLO and the subsequent lookups at the DNS > >lists ). it appears that sending mail to a > >domain that doesnt exist is an easy way to > >achieve NDR spam. > >Unless I can figure out I cant see the point of > >moving to IMAIL 8. > > Imail of any version wouldn't help here. Every IMail version already does > what your IMail is doing, with the same (in)efficiency. > > >Please help. > > This kind of situation (and everybody has to expect that he will see this > kind of attack sooner or later, to lesser or greater severity, for > shorter/longer duration) is extremely difficult to defend against. > > The best insurance and defense is not to expose you mailbox server to > Internet as MX but to run a defensive machine in front of Imail like > IMGate. I have recently seen an IMGate box of 850 MHz reject 70K msgs/hour > to unknown users, and over 1 million rejects/24 hours with no ill effects > on IMGate, while the mailbox server was untouched. The attack has persisted > for 2 weeks, with 300k to 600K rejects/day. > > If you were running IMGate, you IMail server and your users would continue > untouched by the attack. In fact, you would have to do nothing during the > attack, other than throw your head back and laugh at the futility of the > attack. > > So, there's nothing you can do at the IMail level. See the Imail manual or > IMail on-line knowledge base about how to increase the max number of Imail > processes (but do not be surprised if this does not work). > > About the only tactic you have is to harvest the IPs from the Imail logs, > count up which 50 or 100 or 1000 are the most aggressive in repeatedly > connecting to Imail and block those IPs at your router. This will PERHAPS > give you some temporary relief so that legit IMail traffic can pass in and > out. > > But, you will have to repeat this hourly since the set of attacking IPs > will be constantly changing. And as you block 50 or 100, then another 50 > or 100 will take their place. The idea is to keep several of IMail > available processes open for legit mail. Again, don't be surprised if this > tedious tactic doesn't work, since Imail's 30 processes is a small number > to consume by the attack. > > The attack could stop in a few minutes, or continue for days, or weeks. > > The only real defense is to block the attack before it arrives at IMail, > with a box like IMGate. > > btw, I have been seeing more and more dictionary attacks, of higher volume > and lasting longer. I expect the spammers are getting desperate to meet > their delivery target as more mail servers mount better defenses, making > the spammer job harder. > > Note the worst attack I've seen was apparently a malicious attack to bring > down one ISP's 3 different mail servers in 3 different locations, all with > different domains. Somebody apparently wanted to shut down the ISP's mail > operation. The ISP never paid me for my services, and I later learned this > was not uncommon for this ISP, so that confirms my suspicion that this ISP > had made enemies who were probably behind the attack. IMGate saved the > day, but the attack was consuming 200 to 350 STMPD processes on IMGate (we > had 400 available, so we outran the attack) > > Len > > _____________________________________________________________________ > http://MenAndMice.com/DNS-training: Seattle; Chicago; San Jose; Wash DC > IMGate.MEIway.com: anti-spam gateway, effective on 1000's of sites, free > > > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html > List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ > Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/ > To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
