[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

   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 <USERNAME> <PASSWORD>. 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.

   <USERNAME> <PASSWORD>
   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 <Recipient email
   address> 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: <Recipient email address>. 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: <recipient email address> [, <recipient email address>]
   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 <DOMAIN> <NUMBER> <RECIPIENT EMAIL ADDRESS>
   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 <RECIPIENT EMAIL ADDRESS >:<NUMBER>
   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:
   => <RELAY> contains the relaying server information </RELAY>.
   => <HEAD> contains the header information of the email </HEAD>.
   => <BODY> contains the body information of the email </BODY>.

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: <sender server information> TO <recipient server
   information>ö. 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: <number>ö.
   => 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>
   Relay from: < master.com (193.1.124.54); 06 June 2003 15:55:12
   o'clock IST; Version: 2.0> TO <master.org (200.200.200.100)>
   </RELAY>
   <HEAD>
   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
   </HEAD>
   <BODY>
   It is a demonstration of the new mail structure with three XML tags.
   </BODY>

   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 [<topic>]
   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: <recipient email addresses> [, <recipient email address>]
   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 <recipient email addresses> 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:
   <RELAY>
   </RELAY>
   <HEAD>
   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
   </HEAD>
   <BODY>
   It is a simple AMTP procedure.
   </BODY>

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:
   <RELAY>
   </RELAY>
   <HEAD>
   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
   </HEAD>
   <BODY>
   Subject: Test
   It is an AMTP procedure using optional commands.
   </BODY>

   The email for bcrouzet@master.com has been received:
   <RELAY>
   </RELAY>
   <HEAD>


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
   </HEAD>
   <BODY>
   Subject: Test
   It is an AMTP procedure using optional commands.
   </BODY>

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>
   Relay from: <master.com (193.1.124.54); 09 April 2003 09:02:13
   o'clock IST; Version: 2.0> TO <master.org (193.1.124.51)>
   </RELAY>
   <HEAD>
   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
   </HEAD>
   <BODY>
   It is an AMTP procedure using RSET command.
   </BODY>

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/