MAILCORRAL FEATURES

This section gives a comprehensive list of all of MailCorral's features:

• Stops viruses and spam before they ever get to the recipients. This can reduce network traffic (for spam) and guarantee that a virus will not get launched by mistake.
• Filters all plain text and MIME components of the message, including inline MIME components.
• Removes harmful inline HTML, including that embedded in plain text and renders harmful attachments innocuous (by renaming or deleting).
• Decodes all encoded plain text and HTML MIME components to find viruses and spam hidden by encoding.
• Can filter all messages or only those from outside.
• Optionally, can send virus detection reports directly to the postmaster.
• Has built-in, fast, black and white list processing as well as a statistical identifier for spam.
• Can invoke the popular SpamAssassin spam arbitration daemon, using the built-in interface, to determine if a message contains spam.
• Only the message body (not attachments) are passed to the spam arbitron. For large attachments, this results in a significant speedup.
• The built-in black/white list processor and statistical identifier can act as a fast path front end for the spam arbitration daemon, giving at least a threefold performance improvement for domains in those lists and messages that meet the statistical tests.
• Has built-in, rules-based, simple virus detection.
• Can invoke external virus identifiers, such as ClamAV), to determine whether message components contain a virus.
• The order of invocation plus the interpretation of the internal and external virus and spam arbitrons is programmable using simple logical expressions, by the user. Depending on return values, tests can be skipped to improve performance.
• The user may provide their own message classifiers and/or filters using a Perl shim that allows them to see and process some or all parts of each message.
• Filtration messages are given in plain language, inline, in the message received.
• The text of filtration messages is configurable in the global configuration file as well as on a per-user basis.
• Foreign language support allows filtration messages to be displayed in any language, also selectable on a per-user basis.
• Message filtration, spam filtration and message disposition options are settable on a per-user basis. Permits tailoring of the filter's actions for each individual message recipient.
• Configurations for both real and virtual users are supported through local configuration files or a DBM database.
• Retains a copy of all filtered (i.e. altered) mail for a set period of time (chosen by you), just in case filtering renders it unusable. No need to worry about the consequences of filtering.
• Three delivery modes are possible for spam: deliver it but tag it as such in the subject; put it straight into the trash; sideline it in the corral for possible later delivery.
• Spam that is not delivered but corralled instead may be remailed using BSM Development's SpamCorral or simply deleted on a periodic basis.
• Spam may be automatically replied to with a rejection notice or silently discarded.
• Rejected spam uses a pacing mechanism that prevents the ping ponging of rejections, rejection rejections, etc. Once a spammer's periodic quotient of rejection notices are sent, further spam from them is silently discarded. You pick the pacing threshold and period.
• Using SpamCorral users can be sent periodic (usually daily) summary notification of all spam received and corralled in that period.
• As a result of notification, users can release any spam they want to see, from the corral, for remailing to them. Important spam (is there such a thing) or mistakenly labeled spam is not lost.
• Directly delivered and remailed spam is tagged (i.e. "[SPAM]") in the subject so that it can be easily separated by recipients (e.g. a subject line filter can send it to a special mailbox).
• Two modes of message archiving are available: email to a third-party archive program; or direct archiving.
• We provide a simple email-type, third-party archiver.
• Can be directed to look for bounceback messages from a non-functioning archiver and delete them silently. This prevents the original sender from seeing archiver bounceback messages, a good thing since most of them have no clue their messages are even being archived, let alone why they're getting bouncebacks.
• Direct archiving can simply store the archived messages in a directory tree or it can index them in a MySQL database.
• We provide a simple post-indexer for indexing archives after the fact.
• Robust code - runs reliably, without human intervention.
• High performance - written entirely in C and completely reentrant.