IMFilter
V2.0 DetailsIMFilter
V2.0 DetailsIndex
License
Details
Quick Reference
FAQ
IMail, by IPSwitch, is an Internet E-mail server with a great many good features. One of these is the ability to do "global" rule based E-mail filtering. (See your IMail documentation for details.)
Many system administrators have started to put this feature to good use by filtering out Spam and occasionally Virus messages before they can get to their users. Unfortunately, on a large system, managing the files needed to make this happen can be a lot of work. If you have a system where you allow users to create their own accounts, or if you have a large number of users and domains, the extra work can become a real problem. That is why we created IMFilter.
IMFilter takes care of propagating your RULES.IMA files to the top-level directory for each of your domains, and the .FWD files for each user. It is fast, efficient, and has additional features to help take care of some additional problems that arise when you begin to filter E-mail for your users... For example, what happens when you want to exclude a user or domain from your filtering process? IMFilter helps with that too.
IMFilter is designed to work properly on Windows NT version 4 (Intel platform) with SP 4 or above and IMail server versions 5.04 through 6.01. The software _should_ be compatible with later versions of IMail, provided that the mail filtering mechanisms, directory structures, and use of the Windows Registry do not change substantially. Use of IMFilter on IMail versions earlier than 5.04 is likely to yield unsatisfactory results.
IMFilter is intended to run as a scheduled process using Windows NT's scheduler service (AT) or something similar. In addition, it can be run as needed from the command line, or as a program alias through IMail.
Some important features are:
- Works directly with IMail through the Windows Registry.
- Multithreaded, OOP design uses your computer's resources efficiently.
- Copies only newer versions of files to save time & minimize drive wear.
- Exclude individual users, domains, and directory trees as needed.
- Create multiple rule sets to alter your filtering for different domains.
- Discovers users even if they are stored in an external database.
- Can remove user directories for deleted users.
- Can be run from a different server if desired.
- UNC Path support.
The primary use for IMFilter is to provide global Spam and limited Macro Virus filtering for all (or most) of the domains on your IMail server. We have included sample files which approximate how this would be done.
To set this up, the first thing you should do is create a directory somewhere on your mail server where you will keep your Rule Set. In our example, we use the directory d:\filters for our Rule Set, but your installation will no doubt be different.
Please be sure to edit all of these files appropriately before using IMFilter.
You may even want to backup your system before running it the first time!
A Rule Set is the combination of files that will be applied to the domains on your IMail server. Typically, this will include a RULES.IMA file, one or more .FWD files, and an EXCLUDE.LST file. Please refer to your IMail documentation for details regarding the use of RULES.IMA and .FWD files.
When IMFilter is run with the -registry option (recommended), it will automatically copy the RULES.IMA file to the root directory of each domain on your IMail server. It will also copy the .FWD files to each user's directory.
In our example, our RULES.IMA file is set up to redirect incoming Spam messages to a mailbox called SPAMBOX, and incoming Virus messages to a mailbox called VIRUSBOX. Normally, this would cause IMail to create special mailbox called SPAMBOX in each user's directory the first time that they received a Spam message. Likewise, a mailbox called VIRUSBOX would be created if they received a message that was thought to contain a virus.
Note: Spam is unwanted, usually commercial e-mail,... Junk mail for the Internet.
Important: IMFilter DOES NOT detect and filter viruses! However, it is possible to set up your RULES.IMA file to detect some macro viruses by identifying the characteristics of the e-mail's that carry them.
Since the goal of our filtering system is to prevent these messages from getting to our users, this might be a problem. That is, the messages are still going to the users, but they are being segregated into special boxes.
Fortunately, IMail has a solution for this. If a forwarding rule is placed in the user's directory, such as SPAMBOX.FWD, then messages that might go into that mailbox will instead be rerouted to the location specified in the forwarding rule. This generally prevents IMail from creating a special mailbox for it in that user's directory.
In our example, we forward all of our incoming SPAMBOX and VIRUSBOX messages to our abuse account so we can monitor what is being caught by our IMFilter. Sometimes we might catch a legitimate E-mail which we would then move to the original user's mailbox. If we find that a particular rule is catching too many legitimate e-mails then we might remove it or modify it.
This causes us a small problem though... If our abuse account is processed by IMFilter along with all of the other users, then it too will have SPAMBOX.FWD and VIRUSBOX.FWD rules in it's directory which will prevent IMail from sending the messages to that account.
That's where the EXCLUDE.LST file comes into play. We add the abuse@microneil.com address to the EXCLUDE.LST file so that IMFilter will avoid adding the .FWD files to this user. This way, the abuse account receives the redirected e-mails from every other user on our system, and each message is redirected to the appropriate mailbox. Spam messages go into the SPAMBOX and Virus messages go into the VIRUSBOX.
Once we have all of the files set up in our Rule Set, we're ready to launch IMFilter. IMFilter can be run from the command line, or scheduled to run periodically using NT's scheduler service, or you can even run it as a program alias through IMail. In practice, you will probably use all three methods.
Use the program alias to do quick updates - for example, if you get word of a new macro virus, you can add a rule to your RULES.IMA file and then launch IMFilter by sending your server a message. Your quick response might save your users a lot of trouble.
Use periodic scheduling when you operate a system that allows users to create their own accounts. Every couple of hours or so (the time will vary with your needs) you can have IMFilter run to apply the .FWD files to all of the new users who have arrived since the last time IMFilter was run. This way, you can concentrate on the contents of your RULES.IMA file rather than worrying about which new users might not yet be protected.
Use the command line method for testing, or to make quick updates when you're at the server.
Hint: If you run IMFilter without any options, it will show you all of the command line options and their descriptions. This can save you some time when you're trying to work quickly.
The cleanup option works with the EXCLUDE.LST to reverse the previous effects of IMFilter. With the cleanup option set, IMFilter will compare the .FWD files in the current rule set with the .FWD files in the user directories being scanned. If a user is listed in the EXCLUDE.LST, any .FWD files found to match those in the rule set will be deleted.
This feature makes it possible to remove some of the effects of mail filtering from users which don't want their mail filtered even if they previously had filtering turned on. However, because of the way IMail handles global mail filtering, if there is a RULES.IMA file in the top level directory for that user, the messages which are caught by the filter rules will be segregated into special mail boxes for the user as defined by the RULES.IMA file. This cannot be prevented.
Hint: It is possible to set up your RULES.IMA file so that the messages it captures are simply deleted by using the NUL account. (See your IMail documentation) If you do this, excluding a user will have no effect except to remove previously copied .FWD rules - any message caught by a NUL rule will be eliminated.
The scrub option causes IMFilter to seek out and destroy any mail boxes that match forwarding rules in the current rule set. These mailboxes might be created if a new user is created under a filtered domain and a filtered message arrives before IMFilter has had a chance to copy the .FWD files to the new users' directory. With the scrub option set, IMFilter will not only copy the .FWD files to that directory but it will also delete any .MBX, .SRT, and .UID files that match the name of the .FWD file.
For example, if a mailbox called SPAMBOX exists for a new user, there might be a SPAMBOX.MBX, SPAMBOX.UID, and SPAMBOX.SRT file in the user's directory. If the scrub option has been set, and there is a SPAMBOX.FWD file in the current rule set, then IMFilter would delete the SPAMBOX.MBX, etc... files and would copy the SPAMBOX.FWD file to the user's directory.
CAUTION! If the user's mail client has had time to see the mailbox before it could be deleted, then deleting it with the scrub option might cause them to receive errors next time their client checks for messages. This is because the client will be looking for mailboxes that do not exist on the server. These errors are usually harmless, and they can usually be corrected by removing the mail boxes from the user's client.
The scrub option has no effect on users who are excluded in the EXCLUDE.LST file since they are not supposed to receive any .FWD files.
IMFilter also has some additional features to help out with managing your IMail server. One of these is the -wipedel option which will identify users that have been removed from your server and clean up their directories to save space.
This feature depends on IMail to identify deleted users. When a user is deleted from IMail, it will place a .DEL extension on the user's directory. IMFilter will search for these directories and delete them along with their contents.
If you are using an external database for your user data, you may need to delete user directories yourself, or at least mark them with the .DEL extension so that IMFilter can do it.
IMFilter is a multithreaded program. Each domain is processed in it's own thread. This means that if you have a powerful computer to run it on, you can get extra speed by increasing the number of threads that it uses. This can be useful on systems with more than one CPU, a lot of memory, and a fast hard drive system.
IMFilter's default is to use 5 threads, which means it will process 5 domains at a time until it is finished. This is usually sufficient. Values higher than 5 _might_ improve the performance of IMFilter on some high-end servers at the expense of available memory.
For example, if you were running a large number of IMail servers and you were using a different machine to run IMFilter using the DOMAINS.LST file, you might increase the number of threads significantly so that you could process all of the domains on all of your servers at the full speed allowed by your network and your processors.
If, on the other hand, you have a single system which is fairly small, you can tell IMFilter to use fewer threads. Even as few as 1. This can help if you are a little short on memory.
We recommend that you do not use this option unless you have a good reason.
If you are working in a very large production environment, or if you like to have more control over your rules processing, you might chose to use IMFilter in domain list mode. To do this, simply run IMFilter without the -registry option. This will force IMFilter to use the DOMAINS.LST file present in your rule set. Keep in mind that some of the EXCLUDE.LST functions, particularly those having to do with specific users, will NOT work properly in this mode. In general, if you want to exclude a domain from processing in this mode, you should remove the corresponding directory from the DOMAINS.LST file.
The benefits of using the domain list mode of IMFilter are that you can explicitly define the domain directories that will be processed, and that you do not have to run the IMFilter program on your mail server. This can be very helpful if you have a large number of different rule sets or if you are supporting a number of IMail servers.
For example, if you have 4 IMail servers, and one management console, you could run IMFilter from the console using the domain list mode and propagate your rule files to all of the servers at once. This also has the advantage of minimizing the load on your mail servers so that they can continue to concentrate on delivering mail and responding to web-messaging sessions without delays.
Of course, setting up your DOMAINS.LST file(s) can be a lot of work. IMFilter has a mode to do this for you. Run IMFilter from the command line on the machine where your IMail server resides using the -makedomainlst option as follows:
IMFILTER -makedomainlst d:\yourdomainlistfile.lst
IMFilter will scan the registry and produce a file that you can modify and then use for your DOMAINS.LST file. If you are running a number of IMail servers covering different domains, you can run the utility at each server and append these files together to create a master list.
Each domain's top level directory will be preceded with a comment containing the domain name. If you want to suppress these comments, add the -suppress# option.
We will offer support for IMFilter to registered users through a special mailing list. You will be subscribed to this list when you register IMFilter. We encourage all IMFilter users to share their experiences with us and the other users so that we can continue to improve the program. We will monitor this list and provide assistance and new information as often as possible.
To offer your comments or post a new question, send your messages to IMFilter@MicroNeil.com. If you have trouble, or if you would like to be removed from the list, please send a message to support@microneil.com. Be sure to include as much information as possible in your message.
IMFilter is a very powerful tool. If it is not used correctly, it can create a really big mess in a hurry. Be very careful about how you use IMFilter... you should treat it like you would DEL *.* - and if you don't know what we mean by that, you will want to be even more careful!
MicroNeil Research is not affiliated with IPSwitch in any way. We do not provide technical support for IMail or any other IPSwitch product, and they do not provide technical support for IMFilter.
Copyright 1999, MicroNeil Research, all rights reserved.