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).

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).

• Unix 5.4 (and UnixWare? 2.1) package data streams. Why include this one in an early release? Simple: At the time I was working on this part of the system, I used them a lot!

• Unix 5.4 (and UnixWare 2.1) package data streams. Why include this one in an early release? Simple: At the time I was working on this part of the system, I used them a lot!

%META:TOPICMOVED{by="chris.lowth" date="1025270442" from="Protector.DocGuide" to="Protector.DocGuide100"}%

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

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).

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 tradition virus scanning software requires.

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.

%META:TOPICINFO{author="chris.lowth" date="1022793420" format="1.0" version="1.1"}% %META:TOPICPARENT{name="Documents"}%

Using protector 1.00.11

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

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..

• DOS (windows) executable (.exe, .com etc) files
• visual basic files (.vba)
• Microsoft word documents that contain macros
• .. etc ...

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 tradition 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.

• X-Discovered-Type contains the mime type of the attachment, as determined by the part_filter and it's helpers (its there as a debugging aid).
• X-Copy-Of-Original is the name that the archive copy of the file has been given, when stored in the /var/protector/rejects directory.

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

• Raw text files (mime type text/*)
• Files compressed with GZIP or BZIP2 - provided that the uncompressed file is also valid. Decompression is performed recursively, so you cant fool the system by sending a .exe file in a GZIPPED, BZIP2'ed file (for example).
• Files contained in TAR or ZIP archives - provided that the archive contains only one file (this limitation may be lifted in future), and that the unzipped file is also valid (see note above about recursive decompression).
• Multi media files of types image/*, audio/* and video/*.
• E-Mail notification mails (sub-attachments are also submitted back to protector for re-approval) of types message/disposition-notification, message/delivery-status and message/rfc822.
• MS Word documents - provided that they dont contain any macros (the test for this is currently rather crude).
• Unix 5.4 (and UnixWare? 2.1) package data streams. Why include this one in an early release? Simple: At the time I was working on this part of the system, I used them a lot!

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..

• That you accept that your code will be released under the terms of the GNU public licence - and that you follow those terms yourself - particularly if you "borrow" code from others.
• That you accept that I will submit your code to public scrutiny (in the form of a alpha or beta release) before "going official" with it, and may choose not to include in a release for what ever reason I wish (this will usually be because of security or other "holes" in the logic, which I will enter into discussion with you about before making my final descision).