ACKNOWLEDGEMENT

Apart from the efforts of me, the success of this project depends largely on the encouragement and guidelines of many others. I take this opportunity to express my gratitude to the people who have been instrumental in the successful completion of this project. I would like to show my greatest appreciation to my helpful supervisor Mr. Gaurav Saluja I cant say thank you enough for his tremendous support and help. I feel motivated and encouraged every time I attend his meeting. Without his encouragement and guidance this project would not have materialized. The guidance and support received from all the team members including Gajendra Singh , Prashant Khandelwal and Kamal Singh who contributed and are contributing to this project, was vital for the success of the project. I am grateful for their constant support and help.

Finally, yet importantly, I would like to express my heartfelt thanks to my beloved parents for their blessings, my friends/classmates for their help and wishes for the successful completion of this project.

ANKIT SHARMA

TABLE OF CONTENTS
Introduction

Project Overview ....

Software Requirments ...

User Manual ...

Results

Conclusion ...

References ..

ORGANIZATION PROFILE

GRRAS is a well known Linux training institute and authorized Linux training partner of Red Hat. We offer Red Hat certified RHCE, RHCVA and RHCSS courses, which are required to get expertise over Linux server. Our wide range of Linux training services includes Linux Consultancy Linux Server Migration Server Management and Implementation Corporate training In-house training Certifications Red Hat certified Linux courses Cisco certified courses-CCNA, CCNP PHP, MySQL projects development and maintenance

With its advanced and comprehensive Linux courses and Linux training, GRRAS is raising the standard of Linux training. With its practical knowledge base approach, GRRAS makes professionals enable to meet industry demand for high quality enterprise-level skills. GRRAS is an award winning RedHat certified Linux training institute which combines all these prerequisites. We have received tremendous recognition from RedHat for offering quality certified courses.

INTRODUCATION

What is Email ?
Electronic mail, commonly called email or e-mail, is a method of exchanging digital messages from an author to one or more recipients. Modern email operates across the Internet or other computer networks. Some early email systems required that the author and the recipient both be online at the same time, in common with instant messaging. Today's email systems are based on a store-and-forward model. Email servers accept, forward, deliver and store messages. Neither the users nor their computers are required to be online simultaneously; they need connect only briefly, typically to an email server, for as long as it takes to send or receive messages.

History of Email :
The birth of electronic mail (email) occurred in the early 1960s. The first network transfer of an electronic mail message file took place in 1971 when a computer engineer named Ray Tomlinson sent a test message between two machines via ARPANET the precursor to the Internet. Communication via email soon became very popular, comprising 75 percent of ARPANET's traffic in less than two years. Today, email systems based on standardized network protocols have evolved into some of the most widely used services on the Internet. Red Hat Enterprise Linux offers many advanced applications to serve and access email.

Mail Server
A mail server is the computerized equivalent of your friendly neighborhood mailman. Every email that is sent passes through a series of mail servers along its way to its intended recipient. Although it may seem like a message is sent instantly - zipping from one PC to another in the blink of an eye - the reality is that a complex series of transfers takes place. Without this series of mail servers, you would only be able to send emails to people whose email address domains matched your own - i.e., you could only send messages from one example.com account to another example.com account.

Types of Mail Servers

Mail servers can be broken down into two main categories: outgoing mail servers and incoming mail servers. Outgoing mail servers are known as SMTP, or Simple Mail Transfer Protocol, servers. Incoming mail servers come in two main varieties. POP3, or Post Office Protocol, version 3, servers are best known for storing sent and received messages on PCs' local hard drives. IMAP, or Internet Message Access Protocol, servers always store copies of messages on servers. Most POP3 servers can store messages on servers, too, which is a lot more convenient.

Sendmail
Sendmail's core purpose, like other MTAs, is to safely transfer email among hosts, usually using the SMTP protocol. However, Sendmail is highly configurable, allowing control over almost every aspect of how email is handled, including the protocol used. Many system administrators elect to use Sendmail as their MTA due to its power and scalability.

Postfix
Originally developed at IBM by security expert and programmer Wietse Venema, Postfix is a Sendmail-compatible MTA that is designed to be secure, fast, and easy to configure. To improve security, Postfix uses a modular design, where small processes with limited privileges are launched by a master daemon. The smaller, less privileged processes perform very specific tasks related to the various stages of mail delivery and run in a change rooted environment to limit the effects of attacks. Configuring Postfix to accept network connections from hosts other than the local computer takes only a few minor changes in its configuration file. Yet for those with more complex needs, Postfix provides a variety of configuration options, as well as third party add ons that make it a very versatile and full-featured MTA. The configuration files for Postfix are human readable and support upward of 250 directives. Unlike Sendmail, no macro processing is required for changes to take effect and the majority of the most commonly used options are described in the heavily commented files.

How Email Clients are Handled

Many people use web-based email clients, like Yahoo Mail and Gmail. Those who require a lot more space - especially businesses - often have to invest in their own servers. That means that they also have to have a way of receiving and transmitting emails, which means that they need to set up their own mail servers. To that end, programs like Postfix and Microsoft Exchange are two of the most popular options. Such programs facilitate the preceding process behind the scenes. Those who send and receive messages across those mail servers, of course, generally only see the "send" and "receive" parts of the process. At the end of the day, a mail server is a computer that helps move files along to their intended destinations. In this case, of course, those files are email messages. As easy as they are to take for granted, it's smart to have a basic grasp of how mail servers work.

Red Hat Enterprise Linux What is Red Hat ?

