Make your own free website on Tripod.com
TOP NEXT

Problem Definition

Current Situation

Problem Constraint

Objective to be Achieved

Scope of the Project

Methodology

Project Resources


1.1 Problem Definition

1.1.1        Current Situation

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.

Rising Flood of Spam
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.

Anti-virus protection i.e. complete protection from external and internal security threats.

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.2  Scope 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 virus protection 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 computer security 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.4  Project Resources

Hardware Requirements:

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

ü      IBM PC or compatible

ü      A Network card (NIC)

ü      10MB of disk space

ü      10KB of physical memory

ü      Mail Server

Software Requirements:

ü      Red Hat Linux 6.0

ü      Gcc ver 2.96/3.0

ü      BSD socket interface

ü      Emacs text editor

ü      TCP/IP stack

ü      Four or more IP addresses for different computers.

ü      Sendmail 8.12.1

ü      Sendmail configured with Milter libraries support

ü      Network Monitoring utilities such as netstat, route etc.

ü      Debuggers such as gdb.

ü      Super User privileges to install the system

ü      BSD Unix to check portability issues


TOP NEXT