A serious
security risk today is the propagation of malicious executables through email
attachments. A malicious executable is defined to be a program that performs
a malicious act, such as compromising a system's security, damaging a system
or obtaining sensitive information without the user's permission. . The project
provides a tool for the protection of systems against malicious email attachments.

Spam is widely recognized
as a growing problem. Internet research company estimates that by 2006 junk
emails will more than double, with the average user receiving 1,400 Spam emails,
totaling over 206 billion in the US alone. Present attempts to address this,
either through self-regulation by the direct marketing industry, or through
identification of known spammers, have been ineffective. An Active State study
found that only 2% of UCE (unsolicited commercial email) is guideline compliant,
and that only 31% of Spam is identified by the most common anti-Spam method,
real-time blackhole lists (RBL).

The current mail filters available face with many problems
such as:

· Integration:

The Mail Transfer Agent (MTA) and the mail filter are often
two totally different components and communicate with each other on a rather
higher interface such as IPC mechanisms provided by the operating systems. Hence
the resultant system is quite often a less-than-optimized solution to the problem.
Moreover there are several overhead concerns relating to this approach such
as operating systems efficiency and at times may dictate terms to the application
programs which even though built up by the best of the programmers fail to deliver
the desired effect.

· Flexibility:

Flexibility means the ability to quickly change the configuration
of the system. Many of the currents designs provide rather segregated approach
in configuring the system. This may lead to rather complex configuration mechanisms
as devised by the developer’s and may involve study of it. This work being pertinent
to the user often try to neglect this extra effort to be put in. Hence a general
approach should be considered in designing the system.

· Installation:

Installation implies creation of configuration files (daunting
task) so as to make the system work in the first place.

1.1.2 Problem Constraint

The system should be configurable at the server or at the
user’s workstation. This means it may be a tool for the system administrator
or the user.

It should provide a common interface to various problems such
as filtering incoming and/or outgoing mails depending on the sender’s address,
recipient’s address and the content of the mail.

Moreover it should even be possible to scan the attachments
for any illegal or malicious material.

The whole system should be designed in such a way that the
filtering process is carried out incognito to the communicating components.
Only the system administrator is informed of the activities of the mail filter.

Addition of or updation of the headers should be a configurable
attribute that can only be governed by the system administration.

1.1.3 Objective to be achieved

Anti-Spam Configuration Control:

The primary anti-spam features are as following:

a) Relaying
is denied by default: Relaying (transmission of messages
from a site outside your host to another site except yours) is denied by default.
This feature will stop spammers while using your host to relay spam but it will
not stop outsiders from using your server as a relay for their site.

b) Better
checking on sender information: - Refusal of mail if the MAIL FROM: parameter
is not fully qualified.

c) Access
database: - An “Access” database can be created to accept or reject mail from
selected domains. The access database can also be used to block sender addresses
based on the username portion of the address.

d) Header
Checks: - Mails can be rejected on the basis of the contents of the headers.
Adding a rule set call to the ‘H’ header definition command in sendmail.cf does
this.

If any message contains expugnable word then the
filter searches for that word using ‘grep’ command and after the search is
over, the filter should be capable of removing that word from the message.

The privacy option is used to limit the amount
of information offered to the outside world and to limit other kinds
of access. Encrypting the required message while sending does this and then
the received message is decrypted and read by the user.

Email addresses (or patterns) of users can be configured
to pass through the filter. Two separate lists are maintained: one is matched
against the From: header and the other against the to: header. The former is
used to allow people from filtered sites like aol.com to mail you. The latter
is used to ensure that the filter does not reject mail sent to you from mailing
lists.

If you are using Pine to read mails, you probably
notice that all your incoming mails go into a folder called INBOX. Using a mail
filtering facility you can automatically sort your mails according to the sender,
the subject, etc. into different folders called incoming folders.

Adding New Mail Filter: - The mail filters filter
incoming SMTP messages according to the “sendmail mail filter API “ documentation.
These filters can be configured in your mc file using two commands:

MAIL_FILTER (‘name’,
equates)

INPUT_MAIL_FILTER
(‘name’, equates)

The first command defines
a filter with the given name and equates. The second command performs the same
action as the first but also populates the M4 variable ‘confINPUT_MAIL_FILTER’
with the name of the filter such that the filter will actually be called by
the sendmail.

1.2Scope of Project

The project can be deployed in the fields where
security is one of the greatest concerns. Apart from this it can be employed
by the users who receive mail in abundance and whose management and later retrieval
causes blunder. Broadly, it can be effectively deployed in the following real
world instances

1. On
the mail server:

Policies can be binded on the mail server for a
user or group of users. The policies can be easily configured through a set
of user interfaces. This gives us a centralized approach for management of user
mail. Policies common to a group of users can be defined at this server without
any considerable overhead at the server and even if in case there is an overhead,
it is totally reasonable.

2. Tool
for mail administrator:

This can be used as an effective tool for mail
administrator where the administrator can bind policies specific to his network
or to specific user or group of users.

3. User
configurable:

Creating open source
solutions to provide virusprotection for end-users and corporate
users for use on their networks, i.e. email servers, internet gateways, or and
file servers. Creating open source solutions to provide computersecurity and network security for end-users
and corporate users for use on their networks, i.e. email servers, internet
gateways, or and file servers offering technical
rescue capabilities for worst case scenarios through open source
systems and software as a support solution for system administrators

4. Incoming
mail blocking:

If the user wishes to
block incoming mails coming from the particular mail id, user can block these
mails by specifying that mail id.

5. Outgoing
Mail blocking:

If the organization using this project wish to
block the outgoing mails from the particular mail id, the mail id can be blocked
so that mails outgoing from that address will not be delivered.

6. As
a virus filter:

It will search for an id of virus and if it is
found, it will report to the user or the administrator.

7. As
a spam detector:

If in case it is found that a user gets mail from
particular address in large amount and is filling out the mailbox then the mail
filter will detect it and inform the user or the administrator.

1.3 Methodology

The methodology adopted for the project work is broadly
divided into four phases:

1. Analysis

2. Design

3. Development

4. Testing

Analysis: This phase is included as the study of email filter in the
use of internet. Also an in depth study of sendmail, milter libraries is required.Further,
the concept of various filters along with some RFC’s need to be thoroughly understood.

The entire essential component that will be required
by the project need to be estimated at this phase and should be configured accordingly
and maintained throughout the lifecycle of the project.

Design: Software development under C/C++ should
be done and on Linux platform. Before this, we need to compile and configure
current sendmail using sh Build. After this we have to learn programming
using milter libraries. This includes following:

Loading of milter libraries

Building small modules of filters for various purposes.

Creating a stack of these modules

The incoming mails will be tested for these
modules.

Development: We have to develop architecture
for the actual implementation of generalized filter. In this phase, the main
virus filter will be developed along with it’s other applications like spam
filter, user configurable filter, etc.

There will be a stack, which will consist of various
modules, which are capable of checking the mails for a particular specification.
After checking the mails for the various modules, the acceptance or rejection
of the mail is decided.

Testing : In this every block of the project will be tested for its
proposed functionality and even for its behaviour in unknown conditions. The
project will be at least tested for its behaviour under following circumstances:

Arrival of virus infected mail.

Receival of mail from blocked email address.

For user specification.

1.4Project Resources

Hardware Requirements:

Networked computers
with any type of physical connections within themselves. An instance can be
given as: