Mailing System: The Intra Mail

Mailing System: The Intra Mail Prof. T. Malik Asst. Professor, Telecommunication JSBT School of Engineering & Technology Bangaluru, India Ms. S. P. Harini Research Associate, Network Infrastructure Edith Cowan University, Australia Abstract: INTRAMAILING SYSTEM aims of providing a good communication interface for the organization. It can cut down the time of employees spend on routine communication tasks. Its successful implementation makes easy the job of employees in the organization. The basic problem is that the employees in the organization communicate or makes correspondence only through post, as their units are located in remote areas. This method of communication is very slow in nature and it is not reliable. Therefore the solution for this problem is to develop communication channel that meets the need of the organization. Basically, the computerized solution is for improving the services as well as self-efficiency of the computer. The objective of the system is for meeting the needs of the employees in the organization for communicating with each other within their units. This application provides basic requirements such as Mail management, File transfer and instant messaging. It also has enhanced features like web browsing and utilities. The Intra-mailing System is very user-friendly application. Only certain applications like system monitoring instant messaging, chatting between two users needs a little training. 1

1. Introduction The aim of the project was to develop an Intranet Web Based Mailing System connecting to a Linux Server running a Mail Server, Database Server and with Apache as The Web Server. The aim was to implement the necessary functionalities to the users such as receiving and organizing mails through SMTP and PHP MAIL FUNCTION and Sending mails using MERCURY MAIL. All these are provided with the graphical interface so that the users can do their desired work smoothly. Apart from that, the administrator can create and delete user accounts through the server. The system starts with the welcome page prompting the user to establish his authentication. He is allowed to see his mail boxes, read mails and send mails to the other users only after his/her account is verified. 2. Functional Requirements 2.1.Login Page: There should be a login page for the existing user where the username and password are verified and then if he is a valid user, he is allowed for further advancements. 2.2.Inbox: The logged in users should be able to see the lists of new mails as well as the existing ones. 2.3.Compose Mail: User should be able to compose mails and send them to the other users. 2.4.Reply/Forward/Delete: The user should be able to reply to mails, forward mails and also delete mails from his mailboxes. The deleted mails should be moved to the Thrash mailbox. 2.5.Attach Files: The user should be able to attach files to the mails and send them to the desired users. 2.6.Save As Draft: The user should be able to save the incomplete mails in the Draft mailbox and these can be completed later and can be sent to others. 2.7.Record Sent Mails: There should be a provision for keeping a record of the mails that have been sent by the user in a separate mailbox called Sent mailbox. International Journal of Innovative Research and Studies Page 2

2.8.Trash mailbox: This mailbox keeps a record of the deleted mails from the other mailboxes such as Inbox, Sent, and Draft. If further mails are deleted from this, the mails should be permanently deleted from the users accounts. 2.9.Chat: An embedded Chatting System will help the user to chat with the online members of Intranet Mail System using Public or Private Chat room. 2.10. Download Mails: Users are allowed to download the mails (in TEXT/CSV/XML formats) for further reference. 3. Simple Mail Transport Protocol (SMTP): RFC 2821 3.1.Description: Simple Mail Transfer Protocol (SMTP) is the basis of Internet e-mail. Its objective is to transfer mail reliably and efficiently. SMTP is the IETF's Standard Number 10, or STD0010. Standard e-mail formats are also closely related to the SMTP standard. E-mail was the first "killer app" on the ARPANET, and SMTP was the scalable, standardized way to transport that e-mail. Its popularity helped drive adoption of TCP/IP and the Internet. SMTP has scaled very well indeed: the basic protocol is still in use 22 years after its standardization and is used by more than 500 million people around the world! 3.2.Location in the Protocol Stack: Rides on top of TCP, although it will run over others, such as X.25. 3.3.Port Numbers: 25 SMTP 587 Submission (e-mail submission via SMTP on port 587) 3.4.IPv6 client/server availability: Both available. 3.5.Early History: Work on network mail began in 1971 over NCP on ARPANET (pre-ip). RFCs 196, 221, 224, and 278 (all in 1971) dealt with the Mail Box Protocol, a system running over NCP/DTP or NCP/FTP and allowing an ASCII text document to be printed or stored as a file on a remote host. MBP was a subset of FTP. 1973 saw a flurry of RFC activity to refine electronic mail over the ARPANET. Electronic mail was widely used on the ARPANET by this time. Mail was handled through FTP International Journal of Innovative Research and Studies Page 3

commands MAIL and MLFL. RFCs 453, 456, 458, 469, 475, 498, and 510 refined mail protocols and operations. RFC 469 standardized the "user@host" addressing method. RFC 524 (Mail Protocol, or MP) was an attempt to further define and standardize electronic mail, still making the protocol a part of FTP. It addressed forwarding mail, replying to mail, mail acknowledgement, and author verification. RFC 539 was Dr. Jonathan Postel's first forray into electronic mail. It was a response to RFC 524. RFC 555 was a response to Postel's response. From 1974 to 1980, these RFCs about mail protocols were issued: RFC 630, 644, 720, 751, 754, 763, and 771. Notable among these were: RFC 644 - addressing how to authenticate e-mail signatures RFC 771 - How to transition existing e-mail protocols and systems from ARPANET/NCP to Internet/TCP. Modern SMTP protocol begins in 1980 in an RFC by Dr. Jon Postel. RFC 772, Mail Transfer Protocol was an attempt at making a mail protocol that was independent of FTP. It is this RFC that will evolve into the first killer app, SMTP e-mail. MTP used port/socket 57, and had 3-digit response codes. It was designed to be independent of the network and transport layers, and work between different operating systems. RFC 773 - Comments on the mail transition strategy outlined in RFC 771. RFC 780 (1981) MTP refined (Postel) RFC 784, 785, and 786 (1981) dealt with implementing MTP on a DEC TOPS-20 operating system. RFC 788 (1981) - Postel introduces SMTP, the Simple Mail Transfer Protocol. It will run on port/socket 25 and contains all the basic commands that are used today. RFC 799 (1981) is also very important in its relationship to mail, since it discusses moving to a hierarchical name space (Internet Name Domains) and the implications for e-mail and e- mail addressing. RFC 805 (1982) was noted from a big meeting on computer mail. The most important outcome of this meeting was a consensus on using the user@host.domain addressing scheme. RFC 807 - Multimedia mail meeting notes RFC 808 - Summary of a computer mail services meeting in 1979. Then came the modern era of SMTP e-mail, with the standardization of RFC 821 (SMTP) and RFC 822 (Internet mail format). International Journal of Innovative Research and Studies Page 4

4. The SMTP E-Mail Standard Here were the original commands for the SMTP protocol: Command set from RFC 821: HELO domain MAIL FROM: reverse-path RCPT TO: forword-path DATA RSET SEND FROM: reverse-path SOML FROM: reverse-path SAML FROM: reverse-path VRFY string EXPN string HELP [string] NOOP QUIT TURN A minimum implementation must contain these SMTP "verbs": HELO MAIL RCPT DATA RSET NOOP QUIT After RFC 821 and RFC 822, more than 60 RFCs have been published concerning SMTP, e- mail formats, e-mail security, and other core e-mail concerns. This does not include POP, IMAP, or PCMAIL! This continuing development has improved the reliability, functionality, performance, and security of e-mail. Here is a list of the basic categories of post-rfc 821 e- mail RFCs: Enhancing SMTP (How to add capabilities while maintaining backward compatibility) International Journal of Innovative Research and Studies Page 5

Security & Encryption Handling attachments (8-bit, binary, large, multiple types) Format/Headers Internationalization and Encoding FAX/Multimedia DSNs (Delivery Status Notifications) Perhaps the most important changes to Internet e-mail were the standardization of MIME, which allowed multiple attached files of different kinds to be sent via SMTP, and SMTP Service Extensions (ESMTP). 5. Internet Mail System Overview: Internet e-mail systems can be described in generic terms, which is helpful in understanding basic e-mail concepts. The X.400 MHS terminology is frequently used. X.400 was an OSI architecture for electronic messaging. It never caught on the way SMTP e-mail did, but the terminology is still useful: Terms defined in the OSI X.400 Message Handling System Model An originator prepares messages with the assistance of his or her User Agent (UA). A UA is an application process that interacts with the Message Transfer System (MTS) to submit messages. The MTS delivers to one or more recipient UAs the messages submitted to it. 14 The MTS is composed of a number of Message Transfer Agents (MTAs). Operating together, the MTAs relay messages and deliver them to the intended recipient UAs, which then make the messages available to the intended recipients. The collection of UAs and MTAs is called the Message Handling System (MHS). The MHS and all of its users are collectively referred to as the Message Handling Environment. 6. Other Common E-mail Terms The terms below are more commonly used today when discussing e-mail protocols, applications, and models: 6.1.Message User Agent (MUA) A process which acts (usually on behalf of a user) to compose and submit new messages, and process delivered messages. In the split- MUA model, POP or IMAP is used to access delivered messages. International Journal of Innovative Research and Studies Page 6

