Plans For The Next Version


Sorry, this page has got very out of date. Until I get a chance to bring it up to date, I would ignore it if I were you. Sorry about that.

If there are any features you would like to be added, please email me and if enough people ask for it then I'll think about adding it.

This is where I put my thoughts, plans and ideas for future versions. The current version is not perfect, there are always improvements that can be made.

Change error messages for filename traps - Done

Make the message that is returned to the user different depending on whether the error found was a real virus or whether it fell foul of filename.rules.conf.

Make PrependHeader and AppendHeader work to the same spec - Done

Currently one of these functions inserts a "," and one inserts a " ". Need to make them work the same way, by providing an extra parameter containing the separator.

Handling Multiple/Split Spool Directories

Currently, I do not support the features of Exim and sendmail where you can split your spool directory into multiple directories. This is provided for large mail servers running OS's such as Solaris which grind once there are more than about 10,000 entries in a directory. It would be nice if I supported multiple/split spool directories for both the incoming and outgoing queues.

Handling the incoming queue is a matter of scanning many directories for the contents of the queue, and keeping track of the exact pathname of every file associated with every message. Handling the outgoing queue would be done by randomly placing outgoing messages into (appropriate) queue directories.

Winmail.dat Removal

It's a right pain for non-Outlook users that Outlook users keep sending attachments as winmail.dat files (i.e. TNEF encoding). It would be really neat if these attachments were automatically converted to proper MIME attachments so that everyone could read them. This would simply involve detecting a winmail.dat file, blowing it apart and reconstructing the attachment list as a bunch of normal MIME attachments.

Most useful for non-Outlook sites (most people) but may cause damage to Outlook users as we would almost certainly have to throw away all the directory information in the process. Is this a reasonable cost?

Scan/Skip Ruleset

There is some demand for a feature whereby the site administrator can setup what addresses have their mail scanned and what do not. This would allow, for example, a "virusmaster" to receive viruses unscanned, and also allow really paranoid sites to scan plain text messages as well as MIME messages.

I'm thinking about a ruleset file that would look something like this:

        DontScan  TextOnly       from * to *
        DontScan  All            from * to
        DontScan  All            from * to
        Scan      AlreadyScanned from to *
        DontScan  AlreadyScanned from to *
        Scan      All            from * to *
This would skip text-only messages, any mail to your virusmaster or postmaster, and anything from your mailing list server to off-site recipients that claims to already have been scanned. It will scan everything else. The supplied ruleset will be this:
        DontScan  TextOnly       from * to *
        Scan      All            from * to *

The questions are:

  1. Is this useful?
  2. Is this too complicated/not complicated enough?

Arbitrary Header Rules

Arbitrary regular expression rules need to be able to be applied to any header. This could be used to implement header length checks on MIME headers, date headers, etc where virus writers have written long header exploits. This can also be used to check for unprintable characters in the subject header, an old XTerm hackers trick. It can even be used to control spam by looking for common regular expressions within subject headers.

A similar configuration file could be used to the one used for filename rejection, except it would probably have the header name rather than the allow/deny keyword.

Julian Field