Internet Draft B. Crouzet Document: draft-crouzet-amtp-01.txt Institute of Technology Tallaght Expires: April 2004 October 2003 Authenticated Mail Transfer Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Recent years have seen electronic mail becomes the first mode of communication. Electronic mail allows users to exchange information using different formats such as files, pictures, videos and text messages. Electronic mail is quicker and faster than other modes of communication but it generates more problems, such as email bombing, email virus, email spoofing, anonymous email, relaying email and in particular spam email. This Internet Draft aims at solving or reducing the above problems by proposing a new transfer protocol, Authenticated Mail Transfer Protocol. Authenticated Mail Transfer Protocol is a second modified version of the current transfer protocol, Simple Mail Transfer Protocol. It identifies a sender, differentiates a server from a user, changes the electronic mail structure and improves the electronic mail transaction. Crouzet Expires - April 2004 [Page 1] Authenticated Mail Transfer Protocol October 2003 The purpose of this document is to describe Authenticated Mail Transfer Protocol to the Internet community. The implementation of the new transfer protocol allows us to carry out a series of tests that measures and proves the performance and efficiency of the new transfer protocol. Conventions used in this document SA => Sender Server: SA represents an email server where the sender is known. SB => Recipient Server: SB represents an email server where the recipient is located. In examples, "C:" and "S:" indicate lines sent by the client and the server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction...................................................4 2. Presentation of Authenticated Mail Transfer Protocol (AMTP)....5 2.1 General View of Authenticated Mail Transfer Protocol.......5 2.2 Explanation of Authenticated Mail Transfer Protocol........5 2.3 Goals......................................................7 3. Authenticated Mail Transfer Protocol States....................7 3.1 Identified State...........................................7 3.1.1 Presentation of the Identified State.................7 3.1.2 Command in the Identified State......................7 3.2 Email State................................................8 3.2.1 Presentation of the Email State......................8 3.2.2 Command in the Email State...........................8 3.3 Logout State...............................................8 3.3.1 Presentation of the Logout State.....................8 3.3.2 Command in the Logout State..........................9 3.4 Information State..........................................9 3.4.1 Presentation of the Information State................9 3.4.2 Command in the Information State.....................9 3.5 Retrieved State...........................................10 3.5.1 Presentation of the Retrieved State.................10 3.5.2 Command in the Retrieved State......................10 4. Structure of an email in the Authenticated Mail Transfer Protocol header...........................................................10 Crouzet Expires - April 2004 [Page 2] Authenticated Mail Transfer Protocol October 2003 4.1 Relay Tag.................................................11 4.2 Head Tag..................................................11 4.3 Body Tag..................................................12 4.4 Example of an email structure.............................12 5. Authenticated Mail Transfer Protocol Commands.................13 5.1 Optional Commands.........................................13 5.2 Obsolete Commands.........................................14 5.3 Order of commands.........................................15 5.4 Authenticated Mail Transfer Protocol Procedures...........15 5.4.1 Simple Procedure....................................15 5.4.2 Procedure using optional commands...................16 5.4.3 Procedure with RSET command.........................18 6. Relay with Authenticated Mail Transfer Protocol...............19 7. Authenticated Mail Transfer Protocol Reply codes..............21 7.1 New Reply Codes...........................................21 7.2 Reply Codes from Request For Comment 2821.................22 8. Test Carried Out Against Email Problems.......................23 8.1 Test Authenticated Mail Transfer Protocol Against Anonymous Email.........................................................23 8.2 Test Simple Mail Transfer Protocol Against Anonymous Email23 8.3 Test Authenticated Mail Transfer Protocol Against Spoofed Email.........................................................24 8.4 Test Simple Mail Transfer Protocol Against Spoofed Email..24 8.5 Test Authenticated Mail Transfer Protocol Against Relaying Email.........................................................24 8.6 Test Simple Mail Transfer Protocol Against Relaying Email.25 9. Test Carried Out in a Network.................................25 9.1 Presentation..............................................25 9.2 Test the Transfer Protocol with Routers as a gateway......27 9.3 Test the Transfer Protocols with a Firewall as a gateway..27 9.4 Test the Transfer Protocols with a Proxy Server as a gateway27 9.5 Test the Transfer Protocols with a Firewall associated with a Proxy Server as a gateway.....................................28 9.6 Test the Transfer Protocol in a World Wide Web Simulation.28 10. Comparison of the Speed of the Two Transfer Protocols........28 11. Attack against an Authenticated Mail Transfer Protocol server30 11.1 Using the SELO command...................................31 11.2 Using the SEMA command...................................32 11.3 Overview of attacks against an Authenticated Mail Transfer Protocol server...............................................32 12. Conclusion...................................................33 Security Considerations..........................................34 References.......................................................34 Appendix.........................................................35 Appendix A: Acronyms..........................................35 Appendix B: Terminology.......................................36 Author's Addresses...............................................36 Copyright Notice.................................................36 Crouzet Expires - April 2004 [Page 3] Authenticated Mail Transfer Protocol October 2003 1. Introduction The last solution is to add an identification state to the Simple Mail Transfer Protocol, creating a new protocol to be called Authenticated Mail Transfer Protocol (AMTP). It would use the Transmission Control Protocol/Internet Protocol (TCP/IP) model to communicate across the network. AMTP is a five state process with three Client-to-Server communication states (Identified, Email and Logout states) and two Server-to-Server communication states (Information and Retrieved states). The first Client-to-Server state is the Identified state where the protocol asks for a username and a password to identify the user. The user has to log in successfully before he/she can use the server. The second state is the Email state where the user can employ any protocol commands in order to send an email. Once the user has logged onto the server, he/she does not have to enter his/her email address any more. The server will automatically add his/her email address to the email. The last state is the Logout state where the user is logged onto the system therefore he/she has to be logged out. There is also a new transaction between two email servers. The first Server-to-Server state is the Information state, whereby the sender server informs the recipient server that an email is waiting to be retrieved. The second state is the Retrieved state, whereby the recipient server retrieves the email from the sender server. Authenticated Mail Transfer Protocol will structure the email in order to provide an easier way to find information inside the email, to limit the access of the email by a user and finally, to validate the email itself. The structure of the email will allow a filter to be more efficient in order to look the most important fields. Authenticated Mail Transfer Protocol adds three XML tags that separate the information inside the email. A relaying server allows a sender server to route an email without knowing the address of the recipient server. A relaying server transmits the email to the recipient server or another relaying server like a normal Server-to-Server communication. In order to protect a network, it is possible to use a router, a firewall or a proxy server associated with a firewall. Under these protections, AMTP is operational. AMTP does not work behind a proxy server. Authenticated Mail Transfer Protocol both adds and removes commands from SMTP. The Authenticated Mail Transfer Protocol procedures are Crouzet Expires - April 2004 [Page 4] Authenticated Mail Transfer Protocol October 2003 demonstrated. It also adds new reply codes and uses identical reply codes from SMTP. This document explains the result of the series of tests that Authenticated Mail Transfer Protocol passed. Authenticated Mail Transfer Protocol is compared to Simple Mail Transfer Protocol in order to prove that the new protocol solves three email problems: anonymous, spoofed and relaying email. Four network simulations, a speed evaluation of these two protocols and different attacks against the new protocol have been carried out and tested. This demonstrates the efficiency and the performance of the new transfer protocol. In the Appendix chapter, acronyms and terminology are defined in Appendix A and B. 2. Presentation of Authenticated Mail Transfer Protocol (AMTP) Authenticated Mail Transfer Protocol (AMTP) is located at the Application layer of the Transmission Control Protocol/Internet Protocol (TCP/IP). The AMTP header handles and presents the data to the user. It analyses commands and replies to the user. 2.1 General View of Authenticated Mail Transfer Protocol The following figure gives a general view of the Authenticated Mail Transfer Protocol states. In the Identified state, the user has to be identified before he/she sends the email. The user writes his/her email in the Email state. At the end of the email, the server delivers the email to the recipient. If the recipient is internal, the email is immediately delivered to the recipient mailbox. If the recipient is external, the sender server uses the Information state. The recipient server executes the Retrieved state in order to retrieve the email from the sender server. These two states are reserved for an email server and are the result of the solution to identify a sender and validate a sender email address. --------------------------------------------------------------------- User -> Identified State -> Email State -> Logout State Sender server -> Information State -> Logout State Recipient server -> Retrieved State -> Logout State --------------------------------------------------------------------- Figure 2: General View of Authenticated Mail Transfer Protocol --------------------------------------------------------------------- 2.2 Explanation of Authenticated Mail Transfer Protocol The host server starts the Authenticated Mail Transfer Protocol service by listening to port 26. The email client establishes a TCP connection with the AMTP server. If the AMTP server accepts the Crouzet Expires - April 2004 [Page 5] Authenticated Mail Transfer Protocol October 2003 connection, it sends back a reply code 220. Now the AMTP server and the email client can exchange commands and replies. The AMTP server or the email client with the QUIT command can close or abort the transaction at any time. The Authenticated Mail Transfer Protocol session progresses through a number of steps during its lifetime. Once the TCP connection has been opened and the AMTP server has accepted the connection, the session enters into the Identified state. In this state, the user must identify himself/herself to the AMTP server. Once the user has successfully done this, the session enters into the Email state. In this state, the user will be allowed to request an action from the AMTP server. He/she can send an email to a random user. When the user has finished his/her session, he/she has to enter the QUIT command and the session enters into the Logout state, i.e. the AMTP server closes resources used such as the network connection (TCP), the database connection and the files. Authenticated Mail Transfer Protocol contains two server states: Information and Retrieved states. These states are reserved for the AMTP server only and occur in cases where the AMTP server has to send an external email. A user will be able to use the command but the transaction will be aborted after the AMTP server recognises the parameters are incorrect. Only one AMTP server, the sender server, recognises the user. The recipient server accepts information coming from the sender server or a user. The only thing email servers have in common is port 25. It is the only piece of information that an email server can recognise from another email server. Port 25 makes sure that the transaction takes place between two email servers and not between a user and a server. The first state is the Information state. In this state, the sender server informs the recipient server that an email is waiting to be delivered. The sender server gives the recipient server a number that refers to the email, the recipient email address and its IP address or domain name. The IP address or domain name is required to allow the recipient server to connect on to the sender server. The second state is the Retrieved state. In this state, the recipient server connects to the sender server to retrieve an email. It gives the number and the recipient email address that has been transmitted in the Information state. When these states are completed, the email servers close all resources used. These two states are automatic and fast because it is simply two computers that exchange data. Time out can be created when the server is waiting for a command. The two functions of these email servers are to send and read information and as such, they do not perform tasks that require time, resources or memory. Crouzet Expires - April 2004 [Page 6] Authenticated Mail Transfer Protocol October 2003 2.3 Goals This solution solves the problem of anonymous and spoofed email, and reduces the effect of email virus, email bombing and spam email. Therefore, everyone knows where the email comes from. The sender exists and the sender server recognises him/her. It does not stop spam email but a user has the possibility to avoid it and locate the sender. The solution still has to be tested to see if a hacker can crack it and if this solution is feasible on the network. 3. Authenticated Mail Transfer Protocol States 3.1 Identified State 3.1.1 Presentation of the Identified State This state is important because it protects a user from spoofed and anonymous email. Two new commands have been added to implement this state: USER and . When the AMTP server accepts the connection, the user enters into the Identified state. In this state, the user types the USER command that means he/she wants to be identified by the AMTP server. The AMTP server answers with the reply code 250 when it is ready to identify the user. The user types his/her username and password as a simple command. Any user can be identified with these parameters. There are three types of answers for the server. In the case of the username and password corresponding to one user, the server replies with the code 250 and sends him/her helpful server information. The AMTP server now identifies the user who can now use any AMTP commands. In the case of the username and password being incorrect, the server replies with the code 401. After the third try from the user, the server closes the connection and replies with the code 555. 3.1.2 Command in the Identified State USER The user enters the USER command to inform the AMTP server that he/she wants to be identified by the server. The USER command does not need any parameters. The user needs to enter his/her username and password, which contain no space in them. In order to protect the user, the username has to be different from his/her email address. In addition to this, the username and password are entered after the USER command in order to protect this data. It will be difficult for a hacker to find these parameters. If the hacker is watching the network, he/she has to catch the USER command and the packet with the username and password data, which contains no sign of them. Crouzet Expires - April 2004 [Page 7] Authenticated Mail Transfer Protocol October 2003 3.2 Email State 3.2.1 Presentation of the Email State In this state, the user can send an email. Once the user is logged into the AMTP server, he/she does not have to enter his/her email address any more. The AMTP server adds his/her email address into the email header. The MAIL FROM command has been removed from the transfer protocol. The RCPT TO and DATA command from SMTP are still used in this state. Two new commands, MORE TO and HEAD, have been added in order to improve the service of the transfer protocol. The user enters a recipient email address using the command: RCPT TO: . The AMTP server validates the email address and acknowledges if the recipient email address is internal or external to the system. If it is internal, the server checks if the user exists or not and sends back the appropriate reply code: an error message in case the user does not belong to the server. If it is external to the system, the AMTP server does not check the recipient email address, it just validates it. The AMTP server continues the process and the user enters the DATA command to specify the email body. The user writes the content and the AMTP server stores his/her data on an email. If the recipient email address is internal, the AMTP server transports directly the email to the recipient mailbox. If the recipient email address is external, the AMTP server starts the Information state. 3.2.2 Command in the Email State RCPT TO: [, ] This RCPT TO command is used to identify an individual recipient of the email. It is the same command described in RFC 2821 [2], therefore reply codes are the same. The parameter for this command can be a list of recipient email addresses separated by a comma (æ,Æ). The command returns information about the validity of the recipient email address. DATA The user uses this command to enter the email content. When the AMTP server accepts the DATA command, it has to send an email to the recipient. It is the same command described in RFC 2821 [2]. Reply codes are the same. 3.3 Logout State 3.3.1 Presentation of the Logout State The Logout state is used to close the connection between the AMTP server and the email client when the user has finished with his/her email and wants to leave the AMTP server. The AMTP server closes all resources used like the database, the TCP channel, the files and the thread. The user uses the QUIT command to terminate the transaction. Crouzet Expires - April 2004 [Page 8] Authenticated Mail Transfer Protocol October 2003 3.3.2 Command in the Logout State QUIT The QUIT command does not need any parameter. The server replies with the code 221. It is only after this reply code that the transaction is finished. It is the same command described in RFC 2821 [2], therefore reply codes are the same. 3.4 Information State 3.4.1 Presentation of the Information State In this state reserved for the server only, the sender server contacts the recipient server. The sender server connects to the recipient server and receives the reply code 220. Then, the sender server sends the SELO command with three parameters that are the domain name of the sender server, a unique number created by the sender server and the recipient email address. The recipient server verifies if the domain name or IP address corresponds to the parameters found in the network packet. It checks if the recipient email address exists or not in its server. If the recipient email address is unknown, the recipient server sends the error back to the sender server; the sender server sends it back to the user and deletes the email. If the process is handled successfully, the recipient server continues with the Retrieved state. In the case of the server being a relay to distribute the email, the sender server proceeds normally. The relaying server will retrieve the email and send the number to the recipient server. The sender server will only proceed with the relaying server. The relaying server does not need to check the recipient email address. In a relaying server, the domain name is the only barrier that could stop an email from being sent. 3.4.2 Command in the Information State SELO The SELO command needs three parameters: DOMAIN, NUMBER and RECIPIENT EMAIL ADDRESS. The DOMAIN parameter can be the IP address or the domain name of the sender server. It allows the recipient server to establish a connection with the sender server. The NUMBER parameter is the email identifier. This parameter allows the sender server to recognise the email. The RECIPIENT EMAIL ADDRESS parameter is used to identify a recipient email address. The sender server saves these parameters and the address of the recipient server. If the recipient server knows the recipient email address or if the domain name is in the relaying table, it sends back answers by the reply code 250. If these two conditions are not met, the recipient server answers with the reply code 550. If it is successful, the recipient server enters into the Retrieved state. Crouzet Expires - April 2004 [Page 9] Authenticated Mail Transfer Protocol October 2003 3.5 Retrieved State 3.5.1 Presentation of the Retrieved State In the Retrieved state, the recipient server establishes a connection with the sender server to retrieve the email with the number given in the Information state. If the connection is successful, the sender server answers by the reply code 220. Then, the recipient server sends the SEMA command with two parameters separated by a colon (æ:Æ). These two parameters are the recipient email address and the unique number. The sender server checks if these parameters exist or not in its email queue. If the number, the address of the recipient server and recipient email address are correct, the message will be given to the recipient server. The recipient server stores the email and the email appears in the recipient mailbox. In case the number and the recipient email address are incorrect, the sender server sends an error message to the recipient server. The relaying server proceeds through this state. The difference between a relaying server and a recipient server is that the relaying server will start the Information State to inform another relaying server or the recipient server. The relaying server will store the email and create a number to use the SELO command. It implements a relay queue to keep sending the email. 3.5.2 Command in the Retrieved State SEMA : This command is reserved for the AMTP server. It needs two parameters: RECIPIENT EMAIL ADDRESS and NUMBER. The RECIPIENT EMAIL ADDRESS parameter is the recipient email address. The NUMBER parameter is a number used to recognise the email on the sender server. If the number exists, the sender server will send the data together. If the number is wrong, the connection will be closed. If the email has not been retrieved and the lifetime of the email has expired, the AMTP server will inform the sender about it. The sender can resend the email. The AMTP server will keep evidence of this email and inform the administrator about the fact that the email has not been retrieved. The administrator can think about the reason why the email was not delivered. 4. Structure of an email in the Authenticated Mail Transfer Protocol header The email client needs to make a distinction between the email header, the relaying information and the email and its body. When an email client writes an email, there is a small distinction between the email header information and the email body. For example, the subject is entered with the email body. This option is technical and a user will not see the difference in the email client. Crouzet Expires - April 2004 [Page 10] Authenticated Mail Transfer Protocol October 2003 Authenticated Mail Transfer Protocol modifies the structure of the email. The header will be entered separately from the data. AMTP adds the version of the transfer protocol used into the server information: Version 1.0 for SMTP and Version 2.0 for AMTP. By adding this parameter, a recipient server can prevent a user from risks incurred with SMTP. An AMTP server can accept an email from a SMTP server and insert the version of the protocol into the server information. The server information has the same content as the header field ôReceived Fromö in SMTP. Using XML tags in the email, the server will be able to directly detect the information it needs. The sender server enters these tags. These XML tags are: => contains the relaying server information . => contains the header information of the email . => contains the body information of the email . 4.1 Relay Tag In the relay tag, the information about the relaying server is specified. The relaying server should enter information about the sender server and the recipient server using the header field ôRELAY FROM: TO ö. The recipient server information or the sender server information could be a relaying server. With this information, it will be possible to identify a relaying server from the sender server and to determine the route of the email. 4.2 Head Tag In the head tag, the information about the email is specified. A new header field is introduced in order to distinguish the sender server. The line ôSend From:ö is used to display the sender server information. To avoid a hacker entering data in the email header, this head tag is reserved for the sender server. To implement this solution, an order of lines will be specified. This order will ensure the email is correct. The order is: => Sender details: The line ôFrom: sender email address < name >ö. => Sender server: The line ôSend From:ö with the server information and the version of the transfer protocol used. => Date: When the email was written. => Message Identifier: The line ôMessage id: ö. => Recipient details: The line ôTo: recipient email address < name >ö. => Subject: It is the subject of the email. => Other header: These lines are used to enter different headers that are not necessary for the delivery of an email. => MIME details: The details for the MIME protocol. Crouzet Expires - April 2004 [Page 11] Authenticated Mail Transfer Protocol October 2003 In order to distinguish the email header information from the email body information, the HEAD command is introduced. The user uses this command to enter MIME type information. For a simple text message in ASCII characters, the user can enter the header ôsubjectö into the email content using the DATA command. The header ôsubjectö will be added into the head tag. If a user does not type the HEAD command, the server detects a simple email and presents the email header correctly. The server adds the line ôsubjectö into the email and the content will be entered into the body tag. If a user enters the HEAD command, he can type his/her information about the email. The first lines of the header are reserved for the server. The server adds the header: ôFromö, ôSend Fromö, ôDateö, ôMessage idö, and ôToö. After these lines, the user inserts header data that can contain different information for instance a MIME type. 4.3 Body Tag The body tag is used to enter the email content. Any information in this tag will be considered as body information. This information will be displayed to the recipient as the email part. 4.4 Example of an email structure The format of the email is: Relay from: < master.com (193.1.124.54); 06 June 2003 15:55:12 o'clock IST; Version: 2.0> TO From: bcrouzet@master.com Send From: master.com (193.1.124.54); 06 June 2003 15:55:12 o'clock IST; Version: 2.0 Date: 06 June 2003 15:55:12 o'clock IST Message id: 1055034769259 To: 2@master.org Subject: XML Tags It is a demonstration of the new mail structure with three XML tags. The advantage of these XML tags is to preserve the structure of the email. A user cannot change the information during the process of transferring an email. The sender server completes the XML tags HEAD and BODY. The recipient server and the relaying server modify the XML tag RELAY. Useful information is classified and available without searching in the email. AMTP adds an email structure in Crouzet Expires - April 2004 [Page 12] Authenticated Mail Transfer Protocol October 2003 order to detect the relay, header and body information quicker that Simple Mail Transfer Protocol. 5. Authenticated Mail Transfer Protocol Commands 5.1 Optional Commands RSET The RSET command allows a user to reset any action that has already been activated. It allows a user to restart the transaction from the beginning. It is the same command described in RFC 2821 [2]. The reply codes are identical. NOOP The NOOP command allows a user to reset the timer. It is the same command described in RFC 2821 [2]. The reply codes are the same. HELP [] The HELP command gives a user some information about the command it provides. It provides useful information for the client. It is the same command described in RFC 2821 [2]. The reply codes are identical. If a user enters a topic as a parameter, the system provides information on this topic. MORE TO: [, ] The MORE TO command allows a sender to add more recipient email addresses to the email without changing the first recipient email address entered or to correct a recipient email address entered wrongly with the RCPT TO command. The RCPT TO command does not correct invalid email address. The MORE TO command can be used after the RCPT TO command and does not replace the RCPT TO command. Using the MORE TO command, the sender corrects invalid email addresses. The parameter specifies multiple recipient email addresses separated by a comma (æ,Æ). This command gives the validity of the recipient email address. The advantage of the MORE TO command is to prevent a user from retyping a valid email address using the RCPT TO command. A user can enter the MORE TO command to add different recipients to the email. The programme has to store all valid recipient email addresses during the process. This could be a little inconvenient but this command saves time in the overall process. HEAD A user types the HEAD command to enter the email header details. This command is like the DATA command, is entered before the DATA command and separates the email header from its body. The server replies with the code 354 to enter the email header details. To finish entering the email header details, the user enters a dot (æ.Æ). The AMTP server stores the email header and wait for the DATA command. The email header is always in American Standard Code for Crouzet Expires - April 2004 [Page 13] Authenticated Mail Transfer Protocol October 2003 Information Interchange (ASCII) characters and no code has to be given in reply to the user. The advantage of the HEAD command is to differentiate between the header information to the body information. This command specifies the header information of the email. The user or the programme uses it when the email is complex. The drawback is that the programme or the user has to enter the header information into this command during the Client-to-Server transaction; it therefore adds time to the overall process. 5.2 Obsolete Commands MAIL FROM The sender server manages this command and adds the sender email address to the email. It is a hidden field like the ôreceived fromö field. EHLO Since a user has to be identified by the server, there is no point to keep this command but the result of the EHLO command is important. It gives helpful information about the server to the user. The result will be displayed after the user has been identified. TURN This command allows a client to become a server and the server to become the client. For security reasons, this command has been disabled. VRFY A user will be unable to verify an email address for security reasons. It is important to know and check an email address but today phone, letter or email communications can transmit email addresses. EXPN For security reasons, this command has been removed from the protocol. This command confirms that the argument is a mailing list. It is dangerous because a user can know the name of a mailing list and diffuse it. HELO This command comes from RFC 821 [1] and been replaced in RFC 2821 [2] by the EHLO command. There is no point in keeping this command in the protocol. SEND It is rarely implemented. There is no point in keeping this command and since the protocol changed, this command is obsolete. SOML Crouzet Expires - April 2004 [Page 14] Authenticated Mail Transfer Protocol October 2003 It is rarely implemented. There is no point in keeping this command and since the protocol changed, this command is obsolete. SAML It is rarely implemented. There is no point in keeping this command and since the protocol changed, this command is obsolete. 5.3 Order of commands There are restrictions on the order in which these commands may be used. A session starts with the USER command. After this, a user enters his/her username and password. The server accepts the client if he/she is identified and lets him/her continue the transaction. The NOOP, HELP and RSET commands can be used at any time during a session or without previously initialising a session. The RCPT TO command begins the construction of the email. It specifies the recipient email address or multiple recipient email addresses. A user can add more email addresses with the MORE TO command that also allows a user to correct an email address. If a user has a complex email header, he/she enters the HEAD command. He/she continues in any case with the DATA command to send the email. The transaction can be aborted by the RSET command. There may be zero or more email in the session. To close the connection, a user types the QUIT command. He/she requests the end of the session. 5.4 Authenticated Mail Transfer Protocol Procedures 5.4.1 Simple Procedure A simple AMTP procedure for a user is: S: 220 AMTP >> Connection successful. S: 250 AMTP >> Received from: postgrad-bc 193.1.124.54. S: 250 AMTP >> C: user S: 250 AMTP >> Server Ready C: bct 123 S: 250 AMTP >> Welcome Brice CROUZET to the AMTP server. S: 250 AMTP >> SERVER INFORMATION. S: 250 AMTP >> C: rcpt to:jdoody@master.com S: 250 Recipient accepted for "jdoody@master.com" To add or correct a recipient address, please use the command MORE TO S: 250 AMTP >> C: data S: 354 Enter the data of the message. End with "." on a line by itself. Crouzet Expires - April 2004 [Page 15] Authenticated Mail Transfer Protocol October 2003 C: Subject: AMTP Procedure 1 C: It is a simple AMTP procedure. C: . S: 250 Mail delivery successful for "jdoody@master.com" S: 250 AMTP >> C: quit S: 221 Disconnection The email has been received: From: bcrouzet@master.com Send From: master.com (193.1.124.54); 09 April 2003 08:56:50 o'clock IST; Version: 2.0 Date: 09 April 2003 08:56:50 o'clock IST Message id: 1049998467218 To: jdoody@master.com Subject: AMTP Procedure 1 It is a simple AMTP procedure. 5.4.2 Procedure using optional commands An AMTP procedure using optional commands is: S: 220 AMTP >> Connection successful. S: 250 AMTP >> Received from: postgrad-bc 193.1.124.54. S: 250 AMTP >> C: user S: 250 AMTP >> Server Ready C: bct 123 S: 250 AMTP >> Welcome Brice CROUZET to the AMTP server. S: 250 AMTP >> SERVER INFORMATION. S: 250 AMTP >> C: help S: 214 This is an AMTP Server. 214 Topics: 214 QUIT HELP RCPT HEAD DATA RSET NOOP S: 250 AMTP >> C: help data S: help for DATA S: Explanation S: 250 AMTP >> C: noop S: 250 AMTP >> Noop OK S: 250 AMTP >> C: rcpt to:jdoody@master.com Crouzet Expires - April 2004 [Page 16] Authenticated Mail Transfer Protocol October 2003 S: 250 Recipient accepted for "jdoody@master.com" To add or correct a recipient address, please use the command MORE TO S: 250 AMTP >> C: more to:bcrouzet@master.com S: 250 Recipient accepted for "bcrouzet@master.com" To add or correct a recipient address, please use the command MORE TO S: 250 AMTP >> C: head S: 354 Enter the header of the message. End with "." on a line by itself. C: Subject: AMTP Procedure 2 C: . S: 250 Head Command Accepted S: 250 AMTP >> C: data S: 354 Enter the data of the message. End with "." on a line by itself. C: Subject: Test C: It is an AMTP procedure using optional commands. C: . S: 250 Mail delivery successful for "jdoody@master.com", "bcrouzet@master.com" S: 250 AMTP >> C: quit S: 221 Disconnection The email for jdoody@master.com has been received: From: bcrouzet@master.com Send From: master.com (193.1.124.54); 09 April 2003 09:00:17 o'clock IST; Version: 2.0 Date: 09 April 2003 09:00:17 o'clock IST Message id: 1049998673855 To: jdoody@master.com Subject: AMTP Procedure 2 Subject: Test It is an AMTP procedure using optional commands. The email for bcrouzet@master.com has been received: Crouzet Expires - April 2004 [Page 17] Authenticated Mail Transfer Protocol October 2003 From: bcrouzet@master.com Send From: master.com (193.1.124.54); 09 April 2003 09:00:17 o'clock IST; Version: 2.0 Date: 09 April 2003 09:00:17 o'clock IST Message id: 1049998673895 To: bcrouzet@master.com Subject: AMTP Procedure 2 Subject: Test It is an AMTP procedure using optional commands. 5.4.3 Procedure with RSET command An AMTP procedure using the RSET command is: S: 220 AMTP >> Connection successful. S: 250 AMTP >> Received from: postgrad-bc 193.1.124.54. S: 250 AMTP >> C: user S: 250 AMTP >> Server Ready C: bct 123 S: 250 AMTP >> Welcome Brice CROUZET to the AMTP server. S: 250 AMTP >> SERVER INFORMATION. S: 250 AMTP >> C: rcpt to:jdoody@master.com S: 250 Recipient accepted for "jdoody@master.com" To add or correct a recipient address, please use the command MORE TO S: 250 AMTP >> C: rset S: 250 AMTP >> Reset OK S: 250 AMTP >> C: data S: 503 Need RCPT before DATA "data". S: 250 AMTP >> C: rcpt to:2@master.org S: 250 Recipient accepted for "2@master.org" To add or correct a recipient address, please use the command MORE TO S: 250 AMTP >> C: data S: 354 Enter the data of the message. End with "." on a line by itself. C: Subject: AMTP Procedure 3 C: It is an AMTP procedure using RSET command. C: . S: 250 Mail in the spool for delivery for "2@master.org". S: 250 AMTP >> Crouzet Expires - April 2004 [Page 18] Authenticated Mail Transfer Protocol October 2003 C: quit S: 221 Disconnection The email has been received: Relay from: TO From: bcrouzet@master.com Send From: master.com (193.1.124.54); 09 April 2003 09:02:13 o'clock IST; Version: 2.0 Date: 09 April 2003 09:02:13 o'clock IST Message id: 1064375633560 To: 2@master.org Subject: AMTP Procedure 3 It is an AMTP procedure using RSET command. 6. Relay with Authenticated Mail Transfer Protocol An open relay or relaying server is an email server that allows people to relay email. By processing email that is not for or from a local user, a relaying server makes it possible for an unscrupulous sender to route large volumes of spam email. The advantages of a relaying server are that a sender can send an email from anywhere outside his/her email network, a sender can use any application and the sender server does not have to know each recipient server to transfer an email. The drawback of a relaying relay is that spammers use it in order to hide their identity and the source of their personal computer. The relaying server only adds its information in the email header but it cannot verify the sender email address or insert any information concerning the sender identity. With Authenticated Mail Transfer Protocol, the relaying server that allows people to relay email will do exactly the same transaction as a recipient server. It receives the notification for an email and retrieves the email. After this transaction, it will inform the recipient server that an email has to be retrieved on the relaying server. The email will arrive to the recipient even if the email passes by a relaying server. The transaction between the sender and the recipient within a relay will be longer than if there was a direct link between the two email servers. The advantages are that the spammer cannot use the relaying server to send anonymous and spoofed email and the sender server does not have to know each recipient server to transfer an email. --------------------------------------------------------------------- Crouzet Expires - April 2004 [Page 19] Authenticated Mail Transfer Protocol October 2003 Sender <- AMTP -> Sender Server <- AMTP -> Relay Server <- AMTP -> Recipient Server <- POP or IMAP -> Recipient --------------------------------------------------------------------- Figure 3: Presentation of transaction with a relay server --------------------------------------------------------------------- The sender server transfers an external email to the relaying server. When the route to send an email to the recipient is not known by the sender server, it goes through a relaying server to accomplish the transaction. The sender server enters into the Information state and informs the relaying server that an email is waiting to be retrieved. The relaying server accepts the email if it knows the recipient server or another relaying server that it can send the email to by checking its route table. The relaying server enters into the Retrieved state and retrieves the email from the sender server. Instead of storing the email in the recipient mailbox, it stores the email as an external email and informs the recipient server or another relaying server about it. The email is stored into the relaying server and no longer in the sender server. The relaying server continues with the Information state and waits for an answer from the recipient server. The recipient server checks and validates the recipient email address. If the recipient email address does not exist, it sends back an error message to the relaying server that sends an email to the sender to inform him/her about the fact that the recipient email address is incorrect. If the recipient email address is correct, the recipient server enters into the Retrieved state. It retrieves the email from the relaying server and stores the email in the recipient mailbox. The transaction between a sender server and a relaying server is identical to a transaction between a sender server and a recipient server. The same transaction is also used between a relaying server and a recipient server. The difference with a relaying server is that the email has to be sent to another server. The relaying server will change the NUMBER parameter in the SELO command, by creating a new one to avoid a copy of the email. The procedure of the AMTP relaying function is: --------------------------------------------------------------------- Step1: Sender email Client --> Sender server Using AMTP logout state, AMTP identified state and AMTP mail state --------------------------------------------------------------------- Step 2: Sender server --> Relaying server Using AMTP information state Crouzet Expires - April 2004 [Page 20] Authenticated Mail Transfer Protocol October 2003 Sender server <-- Relaying server Using AMTP Retrieved state --------------------------------------------------------------------- Step 3: Relaying server --> Relaying server Using AMTP information state Relaying server <-- Relaying server Using AMTP Retrieved state --------------------------------------------------------------------- Step 4: Relaying server --> Recipient server Using AMTP information state Relaying server <-- Recipient server Using AMTP Retrieved state --------------------------------------------------------------------- Step5: Recipient server <-- Recipient email client Using POP3 or IMAP transaction --------------------------------------------------------------------- Authenticated Mail Transfer Protocol is operational as a relaying server. The relaying server is used to transfer email to a recipient server. Authenticated Mail Transfer Protocol is therefore protected against anonymous and spoofed email. A user can send an email to his/her server and use the relaying server to transfer an email to other email servers. 7. Authenticated Mail Transfer Protocol Reply codes 7.1 New Reply Codes Reply codes are important for a server and a user because it permits them to know if the transaction is correct or not. The reply code 555 informs the server for any errors that occur between two servers. The error permits the server to take action of it. There are four types of error: during the Identified state, during the transaction to send an email (Email State) and during the transaction between two servers for the commands SELO and SEMA. For the Identified state, the reply codes are: => 503 Use the Command USER before other commands. => 401 User unknown û Enter the user information again - only 3 times. => 505 User does not exist û Connection close. => 250 User Accepted. When the user sends an email, the reply codes are: Crouzet Expires - April 2004 [Page 21] Authenticated Mail Transfer Protocol October 2003 => 501 The email is wrong. => 551 User not local. => 250 Server Ready. When the server uses the command SELO, the reply codes are: => 555 Selo command error û Recipient Unknown, Argument missing, Command Unknown or Result Unknown. => 250 Selo Accepted. => 250 Mail accepted for delivery. When the server uses the command SEMA, the reply codes are: => 555 Sema command error û Argument missing, Mail does not exist, Command Unknown or Result Unknown. => 555 Mail error. => 250 Sema Accepted. => 250 Mail delivered. 7.2 Reply Codes from Request For Comment 2821 Positive Completion replies are: => 211 System status or system help reply. => 214 Help message. => 220 Service ready. => 221 Service closing transmission channel. => 250 Requested mail action okay, completed. => 251 User not local. => 252 Cannot VRFY user, but will accept message and attempt delivery. Positive Intermediate reply is: => 354 Start mail input; end with. Transient Negative Completion replies are: => 421 Service not available, closing transmission channel. => 450 Requested mail action not taken: mailbox unavailable. => 451 Requested action aborted: local error in processing. => 452 Requested action not taken: insufficient system storage. Permanent Negative Completion replies are: => 500 Syntax error, command unrecognized. => 501 Syntax error in parameters or arguments. => 502 Command not implemented. => 503 Bad sequence of commands. => 504 Command parameter not implemented. => 550 Requested action not taken: mailbox unavailable. => 551 User not local; please try. => 552 Requested mail action aborted: exceeded storage allocation. => 553 Requested action not taken: mailbox name not allowed. => 554 Transaction failed. Crouzet Expires - April 2004 [Page 22] Authenticated Mail Transfer Protocol October 2003 8. Test Carried Out Against Email Problems 8.1 Test Authenticated Mail Transfer Protocol Against Anonymous Email The different tests on Authenticated Mail Transfer Protocol show that a user cannot send an anonymous email. The user was not able to change and to enter his/her email address during the process of sending an email. The old commands from SMTP (HELO, EHLO and MAIL FROM) do not work with AMTP. The user can only enter the recipient email address and his/her message. The user cannot modify the email in order to change or to enter a sender email address. The message is entered in the XML tag BODY and the sender server completes the email header using the XML tag HEAD. The sender server enters the sender email address into the email and sends the email at the end of the transaction to the correct recipient. Authenticated Mail Transfer Protocol stops anonymous email. This is the goal of the protocol. The only possible way to send an email is to access the email server. The hacker has to create a file in the email server and a row in the email server database. Therefore, he/she can use the SELO command to inform the recipient server. 8.2 Test Simple Mail Transfer Protocol Against Anonymous Email The test shows that it is possible to receive an email from an invalid email address from the same or a different domain name for the three external email servers and for the server prototype. When the user replies to the email, the server returns a delivery message from the sender server or an error message from the client interface. The email received contains some useful information that allows an expert to find an evidence of the sender. Examination of the line "Received From" in the email header makes the email traceable. Microsoft Exchange provides the IP address of the sender computer. Using a provider and a modem, the line "Received From" contains the IP address of the Internet provider used for the connection. Therefore, it is impossible to determine the address of the sender computer. In addition to this, the email provider Free does not provide a complete email header: the line ôFromö is unspecified. Therefore, it is impossible to reply to the sender. It is possible to find a sender email address by looking at the email source: The field ôReturn-Pathö gives the user the sender email address. The web interface of the postfix server allows a user to modify his/her email address without finding any information about the true sender in the email header. With Simple Mail Transfer Protocol, it is possible to send an anonymous email with an external or internal sender email address. Different countermeasures exist such as time out, different email servers or a web server. These tests are simple and stay in the Crouzet Expires - April 2004 [Page 23] Authenticated Mail Transfer Protocol October 2003 protocol level. A hacker will study the email server to see if he/she can use it. These tests still prove that Simple Mail Transfer Protocol is insecure. In addition to this, email servers do not respect the email format. Therefore, different applications such as Outlook Express or Microsoft Outlook cannot use the email header. 8.3 Test Authenticated Mail Transfer Protocol Against Spoofed Email The different tests on Authenticated Mail Transfer Protocol show that a user cannot send a spoofed email. The user was not able to change or to enter his/her email address during the process of sending an email using the old commands of SMTP: EHLO, HELO or MAIL FROM. The user has to enter the recipient email address and his/her message. He/she cannot enter a sender email address in the email header or use another email to change the sender email address. Authenticated Mail Transfer Protocol stops spoofed email and is the goal of this protocol. There are two possible ways to send a spoofed email. The first possibility is to find a username and a password; therefore, a user can send a spoofed email. The second way is to access the email server in order to create a file in it and a row in its database. Therefore, a user can use the SELO command to inform the recipient server about an email created by him/her waiting to be retrieved. 8.4 Test Simple Mail Transfer Protocol Against Spoofed Email The test shows that it is possible to receive an email from someone elseÆs email address from the same or a different domain name for the three external email servers. The sender did not send this email but someone else did. All sender email addresses used for this test are valid. Therefore, there is no need to send a reply to the sender. For all email servers, the server accepts any sender email address without verifying the domain name of the sender. The web interface of the Postfix server shows that it is possible to send an external email using someone elseÆs email address without any information in the email header about the true sender. The only information is the header field "X-Originating-IP". These tests prove that Simple Mail Transfer Protocol is insecure. 8.5 Test Authenticated Mail Transfer Protocol Against Relaying Email The test shows that it is possible to use a relaying server in order to send an external email with Authenticated Mail Transfer Protocol. The sender sends his/her email to the sender server. The sender server transmits the email to the relaying server using the Information and Retrieved states. The relaying server relays the email to the recipient server using the Information and Retrieved states. The recipient server retrieves and copies the email into the recipient mailbox. The recipient is able to read his/her email using the protocol POP3 implemented on the server prototype. In the email, Crouzet Expires - April 2004 [Page 24] Authenticated Mail Transfer Protocol October 2003 the XML tag RELAY contains all the relay information in order to be able to trace the route of the email and to find all email server addresses. 8.6 Test Simple Mail Transfer Protocol Against Relaying Email The test shows that it is possible to send an email to an external recipient using a relaying server on condition that the instructions of the RFC 821 (Simple Mail Transfer Protocol) are followed. The transaction between a client and a server is identical to the transaction between a server and a server. Simple Mail Transfer Protocol allows a sender to relay an email from any email server. This test demonstrates that a real email server is not able to relay an email and to send an external email. The user has to use a Graphical User Interface provided by the email server to send an external email. Administrators have turned off the relaying function in order to protect the user against spam email. Microsoft Exchange, the Mail Transfer Agent Exim and Postfix do not authorise any user to send external email. This test has been conducted with a command prompt using a telnet connection and the protocol SMTP. A simple study of the server information provided by any of these email servers does not allow a user to find an access to the email server. Therefore, it is difficult for an external user to send an email outside his/her network. Current email servers provide a Web interface in order to solve this problem but a programmer cannot use his/her client interface in order to send an email. 9. Test Carried Out in a Network 9.1 Presentation In order to protect a network, it is possible to use a router, a firewall, a proxy server or a firewall associated with a proxy server. It is important to accept or refuse requests coming from outside the network or leaving the network. A network has to be protected in order to increase the security of the user data. The following figure represents one possibility for protection of a network. Network 1 is outside Network 2. The router, the firewall or the proxy server is used as a gateway that allows Network 2 to establish a route to Network 1. When an administrator combines these protections, the diagram for the network is different. In any case, an administrator needs a gateway to connect Network 1 with Network 2. It is possible to have a firewall, a proxy server and a router in Network 2 in order to increase the security of the network. --------------------------------------------------------------------- Sender <- AMTP -> Sender Server on network 1 <- AMTP -> Firewall, Router or Proxy Server <- AMTP -> Recipient Server --------------------------------------------------------------------- Figure 3: Presentation of protections for the network Crouzet Expires - April 2004 [Page 25] Authenticated Mail Transfer Protocol October 2003 --------------------------------------------------------------------- The first protection is a router. A router is a physical device that joins multiple networks together in order to form the World Wide Web. Routers have the ability to filter traffic, either incoming or outgoing based on the IP addresses of senders and receivers. The Access List in a router is used to ban or to authorise some packets to enter the network. The Access list has to be configured in the router configuration. The second protection is a firewall. A firewall is used to filter IP packets going into, or coming out of the network. A firewall can block, forward or pass the packet to the final recipient. The firewall can be set up to filter a protocol (i.e. TCP, UDP or ICMP), a port, an IP address or a range of IP addresses. A firewall is the most powerful tool to filter the packets from the network but not to protect the IP address of the network. A firewall is a system or combination of systems that enforces a boundary between two or more networks and keeps intruders out of internal networks. Firewalls serve as barriers for packets passing from one network to another. The command IPCHAINS [5] creates a firewall under Linux. The software ôSolidShare 2.0ö [6] is used as a firewall under Windows. The configuration of these two firewalls is to accept TCP connections and refuse UDP and ICMP connections. The last protection is a proxy server. A proxy server is used to filter the packet going into, or coming out of the network. It is similar to a firewall but the proxy server will keep the network completely inaccessible from outside the network. The proxy server redirects any queries (HTTP, SMTP or FTP) to the server in charge of the protocol whether it is inside or outside the network. From an outside point of view, the user believes the proxy server is the server in charge of the network. He/she cannot establish a connection to any server inside the network except the proxy server. In order to establish a transaction going out of the network, the user establishes a connection with the proxy server and then the proxy server requests the userÆs queries. The proxy server changes the user IP address in the packet and replaces it by its IP address. A proxy is a system that allows a network to share a single Internet connection. The shared Internet connection can be anything from a dialup modem to a dedicated T1 circuit. Under Linux, the proxy server is ôTCPProxy 1.1.6ö [7] and under Windows, the proxy server is ôGateKeeper Pro 4.5ö [8]. An administrator can combine these protections and obtain a well- protected and secured network. The challenge for him/her is to find the right configuration that protects every server and computer, and Crouzet Expires - April 2004 [Page 26] Authenticated Mail Transfer Protocol October 2003 allows the user to have access to all data authorised outside and inside the network. 9.2 Test the Transfer Protocol with Routers as a gateway The test consists in sending an email with SMTP or AMTP between two email servers through routers (CISCO 2600 and CISCO 2500). The test is conducted with the prototype on an internal network. Four tests were performed with one, two, three and four routers. In each test, the transaction with the two protocols was carried out. The IP address of the sender address (192.5.5.10) is identical for the series of tests. The IP address of the recipient server changes according to of the test. The four routers have been configured to accept the transfer of all packets in any direction. The result of the test shows that Authenticated Mail Transfer Protocol and Simple Mail Transfer Protocol are operational behind routers. For the series of tests, these two protocols are able to transmit and receive information through routers. The sender server communicates through different routers and finds the route of the recipient server. Therefore, AMTP and SMTP can access the World Wide Web with no difficulty. 9.3 Test the Transfer Protocols with a Firewall as a gateway The result of the test shows that Authenticated Mail Transfer Protocol and Simple Mail Transfer Protocol are operational behind a firewall. For the series of tests, these two protocols were able to transmit and receive information through a firewall. 9.4 Test the Transfer Protocols with a Proxy Server as a gateway A proxy server replaces the IP address of the packet before it is forwarded to the email server. The goal of the proxy server is to avoid people learning the address of any computer inside the local network. SMTP is operational behind a proxy server because the protocol does not verify the IP address of the packet and does not use the IP address of the sender server. An AMTP server does not work behind a proxy server because the proxy server changes the IP address in the packet but not the IP address of the SELO command. Therefore, the recipient server is unable to establish connection with the sender server. Two solutions can be implemented: The AMTP server runs on the same computer as the proxy server OR the programme does not check the IP address of the packet behind a proxy server. The first solution for AMTP is to have the email server on the same computer as the proxy server. Therefore, it is the same test as to send an external email on the same network. The test was carried out and showed that it works. The second solution for AMTP is to modify the protocol in order not to compare the IP address of the packet with the IP address of the SELO command. The programme enters the IP address of the proxy, and it Crouzet Expires - April 2004 [Page 27] Authenticated Mail Transfer Protocol October 2003 can execute the Retrieved state but the level of security of the protocol is decreased. These two solutions allow an AMTP server to work behind a proxy server. 9.5 Test the Transfer Protocols with a Firewall associated with a Proxy Server as a gateway The result of the test shows Simple Mail Transfer Protocol and Authenticated Mail Transfer Protocol are operational behind a firewall associated with a proxy server. The firewall lets the packet go to the email server without changing the IP address of the packet. The proxy server does not touch the packet. For the series of tests, these two protocols were able to transmit and receive information through a firewall. 9.6 Test the Transfer Protocol in a World Wide Web Simulation The result of the test shows that Authenticated Mail Transfer Protocol and Simple Mail Transfer Protocol are operational on the World Wide Web. For this series of tests, these two protocols were able to transmit and receive information through routers, a firewall and a relaying server. 10. Comparison of the Speed of the Two Transfer Protocols The test consists in comparing the speed of the two transfer protocols: Authenticated Mail Transfer Protocol and Simple Mail Transfer Protocol. The server prototype measures the time that the server or the client interface needs to perform a transaction. The user employs the client prototype to send one, five, ten and twenty emails with two different sizes of data through ten different configurations. The small data size contains 472 bytes and the large data size contains 6085 bytes. The average total of email represents the average to send 35 emails (5 + 10 + 20). The first email sent initiates the route in order to establish a connection to the recipient server. Therefore, the result is not taken into consideration in the average total. The ten different configurations are: C1: The user sends an internal email. C2: The user sends an external email on the same network. C3: The user sends an external email using an email server as a relay between two email servers. C4: The user sends an external email using a firewall under Linux between two email servers. C5: The user sends an external email using a firewall under Windows between two email servers. C6: The user sends an external email using one router between two email servers. C7: The user sends an external email using two routers between two email servers. Crouzet Expires - April 2004 [Page 28] Authenticated Mail Transfer Protocol October 2003 C8: The user sends an external email using three routers between two email servers. C9: The user sends an external email using four routers between two email servers. C10: The user sends an external email using four routers and a relaying server: Simulation of a World Wide Web The following table displays the time in milliseconds and represents the average for sending 35 emails sent using a small or large data size for Authenticated Mail Transfer Protocol (AMTP) and Simple Mail Transfer Protocol (SMTP). The time takes into consideration the Client-to-Server and the Server-to-Server transaction times. The field Difference represents the difference between AMTP and SMTP (time with AMTP û time with SMTP). It compares the times in order to decide which one is the quickest to transfer an email. In brackets, we have the quickest protocol. /------------------------------------------------------------\ | Name | Small Size of Data | Large Size of data | | | AMTP | SMTP |Difference | AMTP | SMTP | Difference | -------------------------------------------------------------- | C1 | 225 | 172 |53 (SMTP)| 221 | 197 | 25 (SMTP)| | C2 | 1455 | 894 |561 (SMTP)| 1345 | 905 | 440 (SMTP)| | C3 | 3442 | 2912 |530 (SMTP)| 3193 | 2172 | 1022 (SMTP)| | C4 | 9762 | 5459 |4303 (SMTP)| 9834 | 6167 | 3667 (SMTP)| | C5 | 9925 | 5299 |4626 (SMTP)| 10019| 5159 | 4860 (SMTP)| | C6 | 1287 | 838 | 449 (SMTP)| 1305 | 1071 | 234 (SMTP)| | C7 | 1510 | 1721 |-211 (AMTP)| 4255 | 7029 | -2774(AMTP)| | C8 | 2090 | 2446 |-356 (AMTP)| 4769 | 7847 | -3077(AMTP)| | C9 | 2087 | 3447 |-1360(AMTP)| 2063 | 2753 | -690 (AMTP)| | C10 | 3446 | 5698 |-2252(AMTP)| 9848 | 8334 | 1513 (SMTP)| -------------------------------------------------------------- | Total | 35004| 28713|6290 (SMTP)| 46632| 41437| 5195 (SMTP)| \------------------------------------------------------------/ All tests have been realised with the same prototype using the same algorithm to send an email. As expected, Simple Mail Transfer Protocol is quicker than Authenticated Mail Transfer Protocol. Overall, the results show only a small difference between these two transfer protocols. Authenticated Mail Transfer Protocol takes 5.2 and 6.3 seconds more to send an email to a recipient than Simple Mail Transfer Protocol. AMTP is better in three cases: Configuration C7, C8 and C9 (routers tests). For a small data size, AMTP is better than SMTP for the configuration C10 (WWW). For other configurations, SMTP is better. During the test, a problem occurred for configuration C3 with AMTP: the server prototype produces some database errors; it tries to insert a row with the same primary key. Because of this, an error Crouzet Expires - April 2004 [Page 29] Authenticated Mail Transfer Protocol October 2003 occurs and the processing time increases. This problem was solved with a random number for the primary key but some errors still happen. The server prototype looses time finding a primary key for the EXTQUEUE table needed to verify the parameters of the SEMA command. It is possible to reduce the time for a Client-to-Server transaction for AMTP. In the server prototype, AMTP sends three times more information than SMTP, i.e. SMTP sends only one line while AMTP sends three lines for each reply. Therefore, the time taken to send these two lines increases the average time. Two tests were conducted with a reduction of the Client-to-Server transaction using the configuration C1 (internal mail) and C2 (external mail with a direct link to the recipient server). The server prototype sends only one line between each command. /------------------------------------------------------------\ | Name | Small Size of Data | Large Size of data | | | AMTP | SMTP |Difference | AMTP | SMTP | Difference | -------------------------------------------------------------- | C1 | 164 | 202 | -38 (AMTP)| 171 | 198 | -27 (AMTP)| | C2 | 610 | 807 | -198(AMTP)| 634 | 739 | -105 (AMTP)| -------------------------------------------------------------- | Total | 774 | 1009 | -235(AMTP)| 806 | 938 | -132 (AMTP)| \------------------------------------------------------------/ The result of this test shows that AMTP is quicker for each configuration. This simple test demonstrates that AMTP can be quicker than SMTP for all configurations if the Client-to-Server transaction is shorter. This transaction is shorter on protocol but longer on server prototype in order to explain the new transfer protocol to the user. In the future, the series of tests should send more emails and should be conducted on a real network with two email servers located on different places. The Client-to-Server procedure should be reduced on the server prototype. This series of tests should give a better demonstration of the efficiency of AMTP. 11. Attack against an Authenticated Mail Transfer Protocol server The two server commands, SELO and SEMA, can be used as an attack against the email server and allow a hacker to obtain a user email address. A hacked needs more resources in order to do so. He/she has to run an Authenticated Mail Transfer Protocol server on port 26. It is more difficult for him/her because only one programme per server can listen to port 26. A hacker cannot implement a programme on an existent Authenticated Mail Transfer Protocol server. Moreover, he/she cannot use a telnet connection to send an anonymous email or create a fake Authenticated Mail Transfer Protocol server on a Crouzet Expires - April 2004 [Page 30] Authenticated Mail Transfer Protocol October 2003 computer without port 26. If a hacker has his/her own server, his/her IP address is in the packets and identifiable by the administrator. A hacker can use the server command in the protocol in order to attack the server. If he/she wants to succeed, he/she has to know the message number and the recipient email address, which he/she cannot have both at the same time. If a hacker tries too many times, the server discovers the attack and closes the connection. A hacker does not affect a user, only the performance of the server. Two commands are available for him/her: SELO and SEMA. The SELO command is used to inform a recipient server that an email has to be retrieved. The SEMA command is used to retrieve an email. 11.1 Using the SELO command The hacker has to create an email inside the email server and a row in the email database. He/she informs the recipient server which server tries to retrieve the email and it will succeed only if the hacker has created the two conditions: email inside the server and a row in the database. Using the SELO command, the hacker can obtain a valid email address from the server. The SELO parameters for this test are: The name or IP address of the sender server is 193.1.124.54 The email number is 123456789 The recipient email address is: Valid Internal email address: bcrouzet@master.com Invalid Internal email address: anonymous@master.com External email address: anonymous@master.org The server returns an error because the email does not exist. The error SAAN3 specifies ôThe function semaAction cannot find the filename and the sender in the database: table extqueueö. Therefore, the sender server cannot deliver the email to the recipient server. On the server prototype, the email server displays the error SA10 that specifies that the reply code is different from 250. The server is informed that an email with the number 123456789 for anonymous@master.org is waiting on the server 193.1.124.54 to be retrieved. The recipient server will try to retrieve this email using the SEMA command. The server returns an error to specify that the user does not exist locally. The server will not try to use the Retrieved state. The problem remains that a hacker is able to find a valid recipient email address from the server and to trigger the Retrieved state. Whatever the situation, the hacker was not able to send an email. The only protection against his/her attack is to have a list of IP addresses that uses the SELO command. If the IP address is repeated many times and the server does not use the Retrieved state, then the Crouzet Expires - April 2004 [Page 31] Authenticated Mail Transfer Protocol October 2003 administrator has to ban the IP address or check the problem. Any email server does not allow people to establish a connection on port 23 (telnet 23). Therefore, it is difficult to insert data into an email server. 11.2 Using the SEMA command The hacker can use the SEMA command to retrieve an email that it is not for him/her. In order to do this, he/she needs to find the two parameters of the SEMA command that correspond to an email on the sender server. The SEMA command needs 2 parameters: The recipient email address is: bcrouzet@master.com Number: 123456789 The result of the SEMA command is identical for all email addresses. The server does not have the valid information in its database. The server returns an error because the email does not exist. The error SAAN3 specifies ôThe function semaAction cannot find the filename and the sender in the database: table extqueueö. Therefore, the sender server cannot deliver the email to the recipient server. The user bcrouzet@master.com did not receive an email and the hacker did not retrieve an email from a user mailbox. The test shows that the hacker was able to do nothing. If the number and the recipient email address are incorrect, the server returns an error. Again, a list of IP addresses will be helpful to protect the server against this type of attack. Any failed SEMA command has to be studied in order to understand the error. Whatever the situation, the hacker was not able to retrieve an email. 11.3 Overview of attacks against an Authenticated Mail Transfer Protocol server Authenticated Mail Transfer Protocol provides two server commands that are used during the Server-to-Server transaction. Hackers can used these two commands in order to hack the system. The different tests on Authenticated Mail Transfer Protocol show that a hacker can find a local email address on the email server but he/she cannot access the email server or retrieve an email. To find the number and the recipient email address is a very difficult task. These two parameters depend on the sender server and the user. It is possible to find the algorithm that produced the number but it will be difficult to find the recipient email address and the number, both at the same time. The recipient email address depends on the sender and the number depends on the number of messages sent. These numbers are stored in the server, where it is difficult to crack the database. In addition to this, it is important to maintain a list of IP addresses, which contains failed SELO or SEMA commands in order to determine the address of the attacker. Crouzet Expires - April 2004 [Page 32] Authenticated Mail Transfer Protocol October 2003 12. Conclusion In conclusion, this is one solution investigated to recognise a user by a server. The Authenticated Mail Transfer Protocol server identifies the user before he/she can use the email server. The drawback is that the transaction between two email servers takes more time than Simple Mail Transfer Protocol. This solution offers the guarantee that the sender exists and avoids spoofed and anonymous email, which is the aim of the exercise. It is a major step forward in the success of the thesis. The sender server identifies any sender and the recipient server is able to trust the information provided by the sender server. The recipient trusts the sender email address and he/she can find the sender without any difficulty. This solution does not stop spam email but it reduces the negative effect of this email problem. A user has the possibility of locating the sender and informing the sender server. Authenticated Mail Transfer Protocol modifies the structure of an email in order to find essential information in the email faster. It also improves the relaying function in order to use it. It adds new commands and improves the service offered during a transaction. The advantage of this solution is the difficulty for a hacker to find the number and the recipient email address from the SELO and SEMA commands. These two parameters depend on the sender server and the sender. The recipient email address depends on the sender and the number will depend on the number of email sent. These numbers are stored in the sender server, where it is difficult to crack the database. It is possible to find the algorithm that produced the number but it will be difficult to find the recipient email address and the number together. This document has demonstrated shown that Authenticated Mail Transfer Protocol is more secure and advanced than Simple Mail Transfer Protocol. The series of tests demonstrates that Authenticated Mail Transfer Protocol solved two email problems: anonymous and spoofed email and improved the relay between email servers. In the local network, Authenticated Mail Transfer Protocol works behind routers and gateways except proxy servers. Authenticated Mail Transfer Protocol is operational to work on a real World Wide Web. Authenticated Mail Transfer Protocol is slower than Simple Mail Transfer Protocol but it only takes 5-6 seconds more than Simple Mail Transfer Protocol in the overall result. A reduction of the Client-to-Server transaction on the prototype shows that Authenticated Mail Transfer Protocol outperforms Simple Mail Transfer Protocol. Different configurations help to show that Crouzet Expires - April 2004 [Page 33] Authenticated Mail Transfer Protocol October 2003 Authenticated Mail Transfer Protocol works as fast as Simple Mail Transfer Protocol. Hackers can attack Authenticated Mail Transfer Protocol with two server commands, SELO and SEMA, without damaging the email server. Authenticated Mail Transfer Protocol offers different advantages with three XML tags (RELAY, HEAD and BODY) in the structure of the email and two new commands (HEAD and MORE TO). In conclusion, Authenticated Mail Transfer Protocol outperforms Simple Mail Transfer Protocol and offers to users different advantages that will improve daily use. Security Considerations Security Considerations has been described during this document. References [1] Postel, J. (1982) Simple Mail Transfer Protocol. RFC 0281. ISI [2] Klensin, J. (2001) Simple Mail Transfer Protocol. RFC 2821. AT&T Laboratories. [3] Crocker, D. (1982) Standard for the format of ARPA Internet text messages. RFC 0822. University of Delaware. [4] Resnick, P. (2001) Internet Message Format. RFC 2822. QUALCOMM Incorporated. [5] Russell, R. (2000) Linux IPCHAINS-HOWTO [Online]. Available from: http://www.tldp.org/HOWTO/IPCHAINS-HOWTO.html [Accessed 04 September 2002]. [6] Lijun, Q. (2002) Internet sharing and firewall - SolidShare [Online]. Available from: http://www.solidshare.com [Accessed 04 September 2002]. [7] Zekoll, W. (2002) tcpproxy - Generic TCP/IP Proxy [Online]. Available from: http://www.quietsche- entchen.de/software/tcpproxy.html [Accessed 04 September 2002]. [8] Infopulse (2002) Proxy - Pro GateKeeper - Your Internet Sharing Solution - Proxy Server [online]. Available from: http://www.proxy- pro.com/index.html [Accessed 04 September 2002]. [9] Postel, J. (1981) Internet Protocol - DARPA Internet Program Protocol Specification. RFC 791. USC/Information Sciences Institute. Crouzet Expires - April 2004 [Page 34] Authenticated Mail Transfer Protocol October 2003 [10] Postel, J. (1981) Transmission Control Protocol - DARPA Internet Program Protocol Specification. RFC 793. USC/Information Sciences Institute. [11] RFC Editor. (2001) Definition of RFC [Online]. Available from: http://www.rfc-editor.org/overview.html [Accessed 10 December 2001]. [12] Freed, N. Borenstein, N. (1996) Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. RFC 2045. Innosoft. First Virtual. [13] Crocker, D., Overell, P. (1997), Augmented BNF for Syntax Specifications: ABNF. RFC 2234. Internet Mail Consortium. Demon Internet Ltd. Appendix Appendix A: Acronyms ASCII=> American Standard Code for Information Interchange (ASCII) is the most common format for text files in computers and on the Internet. In an ASCII file, each alphabetic, numeric, or special character is represented with a 7-bit binary number (a string of seven 0s or 1s). 128 possible characters are defined [13]. IP => Internet Protocol (IP) is designed for use in interconnected systems of packet-switched computer communication networks. The IP provides for transmitting blocks of data called datagramÆs from sources to destinations, where sources and destinations are hosts identified by fixed length addresses. The IP also provides for fragmentation and reassemble of long datagramÆs, if necessary, for transmission through "small packet" networks [9]. MIME => Multipurpose Internet Mail Extensions (MIME) is an extension of the original Internet email protocol that lets people use the protocol to exchange different kinds of data files on the Internet. The type of data can be audio, video, images, application programs, and other kinds, as well as the ASCII handled in the original protocol (SMTP) [12]. RFC => Request For Comment (RFC) forms a series of notes, started in 1969, about the Internet. The notes discuss many aspects of computer communication, focusing on networking protocols, procedures, programmes, and concepts but also including meeting notes, opinion, and sometimes humour [11]. SMTP => Simple Mail Transfer Protocol (SMTP) is to transfer any mail from a client to a server and is defining in RFC 0821 [1] and RFC 2821 [2]. The protocol used the port 25 to receive the data and the TCP/IP protocol to transport the data in the network. Crouzet Expires - April 2004 [Page 35] Authenticated Mail Transfer Protocol October 2003 TCP => Transmission Control Protocol (TCP) is intended for use as a highly reliable host-to-host protocol between hosts in packet- switched computer communication networks, and in interconnected systems of such networks [10]. Appendix B: Terminology => A mail, email, message or electronic mail represents a message sent across the network from one person to another. => Anonymous email is email that has been directed to a recipient through a third-party server that does not identify the originator of the message. => Client refers to the user software. => Command represents a specific order from a user to an application to perform a service. => Hacker is a person who tries to break into the computer system. => Mail Agent System represents a system to manage the mail (write, read, delete and send). => Authenticated Mail Transfer Protocol characterises the Simple Mail Transfer Protocol version 2. => Protocol or standard represents a set of rules for a subject. => Recipient represents the user who receives a mail and is in the server side. => SA represents a SMTP server where the sender is known. => SB represents a SMTP server where the recipient is located. => Sender represents the user who sends a mail and is in the client side. => Server represents the application running on the server side. => Spam is unsolicited email on the Internet. => Transaction is an exchange of information between 2 servers or a server and a user. => User is used to refer to a human user. Author's Addresses Brice Crouzet (PK4) Institute of Technology Tallaght Tallaght Dublin 24 Ireland Phone: + 353 (0) 14 04 23 45 Fax: + 353 (0) 14 04 20 00 E-mail: brice.crouzet@it-tallaght.ie Copyright Notice Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it Crouzet Expires - April 2004 [Page 36] Authenticated Mail Transfer Protocol October 2003 or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Crouzet Expires - April 2004 [Page 37]