6.2.Message Transfer Agent (MTA) A process which conforms to [SMTP-MTA], which acts as an SMTP server to accept messages from an MSA or another MTA, and either delivers them or acts as an SMTP client to relay them to another MTA. 6.3.Message Submission Agent (MSA) A process which conforms to this specification, which acts as a submission server to accept messages from MUAs, and either delivers them or acts as an SMTP client to relay them to an MTA. 6.4.Mail Delivery Agent (MDA) The MDA is responsible for the actual delivery of messages into a user's mail box. While this may seem like a frivolous task, the important aspect of this component is that the delivery process is separate from the very complex MTA. The main concept that the MDA defines is the structure of the mail store. Modern MDAs usually include the ability to filter mail and in some cases to reformat its contents. 6.5.Mail Access Agent (MAA) The MAA is a new component added to the process about 15 years ago. MAA s are to a certain extent an extension of the MDA. MAA s provide remote access to a user's mail. MAA s speak one or more of a variety of Mail Access Protocols. The two most common Protocols today are POP3 and IMAP4. These protocols have evolved significantly over time. The key functions of an MAA are to authenticate a user and deliver e-mail, but some MAA's provide a much more sophisticated set of features for accessing one's e-mail. 6.6.MTAs and SMTP MTAs speak SMTP or ESMTP. They are essentially mail routers. An Internet MTA is to mail what a router is to IP datagrams. There are only a handful of ISP-scale MTAs, Sendmail, Postfix, and Qmail being the most common at the moment. MTAs can store mail in queue until the destination is available, and then send it. Thus, they are sometimes called storeandforward relays. 6.7.SMTP and DNS Internet SMTP e-mail is highly dependent on DNS. From mail routing to spam-prevention, the DNS system is used extensively. MTAs should have valid DNS A, PTR, and MX records. The MX record is a special record which tells MTAs which SMTP server/mail host to connect to in order to deliver mail to domain X. Multiple MX records can be used for load balancing or redundancy. The lowest number is given the highest priority; SMTP MTAs will International Journal of Innovative Research and Studies Page 7

attempt to deliver there first. Below, you can see an example of mail routing from frito@drag.net to kitt@free.org. Detailed explanation follows the picture: Figure 1 User "frito" has drafted an e-mail to his friend, kitt@free.org. He wrote the e-mail using Evolution, a popular open source graphical e-mail client, or MUA. He had to manually configure the address for his ISP's outgoing SMTP mail relay. He must use this relay; the ISP will not allow outbound SMTP traffic to other mail relays. Once the e-mail arrives at his ISP's mail relay, mail.drag.net, it is put in a queue for delivery. This particular MTA is Sendmail, the Internet's old e-mail workhorse. In order to forward the mail to the proper destination, the MTA must perform a DNS lookup for free.org's MX records. It receives the following info: ;; ANSWER SECTION: free.org. 3600 IN MX 10 pluto.free.org. free.org. 3600 IN MX 20 relay.reliable.com. Mail.drag.net first tries to establish an SMTP connection to the lowest-numbered Mail exchanger, pluto.free.org. However, there is a temporary network outage and it is unable to connect. Next, it will try to connect to the "secondary" Mail exchanger, relay.reliable.com. Relay.reliable.com has been configured to act as a backup store-and-forward mail relay for the free.org domain. Mail.drag.net is able to successfully connect to relay.reliable.com, and sends the message via the SMTP protocol. Relay.reliable.com is running Qmail. Now, on relay.reliable.com, DNS is consulted. Qmail removes itself from the list and tries to deliver to the remaining Mail exchanger, pluto.free.org. It continues trying until the network outage is repaired, then connects via SMTP and delivers the message to pluto. International Journal of Innovative Research and Studies Page 8

Once pluto (which is running Postfix) has the message, it will store the mail in user kitt's mailbox file. Kitt will fire up his MUA (Eudora on Mac OS 9), and connect to pluto's MAA, which is a Qpopper POP3 server. The message will be retrieved and then deleted. The mail went through 3 different MTAs in its journey to the recipient. Each one will be listed in the e-mail's header. Note that the clients were running on different Operating Systems, the MTAs were different UNIX/Linux platforms, and the MTAs were all different. It still worked, because it was designed to be platform independent, vendor independent, and non-commercial. 7. Major MTA (SMTP Server) Implementations for Unix/Linux: Sendmail Postfix Exim Qmail Communigate Pro Sendmail and Postfix are the most common MTAs included with modern GNU/Linux distributions, although Debian comes with Exim. 7.1.Security and Authentication: In recent years, most MUAs (mail clients) have the capability to send authenticated and encrypted e-mail. This is done via the STARTTLS mechanism on port 25 or 587. Once a TLSsession is started, a username and password can be sent to the server. If the credentials check out O.K., the mail will be accepted for delivery. The number one reason for using SMTP AUTH is to allow remote/mobile/home users to send/transmit/upload e-mail from the Internet without requiring that the MTA be an open relay for spammers. STARTTLS is used to encrypt the username and password, so that it cannot be sniffed. Although some people point to TLS as providing encryption of content as well, this is not a good assumption to make. The unencrypted e-mail may be forwarded through several other hosts and networks over which you have no control. If you require end-to-end e-mail encryption, you should use S/MIME or OpenPGP/GnuPG. Configuring the right TLS/SSL type, ports, and auth types can be a painful chore. Fortunately, many clients can automatically test "what the server supports" to make configuration a little bit easier. At the time of this writing, MUAs such as Mozilla Mail, Evolution, Balsa, Opera M2, Outlook Express, Netscape Mail, KMail, and Sylpheed all supported sending SMTP mail with TLS/SSL and authenticating with username and International Journal of Innovative Research and Studies Page 9