Red Hat is more than a software company. We are the bridge between the communities that create open source software and the enterprise customers who use it. Red Hat makes the rapid innovation of open source technology consumable in mission-critical, enterprise environments. Red Hat combines a superior development model with a customer-friendly business model that gives customers the choice, flexibility, and power to build an IT infrastructure that solves their business problems and makes their IT a strategic advantage. We do this by sharing. We share our expertise, our code, and our knowledge. We sell subscriptions for enterprise technology and services, we stand up for open source ideals, and we foster greater participation in the open source process. Red Hat is a catalyst for a technology movement that has already changed the world.

Why Red Hat ? 1. We put our value where your money is.
Our technology is delivered via subscription. So you pay for what's most important to Service. Software that works. And we have to keep our promises every day. 2. It starts with transparency. The development process is open. The technology is open. There are no secrets, no surprises, no lock-in. 3. We can help you do more with less. We help enterprises gain full advantage of the capability and efficiency of open source. Especially when budgets are tight. We can help you cut costs and do more with the technology you already have. 4. Open source makes better software faster. Our technology is built in collaboration with a rapidly growing worldwide community. The number of open source projects increased from 16,000 in 2001 to 150,000 in 2007. And when it comes to Linux, Red Hat is the largest contributor. 5. Our development model is different. you.

We collaborate with the open source community to develop technology that makes its way into Fedora and JBoss.org projects. This technology makes its way into Red Hat Enterprise Linux and JBoss Enterprise Middleware. This innovation returns to the community. The cycle is continuous. 6. Which is why we work to keep knowledge open. Transparency. Collaboration. The free exchange of knowledge and ideas. Open source is more than a development model, it's who we are. 7. We offer complete solutions. Red Hat Enterprise Linux as the foundation. JBoss Enterprise Middleware. And the training and services to manage it all. 8. With the power of a broad ecosystem. We collaborate with our partners to deliver certified hardware and software that you can trust. 9. And the capabilities of a global provider. We have nearly 67 offices in 29 countries. Our service is there when and where you need it, delivered by open source, Linux, and JBoss experts. 10. Just ask our customers. Some of the world's largest organizations rely on Red Hat every day. Especially in the most demanding environments like the New York Stock Exchange.

Open Source Application Why Open Source?

All software has source code. Open source software grants every user access to that code. Freedom means choice. Choice means power. That's why we believe open source is inevitable. It returns control to the customer. You can see the code, change it, learn from it. Bugs are found and fixed quickly. And when customers are unhappy with one vendor, they can choose another without overhauling their entire infrastructure. No more technology lock-in. No more monopolies. We believe open source simply creates better software. Everyone collaborates, the best technology wins. Not just within one company, but among an Internet-connected, worldwide community. New ideas and code travel the world in an instant.

As a result, the open source model often builds higher quality, more secure, more easily integrated software. And it does it at a vastly accelerated pace and often at a lower cost. In the proprietary model, development occurs within one company. Programmers write code, hide it behind binaries, and charge customers to use the software--then charge them more to fix it when it breaks. The problem worsens when you become tied to a company's architecture, protocols, and file formats. Bruce Perens calls this the addiction model of software procurement. And we think a model that puts customers at such a fundamental disadvantage is conceptually broken. Open source is not nameless, faceless, and it's not charity. Nor is it solely a community effort. What you see today is a technology revolution driven by market demand. And the revolution is being recognized. Red Hat has teamed up with the Georgia Institute of Technology to look into the causes and the worldwide growth of open source. They created the Open Source Index to better measure its progress. Imagine if all past knowledge was kept hidden or its use was restricted to only those who are willing to pay for it. Education and research would suffer. Publishing books or sharing information of any sort would become difficult. Yet this is the mentality behind the proprietary software model. In the same way shared knowledge propels the whole of society forward, open technology development can drive innovation for an entire industry.

Domain Name Server (DNS)

DNS associates hostnames with their respective IP addresses, so that when users want to connect to other machines on the network, they can refer to them by name, without having to remember IP addresses. Use of DNS and FQDNs also has advantages for system administrators, allowing the flexibility to change the IP address for a host without affecting name-based queries to the machine. Conversely, administrators can shuffle which machines handle a name-based query. DNS is normally implemented using centralized servers that are authoritative for some domains and refer to other DNS servers for other domains. When a client host requests information from a nameserver, it usually connects to port 53. The nameserver then attempts to resolve the FQDN based on its resolver library, which may contain authoritative information about the host requested or cached data from an earlier query. If the nameserver does not already have the answer in its resolver library, it queries other nameservers, called root nameservers, to determine which nameservers are authoritative for the FQDN in question. Then, with that information, it queries the authoritative nameservers to determine the IP address of the requested host. If a reverse lookup is performed, the same procedure is used, except that the query is made with an unknown IP address rather than a name.

Apache HTTP Server

