The customers seemed to have been infected with some sort of trojan/virus that opened up the SOCKS port via a program in the Startup folder called befy.exe, which was trying to propagate itself. We eventually cleaned up their systems, but what amazes me is that one person on an ADSL link and another on a dialup could effectively deny our other customers access to their Web mail through this simple sequence.
There's all kinds of very difficult nastiness coming from DSL and cable links these days, even from dial-ups. It you want to protect your server, block access from "subscriber" IPs, if you can.
Further investigation with a simple Perl script (attached) shows that if I try to relay through the IMail server from an IP that is not allowed to, then SMTPd32.exe takes a little amount of time to respond. During the wait, it spikes up to 100% CPU usage... repeat this constantly and you get an effective DoS.
Imail has to query
1) the registry to learn which domains are IMail domains (I bet list could be kept in memory
2) the ACLs for relay-for-addresses, for deny-IP, etc (potentially too big for memory)
3) the etc/hosts file to learn which @recipient.domains to relay for.
I also tried repeatedly sending to _local_ domains, with addresses that don't exist, but these get an immediate response and little effect on CPU usage.
to validate a user for a localdomain is an access to the registry since the entire list of users wouldn't be kept in memory. But access to the registry, a balanced B-tree (at least it was at one point) should be at most two disk accesses)
It seems to me that if the domain is not local, then IMail is doing some sort of intensive check when a RCPT TO: command is issued. Is there any way around this problem?
That's pretty deep inside SMTPD on a critical code path, only Ipswitch could answer. There aren't any admins knobs you could twist.
Some other MTAs will do things like prevent the client from sending for x seconds between each RCPT TO: after a certain threshold has been reached, in order to slow spammers who scan domains using this technique.
aka tarpitting. There's not much tarpitting available in Imail. Look in the IMail u/g "configuring SMTP server".
If something like this was implemented for IMail, it could reduce the effects of an attack. Perhaps another option is to reduce the process priority of SMTPd32.exe so that more interactive processes can preempt it.
Most MTAs run the SMTPD process at the highest priority, preferring to receive mail over any other MTA chore (although intelligent MTAs detect when receiving mail is out of balance with unattempted mail in the queue and then prefer receiving less).
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/
