|
| | | Junior Member
 
Group: Forum Members
Last Login: 10/23/2007 9:11:09 AM
Posts: 14, Visits: 7 |
| Hi all...
I've already let IPSwitch know about this bug, but I wanted to detail the steps to reproduce it in the hope that IPSwitch will fix it quicker, and so no other IMail users fall into this trap. We found this bug by trying to set up a rule in IMail to copy all messages that have been stripped of banned email attachments to an email administrators mailing list.
The bug is such: Under certain circumstances, an IMail Server (we're running 8.2.1) can be made to "bomb" users by sending a SINGLE, small email to a mailing list; the server then sends out thousands upon thousands of messages to the users on that mailing list. This also has the added effect of draining the server's resources. If the mailing list contains users on other domains not hosted on the IMail server, then those domains *may* see you as a spammer, sending all those thousands of unsolicited emails. Here's how to do it (so DON'T do it):
1. Create a mailing list. For this example, we'll call it mailing list "A".
2. Add some users to the list. These users can be users on the IMail server, or they can be users on other domains. For this example, we'll add users "1", "2", and "3" to list "A".
3. Create an INBOUND rule for the entire domain hosted on IMail stating that if any message body contains the text "This is a test", IMail should COPY the message to mailing list "A".
We now have everything we need to really cause a problem with the server.
4. Go to any email client and create a new email message containing the body text "This is a test" (note that this is the same text that we added to the rule in step 3 above). Address the message to mailing list "A" and send it.
After a few moments, everyone on list "A" (users "1", "2", and "3") begins to receive hundreds, and then thousands of email messages. Apparently, IMail gets stuck in some kind of "loop". Removing the inbound rule does *not* stop the loop. Stopping and starting IMail services does *not* stop the loop. Rebooting the server does *not* stop the loop.
We were pretty panicked. Out administrators were receiving thousands of copies of the ONE message sent the mailing list, and the server itself was bogging down. Thanks to IPSwitch's tech support, we were able to stop the loop by doing the following:
1. Stop the SMTP and Queue Manager services.
2. Rename IMail's SPOOL directory (located in the IMail program folder) to oldSPOOL and create a new, empty SPOOL folder.
3. Restart SMTP and Queue Manager.
This kills the loop, but also stops any pending, legitimate email from being delievered that may have been present in the old SPOOL directory. However, we were able to isolate which messages belonged to the loop by looking at file extensions. Since we have very little mailing list traffic, we found that by deleting every file with an *.LST extension deleted most of the pending loop messages (and there were a few thousand of them in there). We also found that by removing mail list "A", we were able to tie up the loose ends to ensure that the loop was stopped.
4. Open the oldSPOOL folder and delete all files with an *.LST file extension.
5. Delete mailing list "A".
6. Stop the SMTP and Queue Manager services again.
7. Rename the new SPOOL folder to new_oldSPOOL and rename the oldSPOOL folder back to SPOOL.
8. Restart the SMTP and Queue Manger services.
9. Go to Local Host in the IMail Administrator application and click the View Queue button. Delete any remaining messages destined for the the old mailing list "A".
10. If the old mailing list "A" is needed, recreate it.
So, there you go, folks. Don't fall into this trap!! I'm hoping that IPSwitch fixes this soon, as this "bug" could be used in a malicious attack against an IMail server.
PS: My staff is still giving me guff about receiving 2500 emails :-) |
| |
|
|