The Apache HTTP Server is a robust, commercial-grade open source Web server developed by the Apache Software Foundation (http://www.apache.org/). Red Hat Enterprise Linux includes the Apache HTTP Server 2.2 as well as a number of server modules designed to enhance its functionality. The default configuration file installed with the Apache HTTP Server works without alteration for most situations. Features of Apache HTTP Server 2.2 Apache HTTP Server 2.2 features the following improvements over version 2.0 : Improved caching modules (mod_cache, mod_disk_cache, mod_mem_cache). A new structure for authentication and authorization support, replacing the authentication modules provided in previous versions. Support for proxy load balancing (mod_proxy_balancer) * support for handling large files (namely, greater than 2GB) on 32-bit platforms * The mod_cern_meta and mod_asis modules are no longer loaded by default. * The mod_ext_filter module is now loaded by default. For more information, refer to http://httpd.apache.org/docs/2.2/upgrading.html

Squirrelmail
What is SquirrelMail? SquirrelMail is a standards-based webmail package written in PHP. It includes built-in pure PHP support for the IMAP and SMTP protocols, and all pages render in pure HTML 4.0 (with no JavaScript required) for maximum compatibility across browsers. It has very few requirements and is very easy to configure and install. SquirrelMail has all the functionality you would want from an email client, including strong MIME support, address books, and folder manipulation.

PROJECT OVERVIEW

UDP/53

SMTP/25

SMTP Port 25 POP/IMAP SMTP/25

Fig.1: System Architecture of Mail Server MUA Mail User Agent MTA Mail Transport Agent DNS Domain Name Server UDP User Datagram Protocol SMTP Simple Mail Transfer Protocol POP Post Office Protocol

IMAP Intenet Mail Access Protocol

Fig.2: System Architecture of Mail Server System 1. Email Protocols

Today, email is delivered using a client/server architecture. An email message is created using a mail client program. This program then sends the message to a server. The server then forwards the message to the recipient's email server, where the message is then supplied to the recipient's email client. To enable this process, a variety of standard network protocols allow different machines, often running different operating systems and using different email programs, to send and receive email. The following protocols discussed are the most commonly used in the transfer of email. 1.1 Mail Transport Protocols Mail delivery from a client application to the server, and from an originating server to the destination server, is handled by the Simple Mail Transfer Protocol (SMTP).

1.1.1 SMTP The primary purpose of SMTP is to transfer email between mail servers. However, it is critical for email clients as well. To send email, the client sends the message to an outgoing mail server, which in turn contacts the destination mail server for delivery. For this reason, it is necessary to specify an SMTP server when configuring an email client. Under Red Hat Enterprise Linux, a user can configure an SMTP server on the local machine to handle mail delivery. However, it is also possible to configure remote SMTP servers for outgoing mail. By default, Sendmail (/usr/sbin/sendmail) is the default SMTP program under Red Hat Enterprise Linux. However, a simpler mail server application called Postfix (/usr/sbin/postfix) is also available. 1.2 Mail Access Protocols There are two primary protocols used by email client applications to retrieve email from mail servers: the Post Office Protocol (POP) and the Internet Message Access Protocol (IMAP). 1.2.1. POP The default POP server under Red Hat Enterprise Linux is /usr/lib/cyrus-imapd/pop3d and is provided by the cyrus-imapd package. When using a POP server, email messages are downloaded by email client applications. By default, most POP email clients are automatically configured to delete the message on the email server after it has been successfully transferred, however this setting usually can be changed. POP is fully compatible with important Internet messaging standards, such as Multipurpose Internet Mail Extensions (MIME), which allow for email attachments. POP works best for users who have one system on which to read email. It also works well for users who do not have a persistent connection to the Internet or the network containing the mail server. Unfortunately for those with slow network connections, POP requires client programs upon authentication to download the entire content of each message. This can take a long time if any messages have large attachments. The most current version of the standard POP protocol is POP3. 1.2.2. IMAP The default IMAP server under Red Hat Enterprise Linux is /usr/lib/cyrus-imapd/imapd and is provided by the cyrus-imapd package. When using an IMAP mail server, email messages remain on the server where users can read or delete them. IMAP also allows client applications to create, rename, or delete mail directories on the server to organize and store email.

IMAP is particularly useful for those who access their email using multiple machines. The protocol is also convenient for users connecting to the mail server via a slow connection, because only the email header information is downloaded for messages until opened, saving bandwidth. The user also has the ability to delete messages without viewing or downloading them. Other free, as well as commercial, IMAP clients and servers are available, many of which extend the IMAP protocol and provide additional functionality. A comprehensive list can be found online at http://www.imap.org/products/longlist.htm. 2. Email Program Classifications In general, all email applications fall into at least one of three classifications. Each classification plays a specific role in the process of moving and managing email messages. While most users are only aware of the specific email program they use to receive and send messages, each one is important for ensuring that email arrives at the correct destination. 2.1. Mail Transport Agent A Mail Transport Agent (MTA) transports email messages between hosts using SMTP. A message may involve several MTAs as it moves to its intended destination. While the delivery of messages between machines may seem rather straightforward, the entire process of deciding if a particular MTA can or should accept a message for delivery is quite complicated. In addition, due to problems from spam, use of a particular MTA is usually restricted by the MTA's configuration or the access configuration for the network on which the MTA resides. Many modern email client programs can act as an MTA when sending email. Since Red Hat Enterprise Linux installs two MTAs, Sendmail and Postfix, email client programs are often not required to act as an MTA. Red Hat Enterprise Linux also includes a special purpose MTA called Fetchmail. 2.2. Mail Delivery Agent A Mail Delivery Agent (MDA) is invoked by the MTA to file incoming email in the proper user's mailbox. In many cases, the MDA is actually a Local Delivery Agent (LDA), such as mail or Procmail. Any program that actually handles a message for delivery to the point where it can be read by an email client application can be considered an MDA. For this reason, some MTAs (such as Sendmail and Postfix) can fill the role of an MDA when they append new email messages to a local user's mail spool file. In general, MDAs do not transport messages between systems nor do they provide a user interface; MDAs distribute and sort messages on the local machine for an email client application to access.

2.3. Mail User Agent A Mail User Agent (MUA) is synonymous with an email client application. An MUA is a program that, at the very least, allows a user to read and compose email messages. Many MUAs are capable of retrieving messages via the POP or IMAP protocols, setting up mailboxes to store messages, and sending outbound messages to an MTA. MUAs may be graphical, such as Evolution, or have a very simple, text-based interface, such as mutt. 3. Mail Transport Agents Red Hat Enterprise Linux includes two primary MTAs, Sendmail and Postfix. Sendmail is configured as the default MTA, although it is easy to switch the default MTA to Postfix.

3.1. Sendmail
Sendmail's core purpose, like other MTAs, is to safely transfer email among hosts, usually using the SMTP protocol. 3.1.1. Purpose and Limitations It is important to be aware of what Sendmail is and what it can do, as opposed to what it is not. In these days of monolithic applications that fulfill multiple roles, Sendmail may seem like the only application needed to run an email server within an organization. Technically, this is true, as Sendmail can spool mail to each users' directory and deliver outbound mail for users. However, most users actually require much more than simple email delivery. Users usually want to interact with their email using an MUA, that uses POP or IMAP, to download their messages to their local machine. Or, they may prefer a Web interface to gain access to their mailbox. These other applications can work in conjunction with Sendmail, but they actually exist for different reasons and can operate separately from one another. 3.2 Mail Transport Agent (MTA) Configuration A Mail Transport Agent (MTA) is essential for sending email. A Mail User Agent (MUA) such as Evolution, Thunderbird, and Mutt, is used to read and compose email. When a user sends an email from an MUA, the message is handed off to the MTA, which sends the message through a series of MTAs until it reaches its destination. Red Hat Enterprise Linux 5 provides three MTAs: Sendmail, Postfix, and Exim. If all three are installed, sendmail is the default MTA. The Mail Transport Agent Switcher allows for the selection of either sendmail, postfix, or exim as the default MTA for the system.

To start the Mail Transport Agent Switcher, select System (the main menu on the panel) => Administration => Mail Transport Agent Switcher, or type the command system-switch-mail at a shell prompt (for example, in an XTerm or GNOME terminal).

Fig.3 : Mail Transport Agent Switcher if you select OK to change the MTA, the selected mail daemon is enabled to start at boot time, and the unselected mail daemons are disabled so that they do not start at boot time. The selected mail daemon is started, and any other mail daemon is stopped; thus making the changes take place immediately. 4. Mail User Agents There are scores of mail programs available under Red Hat Enterprise Linux. There are fullfeatured, graphical email client programs, such as Ximian Evolution, as well as text-based email programs such as mutt. 4.1 Securing Communication Popular MUAs included with Red Hat Enterprise Linux, such as Ximian Evolution and mutt offer SSL-encrypted email sessions. 4.1.1 Secure Email Clients Most Linux MUAs designed to check email on remote servers support SSL encryption. To use SSL when retrieving email, it must be enabled on both the email client and server.

SOFTWARE REQUIRMENTS
Berkeley Internet Name Domain (BIND) 1. Introduction to DNS
DNS associates hostnames with their respective IP addresses, so that when users want to connect to other machines on the network, they can refer to them by name, without having to remember IP addresses. DNS is normally implemented using centralized servers that are authoritative for some domains and refer to other DNS servers for other domains. 1.1. Nameserver Zones Zones are defined on authoritative nameservers through the use of zone files (which describe the namespace of that zone), the mail servers to be used for a particular domain or sub-domain, and more. Zone files are stored on primary nameservers (also called master nameservers), which are truly authoritative and where changes are made to the files, and secondary nameservers (also called slave nameservers), which receive their zone files from the primary nameservers. Any nameserver can be a primary and secondary nameserver for different zones at the same time, and they may also be considered authoritative for multiple zones. It all depends on how the nameserver is configured. 1.2. Nameserver Types There are four primary nameserver configuration types: Master : Stores original and authoritative zone records for a namespace, and answers queries about the namespace from other nameservers. Slave :Answers queries from other nameservers concerning namespaces for which it is considered an authority. However, slave nameservers get their namespace information from master nameservers. Caching-only :Offers name-to-IP resolution services, but is not authoritative for any zones. Answers for all resolutions are cached in memory for a fixed period of time, which is specified by the retrieved zone record. Forwarding :Forwards requests to a specific list of nameservers for name resolution. If none of the specified nameservers can perform the resolution, the resolution fails.

A nameserver may be one or more of these types. For example, a nameserver can be a master for some zones, a slave for others, and only offer forwarding resolutions for others. 1.3. BIND as a Nameserver BIND performs name resolution services through the /usr/sbin/named daemon. BIND also includes an administration utility called /usr/sbin/rndc. BIND stores its configuration files in the following locations: The configuration file for the named daemon : /etc/named.conf

/var/named/ directory

Note : If you have installed the bind-chroot package, the BIND service will run in the /var/named/chroot environment. All configuration files will be moved there. As such, named.conf will be located in /var/named/chroot/etc/named.conf, and so on. 1.3.1 /etc/named.conf The named.conf file is a collection of statements using nested options surrounded by opening and closing ellipse characters, { }. Administrators must be careful when editing named.conf to avoid syntax errors as many seemingly minor errors prevent the named service from starting.

Fig.4 : /etc/named.conf file A typical named.conf file is organized similar to the following example: <statement-1> ["<statement-1-name>"] [<statement-1-class>] { <option-1>; <option-2>; <option-N>; }; <statement-2> ["<statement-2-n 1.4 Zone Files Zone files contain information about a namespace and are stored in the named working directory (/var/named/) by default. Each zone file is named according to the file option data in the zone

statement, usually in a way that relates to the domain in question and identifies the file as containing zone data, such as example.com.zone. Note:If you have installed the bind-chroot package, the BIND service will run in the /var/named/chroot environment. All configuration files will be moved there. As such, you can find the zone files in /var/named/chroot/var/named. Each zone file may contain directives and resource records. Directives tell the nameserver to perform tasks or apply special settings to the zone. Resource records define the parameters of the zone and assign identities to individual hosts. Directives are optional, but resource records are required to provide name service to a zone. All directives and resource records should be entered on individual lines. 1.4.1. Zone File Directives Directives begin with the dollar sign character ($) followed by the name of the directive. They usually appear at the top of the zone file. The following are commonly used directives: $INCLUDE :Configures named to include another zone file in this zone file at the place where the directive appears. This allows additional zone settings to be stored apart from the main zone file. $ORIGIN :Appends the domain name to unqualified records, such as those with the hostname and nothing more. Note :The use of the $ORIGIN directive is unnecessary if the zone is specified in /etc/named.conf because the zone name is used as the value for the $ORIGIN directive by default. $TTL : Sets the default Time to Live (TTL) value for the zone. This is the length of time, in seconds, that a zone resource record is valid. Each resource record can contain its own TTL value, which overrides this directive. 1.4.2. Zone File Resource Records The primary component of a zone file is its resource records. There are many types of zone file resource records. The following are used most frequently: A This refers to the Address record, which specifies an IP address to assign to a name, as in this example: <host> IN A <IP-address>

CNAME :This refers to the Canonical Name record, which maps one name to another. This type of record can also be referred to as an alias record. <alias-name> IN CNAME <real-name> MX : This refers to the Mail eXchange record, which tells where mail sent to a particular namespace controlled by this zone should go. IN MX <preference-value><email-server-name> Here, the <preference-value> allows numerical ranking of the email servers for a namespace, giving preference to some email systems over others. The MX resource record with the lowest <preference-value> is preferred over the others. NS : This refers to the NameServer record, which announces the authoritative nameservers for a particular zone. The following illustrates the layout of an NS record: IN NS <nameserver-name> Here, <nameserver-name> should be an FQDN. PTR : This refers to the PoinTeR record, which is designed to point to another part of the namespace. PTR records are primarily used for reverse name resolution, as they point IP addresses back to a particular name. SOA : This refers to the Start Of Authority resource record, which proclaims important authoritative information about a namespace to the nameserver.Located after the directives, an SOA resource record is the first resource record in a zone file. 1.4.3 Reverse Name Resolution Zone Files A reverse name resolution zone file is used to translate an IP address in a particular namespace into an FQDN. It looks very similar to a standard zone file, except that PTR resource records are used to link the IP addresses to a fully qualified domain name. The following illustrates the layout of a PTR record: <last-IP-digit> IN PTR <FQDN-of-system>

2. Web Server
Apache HTTP Server The default configuration file installed with the Apache HTTP Server works without alteration for most situations.

2.1 Starting and Stopping httpd After installing the httpd package, review the Apache HTTP Server's documentation available online at http://httpd.apache.org/docs/2.2/. The httpd RPM installs the /etc/init.d/httpd script, which can be accessed using the /sbin/service command. Starting httpd using the apachectl control script sets the environmental variables in /etc/sysconfig/httpd and starts httpd. You can also set the environment variables using the init script. To start the server using the apachectl control script as root type: apachectl start To stop the server, as root type: apachectl stop

You can restart the server as root by typing: apachectl restart or:/sbin/service httpd restart By default, the httpd service does not start automatically at boot time.. You can also configure the httpd service to start up at boot time, using an initscript utility, such as /sbin/chkconfig, /usr/sbin/ntsysv, or the Services Configuration Tool program. You can also display the status of your httpd server by typing: For more details on mod_status can be found on http://httpd.apache.org/docs/2.2/mod/mod_status.html. 2.2 Apache HTTP Server Configuration The HTTP Configuration Tool allows you to configure the /etc/httpd/conf/httpd.conf configuration file for the Apache HTTP Server. It does not use the old srm.conf or access.conf configuration files; leave them empty. Only modules provided with Red Hat Enterprise Linux can be configured with the HTTP Configuration Tool apachectl status

Fig.5 : /etc/httpd/conf/httpd.conf file

The general steps for configuring the Apache HTTP Server using the HTTP Configuration Tool are as follows: 1. Configure the basic settings under the Main tab. 2. Click on the Virtual Hosts tab and configure the default settings. 3. Under the Virtual Hosts tab, configure the Default Virtual Host. 4. To serve more than one URL or virtual host, add any additional virtual hosts. 5. Configure the server settings under the Server tab. 6. Configure the connections settings under the Performance Tuning tab. 7. Copy all necessary files to the DocumentRoot and cgi-bin directories. 8. Exit the application and select to save your settings. 2.3 Configuration Directives in httpd.conf The Apache HTTP Server configuration file is /etc/httpd/conf/httpd.conf. The httpd.conf file is well-commented and mostly self-explanatory. The default configuration works for most situations; however, it is a good idea to become familiar some of the more important configuration options. 2.4 Directory <Directory /path/to/directory> and </Directory> tags create a container used to enclose a group of configuration directives which apply only to a specific directory and its subdirectories. Any directive which is applicable to a directory may be used within Directory tags. By default, very restrictive parameters are applied to the root directory (/), using the Options (refer to Options) and AllowOverride (refer to AllowOverride) directives. Under this configuration, any directory on the system which needs more permissive settings has to be explicitly given those settings. In the default configuration, another Directory container is configured for the DocumentRoot which assigns less rigid parameters to the directory tree so that the Apache HTTP Server can access the files residing there. 2.5 DirectoryIndex

The DirectoryIndex is the default page served by the server when a user requests an index of a directory by specifying a forward slash (/) at the end of the directory name. When a user requests the page http://example/this_directory/, they get either the DirectoryIndex page, if it exists, or a server-generated directory list. The default for DirectoryIndex is index.html and the index.html.var type map. The server tries to find either of these files and returns the first one it finds. If it does not find one of these files and Options Indexes is set for that directory, the server generates and returns a listing, in HTML format, of the subdirectories and files within the directory, unless the directory listing feature is turned off.

Fig.6 : DirectoryIndex in /etc/httpd/conf/httpd.conf file 2.6 DocumentRoot DocumentRoot is the directory which contains most of the HTML files which are served in response to requests. The default DocumentRoot, for both the non-secure and secure Web servers, is the /var/www/html directory.

Fig.7 : DocumentRoot in /etc/httpd/conf/http.conf file

3. Dovecot

The imap-login and pop3-login daemons which implement the IMAP and POP3 protocols are included in the dovecot package. The use of IMAP and POP is configured through dovecot; by default dovecot runs only IMAP. To configure dovecot to use POP: 1. Edit /etc/dovecot.conf to have the line: protocols = imap imaps pop3 pop3s

Fig.8 : /etc/dovecot.conf 2. Make that change operational for the current session by running the command: /sbin/service dovecot restart 3.Make that change operational after the next reboot by running the command: chkconfig dovecot on Please note that dovecot only reports that it started the IMAP server, but also starts the POP3 server. Unlike SMTP, both of these protocols require connecting clients to authenticate using a username and password. By default, passwords for both protocols are passed over the network unencrypted.

4. Postfix
Configuring Postfix to accept network connections from hosts other than the local computer takes only a few minor changes in its configuration file. Yet for those with more complex needs, Postfix provides a variety of configuration options, as well as third party add ons that make it a very versatile and full-featured MTA. Important : Before using Postfix, the default MTA must be switched from Sendmail to Postfix.

3.2.1. The Default Postfix Installation The Postfix executable is /usr/sbin/postfix. This daemon launches all related processes needed to handle mail delivery. Postfix stores its configuration files in the /etc/postfix/ directory. The following is a list of the more commonly used files: access - Used for access control, this file specifies which hosts are allowed to connect to Postfix. aliases - A configurable list required by the mail protocol. main.cf - The global Postfix configuration file. The majority of configuration options are specified in this file.

Fig.9 : /etc/postfix/main.cf file master.cf- Specifies how Postfix interacts with various processes to accomplish mail delivery. transport - Maps email addresses to relay hosts. Important : The default /etc/postfix/main.cf file does not allow Postfix to accept network connections from a host other than the local computer. When changing some options within files in the /etc/postfix/ directory, it may be necessary to restart the postfix service for the changes to take effect. The easiest way to do this is to type the following command: /sbin/service postfix restart 3.2.2. Basic Postfix Configuration By default, Postfix does not accept network connections from any host other than the local host. Perform the following steps as root to enable mail delivery for other hosts on the network: * Edit the /etc/postfix/main.cf file with a text editor, such as vi.

* Uncomment the mydomain line by removing the hash mark (#), and replace domain.tld with the domain the mail server is servicing, such as example.com. * Uncomment the myorigin = $mydomain line. * Uncomment the myhostname line, and replace host.domain.tld with the hostname for the machine.

Fig.10 : mydomain , myhostname in /etc/postfix/main.cf * Uncomment the mydestination = $myhostname, localhost.$mydomain line. * Uncomment the mynetworks line, and replace 168.100.189.0/28 with a valid network setting for hosts that can connect to the server. * Uncomment the inet_interfaces = all line. * Restart the postfix service. Once these steps are complete, the host accepts outside emails for delivery. Postfix has a large assortment of configuration options. One of the best ways to learn how to configure Postfix is to read the comments within /etc/postfix/main.cf. Additional resources including information about LDAP and SpamAssassin integration are available online at http://www.postfix.org/

5. SquirrelMail
5.1 Server requirements There are only two requirements for SquirrelMail:
A web server with PHP installed. PHP needs to be at least 4.1.0. PHP 4, PHP 5 and PHP 6 are all supported.

Access to an IMAP server which supports IMAP 4 rev 1.

It doesn't really matter what OS or web server you use, as long as the combination thereof supports PHP in a stable way. Read the instructions and suggestions in the PHP documentation to see what they recommend. Make sure that everything is working before trying to install SquirrelMail.
5.2 Choosing an IMAP server

You don't actually have to run an IMAP server yourself, but you need to be able to connect to one for SquirrelMail to work. Since IMAP is an open standard, all IMAP products should be able to communicate with each other. SquirrelMail requires that the server supports IMAP 4 rev 1, but that's the only requirement there is. SquirrelMail doesn't care about how the server stores the mails, but it's generally a good idea not to have an IMAP server that store mails in the mailbox (mbox) format. Mailbox performance is low when there are many mails in the same folder and it doesn't allow both mails and subfolders at the same time in the same folder.
5.3 Configuring PHP

Without the PHP gettext extension you lose in performance. The PHP mbstring extension is required for translations that use multibyte or character sets but ISO-8859-1. Without the PHP mbstring extension the interface will remain usable, but some internationalization features and fixes won't be enabled. It's a must if you want to read and write Japanese emails, and users who whish to do that must also set their language option to Japanese. The PHP XML extension is required if the DIGEST-MD5 authentication is used.
Cookies must be enabled in your browser. It might be hard to use SquirrelMail on a display smaller then 15" and with less resolution than 1024 x 768, and some customizations are required to make it usable.

5.4 Client requirements

5.5 Configure SquirrelMail Run config/conf.pl (or just configure) from the command line. This is a Perl script, so if you do not have Perl installed, please refer to our notes about how to configure SquirrelMail without shell access. Use the D option to load predefined settings for your particular IMAP server, and edit at least the Server Settings and General Options (making sure to set the "Data Directory" and "Attachment Directory" settings). 5.6 Log into SquirrelMail Browse to http://example.com/squirrelmail/ to log in. Again, you'll need to change "example.com" and "squirrelmail" to whatever the location is that you have it installed. 5.7 Configuration files and tools

SquirrelMail configuration is file based. If you've installed SquirrelMail directly from source you'll find the configuration file in config/config.php, but if you're using a SquirrelMail package from your OS distribution the actual configuration file may be located somewhere else (such as /etc/) - usually with a symbolic link from config/config.php.. There are three ways to change the SquirrelMail configuration file: using the configuration tool, using the Administrator plugin, or editing the configuration file manually. The first of these ways is the one recommended by the SquirrelMail Project.
5.7.1 The configuration tool

Included in the SquirrelMail distribution is a Perl script, located at config/conf.pl, which helps when creating or editing the configuration file. . 5.7.2 The Administrator plugin SquirrelMail also includes the Administrator plugin as part of the distribution. Some administrators considers this to be a more user-friendly tool than the Perl script. It can be used instead of config/conf.pl, but is less safe since it requires the web server to have write access to the configuration file. Read plugins/administrator/INSTALL for instructions on how to install it and set up the administrator user. 5.7.3 Manual configuration Since config/config.php is a PHP file, SquirrelMail can also be configured manually with the editor of your choice. A sample configuration is provided in config/config_default.php, so copy config/config_default.php to config/config.php and then edit config/config.php to match your installation..

USER MANUAL
Using SquirrelMail Overview
SquirrelMail is an interface to your organization's email system through the web. It has all the functionality you would want from an email client, including strong support for attachments, address books, calendar and folders.

SquirrelMail is also highly customizable. Your systems administrators can write, install, and share "plugins" at your SquirrelMail server to extend its functionality to meet your organization's needs. Because of the high level of customization available to your organization with SquirrelMail, some of the items in this manual may not apply to you. Most should, and we have made every effort to note things that may differ in your situation.

Logging in
Enter your username in the name field (if in doubt: <username>@<your.domain>). Enter your password in the password field. Your password will show up as asterisks (*); this is a security feature to prevent other people from viewing your password when you type it in. The password must be exactly the same as configured in the IMAP Server (or your IPMAP mailer program)

Press the "Login" button.

If you're can't get in, double check your username and password, and then contact your administrator if you still have problems. Some SquirrelMail installations, but not all, allow a user to change their password through the web interface. If this is a feature you need, but don't have, contact your administrator. It is possible to create a link (or bookmark) to the login page that will make it use a default username. To do this add the text ?loginname=username to the end of the URL (which previously ended with login.php), here "username" should be substituted by your actual username.

Setting preferences
From any Squirrel Mail window, you can select "Options" at the top of the screen, to review or edit your user preferences. Options available are:
Personal information Message highlighting Index order Display preferences Folder preferences

Personal information Name and Address Options (all fields are optional) Full Name

Enter your name. This will be used to identify you in outgoing email.
Email Address

Enter your email address. Email you send will show this address in the FROM: line.
Reply To

Enter the email address you would like people to reply to. Most email clients will use this email address instead of the "From" address when replying to mail you send.
Signature

If you would like to include a short message or "signature" at the bottom of your emails, you can type it here.
Multiple Identities

If you like to have multiple email addresses, signatures or names, you can enter them here, or select an already created identity.
Your Current Timezone

Email usually includes a timestamp that tells the receiver when you sent it. If you select your timezone here, the timestamp will be more accurate. If not, the server's time zone is used.
Display Preferences General Display Options Theme

Different color schemes are available. Themes with "(Changes)" after their name may have a different color each time you log in.

Custom Stylesheet

Select a stylesheet to use a different size font. The administrator may install special style sheets that further modify appearance.
Language

Select a different language to allow the reading and writing of emails in that language. For example, to have Japanese emails display properly, one must set this to Japanese.
Use JavaScript Autodetect Detect if the web browser supports JavaScript Always Assume that JavaScript is supported Never Use plain HTML Mailbox Display Options Number of Messages to Index

The number of message to show per page.

Enable Alternating Row Colors

Show every other message with a different color.

Enable Page Selector

Show page numbers that let you go straight to a specific page.

Maximum Number of Pages to Show

How many page numbers to show. If there are too many pages then they will be split like this: 1 2 3 4 5 6 7 ... 17 18 19 20.

Message highlighting

From almost any window, select "Options" from the menu at top. From the resulting page, select "Message Highlighting". (Windows style: Select Options -> Message Highlighting) From this window, you can do these things:
Create a new highlight

Choose a scheme for highlighting messages that match a particular pattern (see below).
Choose: Options -> Message Highlighting Choose: New Assign a name to your new highlight style Select a color for your highlight style Select a criterion for the highlighted message. The criterion matches, if the string is contained within the specified field. E.g. highlighting all messages coming from domain "foo.bar" would be done by selecting "from" within the combobox and then type "@foo.bar" into the pattern field. The match is case-insensitive, and will match a header containing the search string anywhere within it - but no wild cards or regular expressions.

Edit an existing highlight

Make changes to a given highlight style.

Delete an existing hightlight

Remove an existing highlight style from the set.

Reading e-mail
Click on a folder on the folder bar to display a list of messages in that folder. Unread messages cause the folder name to be bold. Once the folder is clicked on, those unread messages are bold in the folder view. Click on the subject to read the message. A bar containing three fields (From, Date, and Subject) is next. These headings separate the message table into logical parts. From tells you who sent you the message, or at least what email address it came from. Date shows the day which the email was sent. Subject displays what the sender entered as the subject. Note: Between the Date and Subject columns is a small column that is unlabeled. There could be a "+", "!" or an "A" in there. If you see the "+", that means that the message has attachments; if you see the "A", that means that you have answered the message, and if you see the "!", then the message was marked as urgent!
Reading attachments

If an email contains an attachment, it will be listed at the bottom of the email when you are reading a message. Depending on how your web browser is set up, it may know how to open various types of attachments. In order to view attachments, you must have a program that can open that type of file.

Sending e-mail

To send a new message, click on the compose link on the top of the screen. To reply, click on reply or reply All on the top right of the message. The address link will allow you to add addresses to the To: CC: or BCC: fields from your address book. A drop down box exists for selecting the priority of the message, and Rcpt check boxes are there for openning and receiving of the email confirmations. Depending on your option configuration, Sent messages may be stored in the sent message folder, or they may be cc'ed to an address you specify.
Attaching documents

To send an attachment, you must be composing a message. At the bottom of the compose window, there should be a form field labeled Attach with a Browse and an Add button next to it. Click the Browse button. Locate the file on your computer that you want to attach. Select it (single click) and click OK or Open. The should now contain the location of the file, as well as the file's name. Click Add to transfer the file to the SquirrelMail server. The file's name should now be listed at the bottom of the compose screen, with a checkbox next to it. The other information listed is the MIME type and the file size in parenthesis. You can add as many attachments to a message as you want. However, the files should have different names. SquirrelMail will allow you to send a message containing multiple attachments with the same name, but when the recipient saves them, they may accidentally overwrite one with another. If you want to remove one or more attachments from your message, check the checkbox next to the attachment(s) you wish to delete and press the 'Delete select attachments' button.

RESULTS
The first screen presented to the user is the login screen where they enter their username and password to log into the IMAP server

Fig.11 : Login Screen of Mail Server

After the user logs in, the first folder that is opened is the INBOX. This is the summary of the INBOX folder with the message listing on the right, and the folder listing on the left. The folder list (left) and tool bar (top) are always present inside SquirrelMail for easy navigation.

Fig.12 : INBOX screen of Mail Server One of the most common tasks performed by an email client is actually reading messages. This is the message reader for SquirrelMail. It is designed to allow unobstructed and easy reading

Fig.13 : Mail Reading screen on mail server Since IMAP folders are stored on the server, it is also essential to have a proper folder management utility. SquirrelMail supports all the necessary functions used when managing folders: create, delete, rename, subscribe, and unsubscribe.

Fig.14 : Folder management utility on mail server SquirrelMail is highly configurable. There are five main configuration sections included in the base distribution. Plugins can also create option sections that integrate seamlessly into the rest of the options.

Fig.15 : Option Utility for customization of mail Server Here is a close-up look at one of the options sections, the display options. This is where the look and feel of SquirrelMail can be tweaked by the user and has such options as language, theme, the use of JavaScript, etc

Fig.16 : Display Preference option utility When composing an email inside SquirrelMail, all the necessary features are within reach. The compose screen allows for spell checking, attachments, and priorities.

Fig.17 :When compose an Email inside screen of mail server Users can store email contacts in personal and shared address books

.Fig.18 : Address book utility of mail server

CONCLUSION

E-mail is an important part of any Web site, and you need to plan its configuration carefully to make it a seamless part of the Web experience of your visitors. Without it, your Web site won't seem complete.

REFERENCES

Related Books
Sendmail Milters: A Guide for Fighting Spam by Bryan Costales and Marcia Flynt; AddisonWesley - A good Sendmail guide that can help you customise your mail filters. Sendmail by Bryan Costales with Eric Allman et al; O'Reilly & Associates- A good Sendmail reference written with the assistance of the original creator of Delivermail and Sendmail. Removing the Spam: Email Processing and Filtering by Geoff Mulligan; Addison-Wesley Publishing Company- A volume that looks at various methods used by email administrators using established tools, such as Sendmail and Procmail, to manage spam problems. Internet Email Protocols: A Developer's Guide by Kevin Johnson; Addison-Wesley Publishing Company- Provides a very thorough review of major email protocols and the security they provide.

Related Website Links http://www.google.com/ http://www.apache.org/ http://www.postfix.org/ http://www.redhat.com/ http://www.squirrelmail.org/ http://www.isc.org/index.pl?/sw/bind/ http://www.sendmail.org/ http://www.dovecot.org/