MailCorral FAQ


This document contains a list of frequently asked questions pertaining to the sendmail filter, MailCorral, its installation, configuration and operation. These questions, posed by our users, are answered herein to assist you with any questions that you may have about this product. Please contact BSM Development if you don't see an answer to your question.

Local Mail Delivery

How is mail delivered to virtual users?

What does "-D" or "DomainList" really do?

Why is mail to external users sometimes filtered?

Filtered Items

Why did a particular item get filtered/not filtered?

Planning

What kind of a system load can I expect filtering to impose?

Configuration

What happens to configuration changes during updates?

Installation

Why doesn't install find the sendmail source?


How is mail delivered to virtual users?

Q.   A piece of email is received that is addressed to "sales@abc.com". Since "sales@abc.com" is in the virtual user table, mapped to a local user but "abc.com" is not in /etc/mail/filter-domains (which is pointed to by the "-D" option), is the message passed through untouched?

A.   Any local email that is received from external users is always filtered. Local mail received from internal users is also filtered, if the "-i" or "FilterInt" option is set. Virtual users that are mapped to local users are treated exactly as all other local users so their mail is filtered, despite the "abc.com" domain not being in the table pointed to by "-D".

Q.   What is the whole story about how sendmail and the filter treats virtual users, local users and aliases?

A.   Sendmail looks up a recipient's address in "/etc/mail/virtualusertable" (or its equivalent) before it does anything else. By the time the filter is called, aliasing via the virtual user table is already done and any addresses therein appear local, for all intents and purposes. Sendmail looks up a recipient's address in "/etc/mail/aliases" (or its equivalent) at the last moment, before it delivers the mail, so that aliasing via the alias list isn't done when the filter sees the message.

The filter looks up local mail addresses in two places to determine if mail to them is deliverable. Firstly, it tries to resolve the name in "/etc/passwd" to see if the user exists and has a home directory (the criteria for actually delivering mail). If this test fails, it looks in any alias list, pointed to by the "-A" or "AliasList" options, to see if the name is a valid alias. It this test fails, the local mail is deemed undeliverable.

What does "-D" or "DomainList" really do?

Q.   If the filter automatically knows whether a user is local or not, what is the purpose of "-D" or "DomainList"?

A.   The file given by "-D" or "DomainList" (typically "/etc/mail/filter-domains") is used in addition to the automatic local address determination that sendmail and the filter make. If an otherwise external name is in the domain list given, it is treated as local and it will be filtered whenever a local address would be. This may be useful in wide area networks where several domains exist, some of which are not local to the particular machine doing the filtering. Never-the-less, these domains should be treated as local, for obvious reasons.

Why is mail to external users sometimes filtered?

Q.   It appears that mail to external users is sometimes filtered incorrectly. Why is that?

A.   Sendmail only gives the filter one copy of a message to filter. If the message is addressed to both internal and external users, the wishes of the internal users take precedence. Whether they want the message filtered and how decides what the filter does. Once the message is filtered, the result is delivered to all recipients, including the external ones. So, the non-local users sometimes get their mail filtered (bonus). Note that any corralled spam/mail is saved under the fully-qualified name of the recipient so that it can be delivered if it is ever released from the corral.

Why did a particular item get filtered/not filtered?

Q.   I received a message with an attachment that shouldn't have been filtered (e.g. ".jpg"), yet the filter flagged it as an obnoxious item and filtered it. Why is that?

A.   The sender of a MIME encoded message is responsible for ensuring that the message conforms to the MIME RFCs. Unfortunately, the last thing the sender of a virus is, is responsible. Consequently, many viruses use malformed MIME entities to try and slip their payload past virus filters. Spammers might employ the same kinds of tricks for similar reasons.

If a mail reader is promiscuous (i.e. willing to accept malformed MIME entities, usually in the interests of being forgiving), they might interpret and accept malformed MIME entities that could be harmful to the recipient. Consequently, the filter errs on the side of caution and rejects such items.

One trick that can be used to fool a filter is to send a MIME entity with two attachment names, the first being an innocuous one and the second being a harmful one (or vice versa). If a promiscuous mail reader accepts the wrong one (theoretically, a MIME entity with two attachment names should be rejected), compared to the one used for filtering, a virus could slip through the filter. In this case, the filter picks the worst case and filters according to its rules. For example, if a name of ".jpg" and ".doc" is sent, ".doc" will be used, since it is more restrictive. Even if the mail reader will use the less harmful name, the filter doesn't know this so it filters the attachment anyway.

What kind of a system load can I expect filtering to impose?

Q.   I'd like to know how much load filtering will impose on the system so that I can decide whether or not to upgrade my mail server. What can I expect?

A.   We usually expect a 25-45% increase in the system load, when filtering is added. The filter itself usually accounts for 15-20% of the CPU and the typical spam arbitron (e.g. SpamAssassin) usually accounts for 5-10% of the CPU. The virus arbitron can account for another 10-15% of the CPU.

If you have already added filtering to your mail server and you are curious about when to upgrade your system, you might want to do so if the users start complaining about crummy performance. Our experience has been that load averages are a good indicator of performance issues. Low numbers generally imply that the performance will be good. Consistently high numbers imply that it will be bad. As a rule of thumb, load averages of 1.5-2 are usually fine while numbers higher than that may not be (however, your mileage may vary, depending on system configuration).

Be sure to check your system's load averages over various time periods but especially during peaks (e.g. mid-morning, mid-afternoon and early evening). Plan you CPU capacity for the peak periods and, if you are upgrading and it is possible, get a machine that is at least twice as big, to allow room for growth.

Q.   So, what are load averages, anyway?

A.   The load average numbers give the average number of jobs in the run queue over the last 1, 5, and 15 minutes (these three time periods may vary from one Unix/Linux system to another, but are most often 1, 5 and 15 minutes). In other words, the n-minute load average is the number of processes competing for the attention of the processor(s) at any moment, averaged over n minutes.

What happens to configuration changes during updates?

Q.   I've made a number of changes to the "smfopts.h" file. What happens to then when I update to a later release of MailCorral?

A.   The configure script should keep any changes that you made to smfopts.h. It applies a diff to "smfopts.h" to bring it up to the next level without wiping out your customizations. There is, of course, the possibility of a collision but, since the majority of the changes to smfopts.h are to add new features, it is very unlikely that a collision will happen. If one does occur, the "smfopts.h" file is not updated and, instead, "smfopts.h.new" is created. You can then manually apply your changes to this file or vice versa.

Why doesn't install find the sendmail source?

Q.   I ran the configure script and then tried to build the filter with the makefile. It doesn't seem to be finding the sendmail source in the correct location.

A.   The configure script tries to determine where the sendmail source is likely to be, based on the current directory and the type of platform on which the filter is being built. Sometimes, this works well and sometimes it doesn't. To ensure that the correct sendmail source directory is used, you should use the "--with-sendmail" flag when you run configure. For example:

./configure --with-sendmail=/home/joeblow/sendmail/sendmail-8.12.3