password. Many SASL options are available for authentication, but PLAIN and LOGIN are the most common type to use with TLS/SSL. If you are NOT using TLS/SSL, CRAM-MD5 and DIGEST-MD5 will protect your password from packet sniffers. 7.2.Firewall Considerations: SMTP works well through firewalls and NAT/PAT devices such as cheap SOHO router and security devices. Traffic is initiated by SMTP clients to SMTP servers, from random nonprivileged ports to well-known TCP ports. You will probably only need to worry about TCP port 25, although you may have to deal with TCP ports 587 and 465. TCP 587 is the mail submission port, which can be handy for bypassing ISP blocking of port 25 traffic, and 465 is the deprecated SMTPS (SMTP over SSL/TLS) port. Fortunately, most mail client and mail server vendors support the standard STARTTLS method on port 25, and 465 is not required. One item to note is that some firewalls and packet filters actually look at and interfere with SMTP traffic. For example, Cisco's PIX firewall by default only allows RFC-821 minimal commands. Even some Linksys SOHO firewalls will block ESMTP commands like EHLO. If you need/want to use standard ESMTP commands like STARTTLS, 8BITMIME, BINARYMIME, or AUTH, then you will need to configure your firewall to not interfere with SMTP traffic, or select a different type of firewall device that will support ESMTP. 7.3.Client Implementations: All SMTP MTAs can act as clients and servers. Virtually every graphical MUA uses SMTP to transmit/send e-mail to an ISP's mail relay/smtp server/mta or an organization's MTA. The user typically has to manually input the mail server name or IP address in account preferences or settings. In many cases, the mail can be submitted to port 25 or 587 (submission), with or without encryption via STARTTLS. The MUA usually retrieves mail via IMAP or POP3. 8. Overview Of The System Here the browser clients have the INTRANET MAIL account. The authentication of the user is verified by PASSWORD AUTHENTICATION SYSTEM which is invoked by INTRA MAIL. PASSWORD AUTHENTICATION sends the required Query to MYSQL DB. MYSQL DB sends back the requested Query results. Then PASSWORD AUTHENTICATION authenticates the user and sends the result back to INTRA MAIL. INTRA MAIL on receiving data initiates the System and brings the TRUE USER to Inbox page. System sends mail to the other user implementing SMTP. All Messages and User details are stored in MYSQL DB. IF International Journal of Innovative Research and Studies Page 10

the INTRA MAIL is invoked to send mail outside the INTRANET i.e. to INTERNET (World Wide Web) it sends the mail to MERCURY MAIL SERVER. MERCURY MAIL SERVER authenticates the Standardization of mail and Sends it out to the INTERNET and Sends a confirmation message to INTRA MAIL that the MAIL is SEND to the respected user. User can send, save, download and delete mails. INTRA MAIL invokes the CHAT SYSTEM when its ask for. All the chat logs of respective user and according to Public and Private room are stored. INTRA MAIL access those chat logs according to the room and displays at respective CLIENT BROWSER. While Logout INTRA MAIL expires all the Cookies and Connection with the CLIENT BROWSER. 8.1.PHP MAIL: It is one of the most popular PHP based implementation of SMTP (Simple Mail Transfer Protocol). 8.2.MERCURY MAIL: MERCURY MAIL Server provides access to personal mail through the SMTP protocol. It uses a pseudo database format. This provides email only users who are totally separate from the local UNIX account database. The mailbox database is stored in parts of the file system that are private to the Mercury Mail. International Journal of Innovative Research and Studies Page 11

References: 1. For RFC2821: http://www.rfc-archieve.org 2. For PHP: http://www.netbeans.com 3. About SMTP: http://www.smtp.org 4. PHP tutorial: http//www.php.net 5. WIKIPEDIA, WKIBOOKS, WIKISCHOLARS, WKIMEDIA 6. GOOGLE BOOKS 7. PHP THE COMPLETE REFERNCE book. 8. PHP & MYSQL THE COMPLETE REFERENCE book. 9. HTML BLACK BOOK 10. AJAX THE COMPLETE REFERENCE 11. JAVASCRIPT THE COMPLETE REFERENCE International Journal of Innovative Research and Studies Page 12