Chris Lowth's Home | Protector Home | Topic Index | Changes | Search

Using protector 1.00.6

Author chris@lowth.com
Date 16 February 2002

The protector program inserts itself (on installation) into the local mail delivery chain in a unix box equipped with sendmail and procmail (and some other SupportedPlatforms).

Every mail message that is delivered to a local user (including POP3 users of connected windows (etc) systems) of the system is piped through the protector program before being passed on to "procmail" for actual delivery. Protector scans the mail message for attachments, and passes each one it finds to a "part_filter" program for approval. This program checks the type of file contained in the attachment, and typically verifies that it is incapable of containing viruses, worms or other undesirable content. It does not (currently) perform a virus scan, but simply rejects file types that could contain viruses. Examples of rejected file types are..

For safety, the part_filter does not (logically) contain a list of types it will reject, but a list of types it will accept. This means that files of unknown (or: as yet un-handled) types dont get through. This "better safe than sorry" logic is deliberate, and means that the author and users alike dont have to play the continual "catchup" game that traditional virus scanning software requires.

The part_filter program is actually a shell script - making it (relatively) easy for systems administrators to modify the rules used to accept or reject mail attachments.

When the part_filter rejects an attachment, it replaces it with a warning message that describes the reason for the rejection, and archives a copy of the attachment (still encoded) in the directory /var/protector/rejects. The system administrator (root) can gain access to this archive in order to pass it on to the original recipient, if he manages to verify it's safety "manually".

The recipient of the mail message is alerted to the fact that protector has modified his (or her) e-mail, by a message like this in the mail..

        --- Warning message from your e-mail system's virus checker ---

        DISALLOWED TYPE

        This email contained an attachment of an "illegal" or "dangerous"
        type, so the system has replaced it with this warning message.

        This may seem like a nuisance, but please understand that it is in
        your own interests to avoid accessing email message attachments
        that contain viruses. Since it hasnt been possible to check this
        message for actual viruses, the server has taken the pessimistic
        but safe view that you are better off without it.

        If it is important that you are able to view the attachment, please
        speak to your system administrator, and ask for assistance. I will
        keep a copy of the original attachment in a "safe" place for a few
        days. You cannot access this "safe" folder, but your system
        administrator can - so speak to him (or her) about it. It would be
        appreciated if you dont ask for help in gaining access to cartoon
        animations and other "joke" files - keep the requests for help for
        real "important" stuff.

            Content-type: Application/Octet-stream; name="b15may00.doc"; type=Unknown
            Content-disposition: attachment; filename="b15may00.doc"
            Content-transfer-encoding: BASE64
            X-Discovered-Type: unknown/unknown
            X-Copy-Of-Original: 20000529.093015.1

At the tail end of this message, the attachment header fields are listed along with two new header fields generated by part_filter itself.

Currently, the system does NOT automatically alert the sender of the mail message to the fact that his mail attachment has been rejected - this option may follow in a future release.

Current approval logic

The current version of protector allows attachments of the following types through, and rejects all others.

In time, other types will be added to the "allowed through" list - particularly as users and developers assist me by sending me logic fragments for handling them (see below).

Reviving rejected attachments

When "protector" rejects an attachment, it places a copy into the directory /var/protector/rejects, where it is held for 50 days (to change this timer edit the file /etc/cron.daily/protector after installation, or "daily.sh" before). The name used to hold the file consists of the date, time and a "salt" number, in the format HHMMSS.Salt, and is listed in the modfied mail beside the header "X-Copy-Of-Original". This copy is in the "as transmitted" format, which is usually something like "base64".

To turn the rejected file back into it's original format, the "revive" utility can be used, like this..

    revive 20010727.091352.1 pictures.zip

The first argument to revive is the name of the file in /var/protector/rejects (as listed against X-Copy-Of-Original), and the second argument is the name of the file to be created. Note that the for security reasons, the directory /var/protector/rejects is accessable only by root - which means that only root can run this command.

Help wanted

In developing a product such as this, I am limited to working with the types of files that I and my immediate circle of users routinely see. If the product is to find wider acceptance, the library of "accepted" file types needs to grow. If you are a developer or systems administrator with enough understanding to add to the list of "accepted" types yourself, please will you send me the results of your work so that I can include them in a future release for others to enjoy. The only rules I impose here are..


  All material on this page, and the "protector" software to which it relates is Copyright (C) 2002 by Chris Lowth. "Protector" is free, open source software, licensed according to the terms of the GNU Public License