Internet DRAFT - draft-fakih-amdp

draft-fakih-amdp





   Internet Working Group                                   A. El Fakih 
   Internet Draft                                                       
   Document: draft-fakih-amdp-00.txt                                    
   Category: Standards Track                                            
   Expires: August 2003                                    January 2003 
    
    
                  Adaptive Mail Delivery Protocol (AMDP) 
    
 
Status of this Memo 
    
   This document is an Internet-Draft and is in full conformance with 
   all provisions of Section 10 of RFC2026 [i].  
    
   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 
    
   This document describes the Adaptive Mail Delivery Protocol (AMDP). 
   It aims to resolve the problems associated with current email systems 
   that rely on the mail delivery process defined by the Simple Mail 
   Transfer Protocol (SMTP).  This is done by extending and designing a 
   backwards-compatible replacement for SMTP, as well as restructuring 
   the mail delivery process.  The process is built around an adaptive 
   scheme that is able to addresses current and future demands for a 
   secure and reliable e-mail delivery systems. 
    
 







 
 
El Fakih                Expires - August 2003                [Page 1] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
Conventions used in this document 
    
   In examples, "C:" and "S:" indicate lines sent by the client and 
   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 [ii]. 
    
   The symbols -> and <- are used to indicate main flow of an email 
   message and its direction, where -> means email flows from the object 
   on the left to the one on the right, while <- is the flow in the 
   reverse direction.  <-> indicates that a continuous two way socket 
   connection is used to exchange information, while <=> indicates that 
   separate socket connections are required to complete the transaction.  
    
   In the document the following numerals are used to reference various 
   stages of the mail delivery: 
    
    Number  Stage ownership  Description 
    10      Sender           E-mail Client 
    15      Sender           Mail Authentication Service (MAS) 
    20      Sender           Outgoing Mail Service (OMG) 
    30      Sender           SMTP outgoing mail gateway 
    40                       DNS or MHF authentication Service 
    50      Sender           Mail Holding Facility Service (MHF) 
    60      Receiver         Mail Information Service (MIS) 
    65      Receiver         Subscription service 
    70      Receiver         Incoming Mail Gateway Service (IMG) 
    80      Receiver         Mail Storage Service 
    90      Receiver         E-mail Client 
    110     External         Mailing list management services 
    120     External         Mail abuse network 
    
    
Table of Contents 
    
   1. Introduction...................................................3 
   2. Current electronic mail delivery process.......................8 
      2.1 Problems with current system...............................9 
      2.2 Scenarios of email abuse..................................10 
   3. Proposed electronic mail delivery process.....................12 
      3.1 The Philosophy............................................12 
      3.2 AMDP design stages and implementations....................12 
   4. Outline of AMDP delivery process..............................14 
   5. Details of AMDP delivery process..............................15 
   6. Private and Public Mail Acceptance Policy.....................25 
   7. Delegating and authenticating Mail Holding Facilities.........29 
   8. Mail Classifications..........................................31 
 
 
EL FAKIH                Expires - August 2003                [Page 2] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
   9. Automatic reporting and resolution of classification abuse....34 
   10. AMDP envelope headers........................................34 
      10.1 AMDP-About...............................................35 
      10.2 AMDP-From, AMDP-From-Name................................35 
      10.3 AMDP-To, AMDP-To-Name....................................36 
      10.4 AMDP-SUBJECT.............................................36 
      10.5 AMDP-ATTACHMENTS.........................................37 
      10.6 AMDP-Mail-Class..........................................37 
      10.7 AMDP-Language............................................38 
      10.8 AMDP-Encoding............................................38 
      10.9 AMDP-Date................................................38 
      10.10 AMDP-OMG-ID.............................................39 
      10.11 AMDP-MSG-Id.............................................39 
      10.12 AMDP-Size...............................................39 
      10.13 AMDP-MHF-Name, AMDP-MHF-Id..............................39 
      10.14 AMDP-Auth-Port..........................................40 
      10.15 AMDP-Timestamp..........................................40 
      10.16 AMDP-Expire-On..........................................40 
      10.17 AMDP-Auth-Keys..........................................40 
      10.18 AMDP-VERSION............................................40 
      10.19 AMDP-PAYMENT-RCPT.......................................40 
   Security Considerations..........................................40 
   References.......................................................40 
   Acknowledgments..................................................41 
   Author's Addresses...............................................41 
   IPR Notices......................................................41 
   Copyright Notice.................................................42 
    
    
    
1.   Introduction 
    
   The Adaptive Mail Delivery Protocol (AMDP) is an ambitious project 
   that aims to solve the problems associated with the current mail 
   delivery system.  This is done by extending and designing a 
   backwards-compatible replacement for the Simple Mail Transfer 
   Protocol (SMTP), as well as restructuring the mail delivery process.  
   AMDP is built around an adaptive scheme that is able to addresses 
   current and future demands for a secure, and reliable e-mail delivery 
   systems. 
    
   Current SMTP based mail systems, suffer from many serious and costly 
   to fix issues.  These issues include impersonating others, lack of 
   privacy, virus spread, spamming, among others.  This is made possible 
   due to the inherent design of SMTP, which was never designed to be 
   used the way we use it today.  AMDP is designed to address and solve 
   these issues, while allowing in its design the flexibility and 
   adaptability required to grow with the needs of the Internet.   
    
 
 
EL FAKIH                Expires - August 2003                [Page 3] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
   Current technical solutions designed to curb the continuous abuse of 
   electronic mail systems, are ineffective in the long run due to the 
   inherent design of SMTP and the mail delivery process in general. 
    
   The continual rise of electronic mail abuse is bound to have a 
   negative effect on the growth and progress of businesses utilizing 
   electronic mail as a business tool.  Therefore it is imperative that 
   we address and solve the issues plaguing the mail delivery process, 
   allowing us to have a better tool for conducting business, promoting 
   education and entertainment within a safe environment.  AMDP aims to 
   achieve the following: 
    
   Prevent and Control Abuse 
    
      Most of the Internet abuse taking place is due to the early 
      designs of network protocol with relied heavily on implicit trust 
      between networked systems.  However with the proliferation of the 
      Internet and its wide use on a global scale, this trust has been 
      abused by individuals for profit and fun, which made controlling 
      the various types of abuse difficult and costly. Most of the 
      solutions geared to deal with the growing number of abuse tend to 
      band-aid the problem by filtering received email massages after it 
      is received by the incoming mail server.  The messages are 
      filtered using sophisticated programs to control SPAM, Viruses, 
      among others. However none has tried to solve the problem from its 
      roots, and AMDP has been designed from the ground up to deal with 
      these issues. 
       
      In AMDP only an envelope is accepted, and only after a routine 
      authentication takes place that does not require any encryption, 
      the message and/or envelope can be accepted for delivery. 
    
   Control and allow Unsolicited Mail 
    
      Everyone using the internet has dealt with unsolicited mail in one 
      form or another.  Unsolicited mail, also referred to as SPAM, had 
      gone from being an annoyance to become a major cost for doing 
      business on the net.   
    
      After technical solutions have failed to control the wide abuse of 
      email systems, legislations in the US and Europe have tried to 
      control it, but to no avail.  Tracking spammers is impossible in 
      most cases and expensive both from a technical and logistical 
      points-of-view. It is sad to see that companies have been set up 
      to explicitly abuse these email vulnerabilities, claiming to abide 
      by the law while they themselves indulge in the profitable 
      business of spamming users on the expense of others.    
    

 
 
EL FAKIH                Expires - August 2003                [Page 4] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
      For the reader that wonders how it is possible, the answer is 
      straightforward.  Any number of unsolicited messages can be sent 
      from any unprotected host to any user whether they want it or not.  
      The message can claim itself to be from any person or any 
      organization whatsoever.  System administrators do not have the 
      tools to stop the abuse, and are unable to keep up with the 
      various permutations used to bypass mail filters through protected 
      systems.  The process of protecting email systems from this kind 
      of abuse is estimated to cost companies millions of dollars in 
      damages every year.   
       
      Although many have negative feelings associated with the practice 
      of mass unsolicited mail, many users benefit from these services 
      if they are not abused. There are many legitimate uses of mass 
      mailing and should be allowed to exist within a controlled 
      environment that is marketing friendly, without trampling all over 
      the rights of the recipient for privacy, or for the business rules 
      of the network provider, and the companies owning the network 
      infrastructure.  
       
      AMDP is designed to be friendly to businesses dealing with mass 
      mailing, while providing within the process various control 
      mechanisms for the end recipient and the domain name 
      administrators as to what kind of mail they want to receive, and 
      in what frequency. 
    
   Control the spread of Viruses 
    
      One of the side effects of the unauthenticated mail transports is 
      the ease in which viruses are spread all over the Internet.  
      During a virus attack (Virus storms) millions of users receive 
      viruses from people who may or may not know, who had their 
      computer systems compromised. Other attacks end up sending the 
      user's private files.  Viruses tend to spread from one user to 
      another without any means of control.  And even after an attack 
      has been identified, it is very difficult for mail administrators 
      to control the flow of these viruses. 
    
      This can be controlled, and even prevented if the identity of the 
      sender is truly known to the user, and there are tools the service 
      provider can use to prevent its mail system to be hijacked by the 
      virus.  
    
       
   Authenticate sender and receiver 
    
      SMTP does not have any means to authenticate the address of the 
      sender, nor does it authenticate the claims made by a server that 
      is sending mail on behalf a domain name.  The authentication is 
 
 
EL FAKIH                Expires - August 2003                [Page 5] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
      assumed to be done on one side of the mail delivery scheme, and 
      the receiving side has to trust the sender's address in the mail 
      envelope.   This is a very poor design that is the heart of many 
      of the abuse cases related to email. Basically SMTP allows anyone 
      to claim to be anyone they choose to.   
    
      AMDP addresses these points in a way that is both easy to 
      implement, manage, and it is very costly/difficult for spammers to 
      overcome.  
    
   Integrate Encryption for better Security 
    
      Current systems rely on third party software to encrypt messages 
      on the client side.  Encryption usage is very limited due to the 
      perceived complexity of setting up mail applications, or not 
      understanding how encryption works and how to encrypt and decrypt 
      their messages. AMDP allows for automatic negotiation for general 
      encryption between mail servers, making it difficult for persons 
      who capture the mail message to read the content without having to 
      decrypt it. 
    
   Multilingual support  
    
      AMDP supports language negotiation, where the language of the 
      message is identified for possible automatic translation. It also 
      aims to use Unicode as its method of communication leveling the 
      ground for the various encoding existing today.  
    
   Native language domain name support 
    
      AMDP will support non-Latin based domain names. 
    
    
   Subject classification support 
    
      AMDP supports the classification of email messages.  The messages 
      can be tagged as business, adult, personal, marketing, etc..  The 
      unified classification will give parents/service providers some 
      control over adult mail being delivered to minorsĂ mail boxes.  
      Although this system may seem to require implicit trust, 
      intelligent parsers, in combination to the business of 
      classification certificates will be used for this purpose.   
    
    
   Separate business and information technology mail delivery rules 
    
      SMTP mail systems do not allow businesses to decide independently 
      from the Information Technology (IT) department what mail should 
      enter its systems, at what hours, volume, or set the priority for 
 
 
EL FAKIH                Expires - August 2003                [Page 6] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
      inbound and outbound processing.  AMDP is designed to take these 
      into consideration and allows the business to make its own rule 
      separately from IT to decide what goes in, what goes out, and 
      when. While IT has its own rules such as what types of mail is 
      allowed, quota's etc..   
       
      AMDP also introduces the concept of public and private mail 
      delivery rules. Where the public rules are available for mail 
      servers to parse before attempting delivery, minimizing the amount 
      of wasted bandwidth due to the guaranteed rejection of any mail 
      message meeting the criteria.  
    
   Streamlined law enforcement and dispute resolution 
    
      Authenticated systems, can give law enforcement a better tool to 
      track effectively messages to its source.   While classifications 
      and automatic error reporting can lead to better control of abuse 
      and talking legal actions (if necessary) against systems that do 
      continue to abuse the mail system. However the intention of the 
      design is to make it unprofitable to abuse mail systems. 
    
   Better support for white and black lists 
    
      Current methods rely on black or white lists to ban or allow mail 
      servers to deliver mail.  These lists are not easy to use, 
      maintain, register or remove a host from it.  They are prone to 
      block people who are not involved in Spam, or allow others who do.  
      Hence AMDP will have a standard way to report these abuses and 
      include specific information required to authenticate an abuse has 
      occurred, and the severity of the abuse. 
    
   Guaranteed mail delivery with return receipt 
    
      AMDP design allows the email system to be used as a method to 
      guarantee delivery of electronic deliverables.  Users purchasing 
      software, images, music, or any other media that can be digitized 
      can receive the actual deliverable into their mailbox.  It stays 
      at the sellerĂs servers, until it is requested by the user, which 
      in turn executes or finalizes the sales transaction by verifying 
      that the deliverable was received. 
    
      Current solutions using similar approach do not guarantee receipt 
      of a message. 
       
   Electronic postage support 
    
      AMDP design incorporates the option to accept payment for 
      electronic mail received. The payment can be perceived as 
      electronic postage, and it is set by the domain name 
 
 
EL FAKIH                Expires - August 2003                [Page 7] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
      administrators.  Mail messages meeting the requirements, and pay 
      the postage are accepted for delivery. 
       
      This option is also used as a natural method to control the growth 
      of unsolicited electronic mail, since these messages will have to 
      pay for access, which makes it unprofitable for companies to mass 
      mail non interested users. 
 
    
2.   Current electronic mail delivery process 
    
   Mail delivery over electronic networks, such as the Internet, relies 
   heavily on an early design defined in the Simple Mail Transfer 
   Protocol (SMTP) specifications RFC 821 iii.   The SMTP specifications 
   outlined a simple approach to transmit a message from a host computer 
   to a recipient mail server. Figure 1 illustrates the path of a valid 
   email message starting from the initiating user [10] to its final 
   destination [90].  
    
                  [10] ->  [30] ->  [70] ->  [80] <-> [90]  
    
                   Figure 1.  SMTP mail delivery process 
    
   Note: The numerals used in Figure 1 are explained in the 'Conventions 
   section' of this document. 
    
   To understand the current mail delivery process we should trace the 
   journey of an email message to its destination. 
    
      1. A mail message starts its journey from a personal computer 
      [10], where the user types in his/her message into an e-mail 
      client such as Outlook on Windows platform, or Pine on the Unix 
      platform,.  The e-mail client will then assemble together the text 
      of the e-mail and the information required for delivery such as 
      sender and receiver emails, date, etc. into a standard format that 
      can be read by SMTP based mail servers, and forward the email to 
      the assigned outbound SMTP server [30]. 
    
    
      2. The message is received, the message header is read, the 
      recipient e-mail is extracted from it, a domain name lookup is 
      done using the DNS protocol [40] to determine the address of the 
      server assigned as a the mail gateway for the domain in questions, 
      and then the message is forwarded to this server [70] using the 
      SMTP protocol.   
    
      Note: The address of the mail server designated as mail gateway 
      [70] is publicly available through the DNS protocol under the MX 
      record for any given domain name. 
 
 
EL FAKIH                Expires - August 2003                [Page 8] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
    
      3. The receiving mail server [70] checks if the user exists, cross 
      references the email with known black lists, or matches it against 
      internal rules, then it accepts the message, and responds to the 
      sender server [30] that it has been accepted. Optionally the 
      receiving server would check for viruses, available space, or uses 
      other filtering techniques to determine if the message is 
      unsolicited, or blacklisted.  If it fails any of these tests it 
      will reply with an email message with the error to the senderĂs 
      email defined in the header of the message itself. However if the 
      message passes the test it is forwarded to a local or remote 
      delivery agent.  
    
      4. The delivery agent will then save the message into the mailbox 
      of the recipient [80] where it will reside until it is retrieved 
      by the recipient using IMAP, POP or other methods using an email 
      client [90].  
    
      5. Once the recipient opens his e-mail client [90], all new mail 
      is retrieved from the mail server [80], and displayed as a list 
      showing the subject, recipients, and dates of each message.  The 
      user can then proceed to read, delete, or respond to any message 
      his/her mailbox. 
    
    
2.1    Problems with current system 
    
   The current process, described in the previous section, relies 
   heavily on the content of the e-mail message to decide how to route 
   the message.  It does not verify the accuracy of any of the 
   information contained within the message.  Like many of the early 
   protocol designs of the Internet, these systems were designed with an 
   implied trust built into them.  This trust is exploited for fun, 
   profit, or as an act of aggression.  
    
   Some of the problems plaguing the current mail delivery process 
   include: 
    
      1. The inability to truly authenticate the identity of sender or 
      server relaying the mail message.  These two important factors are 
      the building block for the practice of unsolicited mail.   
    
      2. The inability to adequately control the spread of unsolicited 
      or virus-packed mail at either side of the mail delivery process. 
    
      3. The inability to isolate, combat and defend from denial of 
      service (DoS) attacks that rely on open relay gateways, and forged 
      return addresses. 
    
 
 
EL FAKIH                Expires - August 2003                [Page 9] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
      4. The inability to reliably track the delivery or non-delivery 
      status of a given message. 
    
      5. The inability to control the type, size, or language used in 
      outgoing mail by system administrators. 
    
      6. The inability of domain name owners to prevent others from 
      utilizing their domain in attacks, or unacceptable business 
      practices. 
    
      7. Absence of encryption in the design of SMTP allows anyone to 
      freely intercept and read other peopleĂs mail, making it a poor 
      instrument to exchange sensitive information without accepting the 
      risks associated with such system. 
    
    
2.2    Scenarios of email abuse 
    
   Listed herein are few scenarios of electronic mail abuse due to the 
   loose design of the SMTP mail delivery process. 
    
   Forged Mail:  
    
      A user connects to an SMTP server (This could be done manually by 
      connecting using telnet to port 25, or via an available program 
      designed for that purpose).  The user will then provide the SMTP 
      server with a forged sender address (FROM), a valid recipient 
      (RCPT TO), and the text of the message to send (DATA).  The 
      recipientĂs SMTP server accepts the message, since it has no tools 
      to authenticate the information provided related to the sender. 
      The recipient becomes a victim of a forged message, which is the 
      building block of all mail based attacks. 
       
   Place blame on someone else:  
    
      This is a variation of the "forged mail÷ case, however in this one 
      the user sends offensive messages, adult material, viruses, or 
      tries to sell something.  The sender provides a valid return 
      address which does not belong to him, and that is not on any known 
      black lists.  The owners of the domain or email account are 
      subsequently blamed for the unsolicited mail, placed on black 
      mailing lists, and have to deal with angry messages, and 
      communicate with the various black list organizations to attempt 
      and remove their domain from the lists, while they are in fact 
      victims of the attack as well. 
    
    
    
    
 
 
EL FAKIH                Expires - August 2003               [Page 10] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
   Denial of Service Attacks: 
    
      In this case, the attacker is interested in inflicting damage to 
      one or more parties.  The attacker starts by selecting their 
      victimsĂ email addresses, which would be used as return address.  
      The attacker proceeds to send mail to million of servers all over 
      the net targeting existing and non-existing email accounts.  Error 
      messages, requests for removal, and replies would be directed to 
      the victimsĂ accounts.  The ISP servicing the accounts and their 
      users will have to abandon the accounts, unless they have the time 
      and money to defend against the variations of the message, and 
      servers responding to the message etc.   
       
      Another type of attack is to send large attachments to victim 
      accounts which would fill the mailbox of the recipient, and 
      cripple the ISP if they are not equipped to deal spam, or the mail 
      volume generated by this kind of direct attack. 
       
      While other attacks rely on relay mail servers which are used to 
      attack one or more targets by using thousands of hosts to email 
      the same target at the same time, and for extend period of time 
      bringing the mail server to a complete stop. 
       
    
   Remove email from lists: 
    
      There are many schemes out there designed to obtain email 
      addresses against their ownerĂs permission for the purpose of 
      Spam.  These schemes include mass mailing and asking people to 
      unsubscribe. Unknown to the victim, by attempting to unsubscribe, 
      they validate the email account for further Spam. Other schemes 
      include harvesting web pages for email addresses, emailing them, 
      and checking for error messages. Email addresses that do not 
      generate errors are kept for future Spam campaigns.  SMTP itself 
      has a design flaw that helps in the chaos.  SMTP has a command 
      called (VRFY) it was designed to verify the existence of username 
      on the email system contacted, which was abused and used as a tool 
      to verify emails for Spam.  Today many SMTP servers block this 
      feature. 
 
    
    
    
    
    
    
    
    
    
 
 
EL FAKIH                Expires - August 2003               [Page 11] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
3.   Proposed electronic mail delivery process 
    
    
3.1    The Philosophy 
    
   The proposed mail delivery scheme revolves around the concept of 
   shifting the bulk of responsibility of storing and delivering the 
   message away from the receiver and onto the sender contrary to the 
   way it is currently implemented.   
    
   The current email delivery scheme places the burden of processing, 
   storing, and delivering mail messages on to the recipient side.  The 
   process is prone to abuse, allowing any user equipped with a list of 
   emails and open relay servers to send millions of unsolicited 
   messages creating havoc at the recipient side. This is due to absence 
   of mutual responsibility in the mail delivery cycle.  In most cases 
   mass mailing contain jokes, viruses, chain letters, or marketing 
   material which require a minimum investment from the senderĂs side, 
   while the recipient must make a larger investment in time and money 
   to process and store unsolicited mail. 
    
   The target of AMDP is it to make the sender responsible for his 
   actions. As in our everyday life, the sender will store the message 
   on his own server, notify the recipient of the existence of a message 
   on the server, and serve the email message when requested.   
    
   This is similar to what happens when you ship something via a 
   commercial carrier be it the local post office, UPS, DHL, or other 
   courier services.  The sender is responsible for the delivery of the 
   message whether it is done directly, or via an agent.  His 
   responsibility ends when the person receives or rejects the message.   
    
   Historically, we have used mail schemes that placed the burden of 
   delivering the message on the sender, and we know it works, and with 
   AMDP we borrowed these tested concepts to design an online system 
   that is adaptive and can operate safely within the Internet today and 
   in the future.   
    
    
    
    
    
3.2    AMDP design stages and implementations 
    
   This design document outlines the steps that have to be accomplished 
   while transitioning existing software that interacts with the mail 
   delivery scheme from its current state to a system that supports all 
   features of AMDP explicitly. 
    
 
 
EL FAKIH                Expires - August 2003               [Page 12] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
   The design document will refer to the transitional and final stages 
   where: 
     
   The transitional stage: 
    
      In this stage, SMTP, DNS and AMDP systems coexist as they are. 
      Without this stage, the system is of no use to anyone.  The system 
      will have to use SMTP readable email envelopes to allow old 
      systems to send, and receive messages to, and from AMDP servers.  
      The system will have to rely on current DNS structure for its MHF 
      authentication, and use available technologies such as secure 
      shell to encrypt communications between venerable points. It will 
      also use HTTP to retrieve messages where applicable. 
       
      Typically an envelope will contains both the SMTP and AMDP header 
      in all of it communications, however this can be dynamically 
      determined when an MHF [50] connects to a mail gateway [70] and 
      decides if it supports AMDP or SMTP based on the HELO command, 
      which could be changed to receive a variation of the command to 
      identify AMDP servers. 
    
   The final stage: 
    
      In this stage, SMTP, DNS, POP and AMDP systems coexist but changes 
      to their architecture has been completed, and refined.  Other 
      parts of the scheme that need to be in place include 
      authentication mechanisms of AMDP, mail classification, reporting 
      of abuse, postage micro payments, etc..  A modified version of POP 
      may be needed to deliver messages to their ultimate destination, 
      unless HTTP or other specially designed protocol is used for that 
      purpose.  
    
   This paves the way for a design that can be enforced technically and 
   legally.  Users continuing to use SMTP can coexist with AMDP, however 
   they will be treated as bulk mail sources, and would be isolated in 
   the long run.  An analogy of SMTP and AMDP would be Archie or Gopher 
   protocols versus http, where they took a back seat as http gained 
   support because it delivered convenience and results compared to its 
   predecessors. 
    
   The simplest way to explain how AMDP works is to follow an e-mail 
   message from sender to recipient, and see how the message is treated 
   on its way to the final destination (See Figure 2). The following 
   sections will outline the AMDP mail delivery process as to give the 
   reader an overview of the process, followed by a revisit to the 
   process with an in-depth approach explaining what occurs at each 
   stage both in the transitional and the final stages of the design. 
    
                                      
 
 
EL FAKIH                Expires - August 2003               [Page 13] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
    
4.   Outline of AMDP delivery process 
    
   AMDP relies on the same client-server communication process used in 
   SMTP. i.e. it will use the basic MAIL FROM, RCPT TO, and DATA to 
   transfer data from one server to another.  However the major change 
   is in the mail envelope itself. 
    
   This section outlines the path traversed by a valid email message 
   traveling from [10] to [90] shown in Figure 2. The details of what 
   happens at each step are discussed in section 5                                                 .. 
    
    
                     [15]     [60] 
                       |        | 
            [10] ->  [20] ->  [50] <=> [70] ->  [80] <ű> [90] 
       
                              [50] <-> [90] (optional) 
    
                   Figure 2. AMDP mail delivery process 
    
    
      1. A user composes a message and sends the message from an e-mail 
      client [10]. 
    
      2. The message is then received by the email gateway [20] (OMG) 
      where it will undergo various business tests, header information 
      is added to the email envelope, and it is forwarded to the Mail 
      Handling Facility (MHF) [50]. 
       
      The mail holding facility (MHF) is the location where outgoing 
      mail is held until it is delivered to the recipient [90].  MHF 
      also keeps track of delivery status of any email message, making 
      it possible to execute e-commerce transactions using the MHF to 
      guarantee delivery. 
       
      3. The mail holding facility (MHF) [50] contacts the mail 
      information server (MIS) [60] and analyzes the public mail policy 
      available online.  If the public policy does not deny mail from 
      50, then it will create a standard envelope using AMDP defined 
      headers, and send it to the appropriate mail server for further 
      processing [70]. 
       
      4. The recipient server [70], also referred to as Incoming mail 
      gateway (IMG), will read the incoming envelope, authenticate the 
      MHF, and if the envelope meets their business requirements, it is 
      forwarded to the user mailbox [80]. 
       

 
 
EL FAKIH                Expires - August 2003               [Page 14] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
       
      5. The messages or envelopes are stored in the server [80] until 
      they are accessed by the final recipient. 
       
      6. The recipient [90] will use an email client to retrieve the 
      available envelopes in his/her mailbox.  Once the user decides to 
      read the message, it is retrieved from [80] if it was accepted by 
      [70] in its entirety, or it has to be retrieved from the MHF [50] 
      using any of the available transports such as HTTP, IMAP, POP or 
      any other protocol designed for this purpose.   
      If the MHF is not online, the client can be programmed to poll the 
      MHF at various intervals until a connection is made, or request 
      from IMG [70] to poll the data from the MHF [50] and deliver the 
      message to the mail storage [80].  
    
    
5.   Details of AMDP delivery process 
    
   AMDP relies on the same client-server communication process used in 
   SMTP. i.e. it will use the basic MAIL FROM, RCPT TO, and DATA to 
   transfer data from one server to another.  However the major change 
   is in the mail envelope itself. 
    
   In this section we will explain in detail the delivery process, and 
   some of the possible variations.  The specification may include 
   separate sections for the transitional and final implementation 
   phases. 
    
      1. A user composes a message and sends the message from an e-mail 
        client [10].  
         
        During the transitional stage, no changes are required to email 
        clients.  All outgoing email should work the same.   
         
        However in the final stage, the email client would provide key 
        information required by MHF [50], such as the mail 
        classification, language and encoding of message. The program 
        should also have better error reporting interface to understand 
        why an outgoing message failed. It will also have better 
        mechanisms in resolving cryptic error message generated by SMTP 
        that most users do not understand, especially when we talk 
        about non-English speaking users, and instruct them on what 
        steps to take to remedy the situation.  The language setting of 
        the mail client will enable the mail gateway [20] to deliver 
        the correct error message. Email clients must be able to read 
        AMDP generated envelopes and retrieve the message 
        automatically, instead of using a separate web browser, it will 
        also allow for MHF polling, etc.. 
         
 
 
EL FAKIH                Expires - August 2003               [Page 15] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
      2. The message is then received by the outgoing mail gateway (OMG) 
        [20] where it will undergo various business tests.   
         
        The server [20] MUST  
         
           Use a trusted connection between [10] and [20].  This can be 
           achieved by enforcing the use of assigned internal IPĂs, 
           firewall, encryption, etc.  It is also recommended that the 
           connection does not use a clear text mechanism when possible.   
            
           Use a username and password to authenticate the user when 
           accepting outgoing mail, by checking the Mail authentication 
           server MAS [15]. 
            
           Replace the AMDP-FROM: field of the AMDP envelope with the 
           proper email address of the user.  This prevents common 
           mistakes made by new users of the Internet, as well as 
           deliberate forgery of senderĂs information. 
            
           Add other header information required by MHF such as 
           language, classification, etc. 
            
            
        Optionally server [20] can:  
         
           Check for bad language, scan for viruses, enforce outbound 
           file size limits, as well as computer quota restrictions for 
           outgoing mail. The server can also block users from sending 
           messages for non-payment, parental control setting, or due to 
           previous history of email abuse. 
            
         
        If the message is refused for outbound delivery for any reason, 
        the user will be informed (preferably via a direct method, to 
        eliminate any chance of flooding a userĂs mail account with 
        error reports as it happens in SMTP) with the reasons for 
        denying the message, and the actions which need to be taken by 
        the sender to remedy the situation.  
         
        However if the message satisfies the business rules, other 
        header information are added to the original mail message 
        envelope, and the message is forwarded to the Mail Holding 
        Facility for delivery [50].  
         
      3. The mail holding facility (MHF) 50 is responsible for holding 
        all outgoing mail for delivery.  The MHF plays an important 
        role in the mail delivery cycle which includes:  
         

 
 
EL FAKIH                Expires - August 2003               [Page 16] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
           a. Checking public mail policies prior to attempting 
             delivery. 
              
           b. Composing standard AMDP envelopes.  
              
           c. Sending notification of mail to recipients.  
              
           d. Holding the mail until it is picked up by the final 
             recipient.  
              
           e. Forwarding the message to other severs that would accept 
             messages instead of envelopes.  
              
           f. Keeping track of the delivery status of all email 
             messages.  
              
           g. Providing a mechanism to report the delivery status, 
             making it possible to conduct e-commerce transactions, by 
             guaranteeing mail delivery status.   
              
         The mail holding facility has three or more possible 
         configurations depending on the size of the email outgoing from 
         its network. 
          
         Small size companies: 
           
            In this context, a small company generates a small number of 
            outgoing messages. The administrator can use the same server 
            that is currently used for processing outgoing mail [20], to 
            act as the Mail Holding Facility [50], by dedicating some 
            extra resources for the task. 
             
         Medium size companies: 
           
            In this context, a considerable amount of storage is needed 
            for the outgoing mail.  The administrator can opt to have a 
            dedicated server with a larger amount of storage for the MHF 
            [50] task.  
          
         Large size companies:  
           
            In this context, millions of messages are sent out for 
            delivery (ISPs and mail service providers).  The business 
            would decide between having the outgoing mail handled 
            internally using its own dedicated servers, or opt to 
            outsource the task to specialized companies authorizing them 
            to act as mail agents to deliver the mail. 
             
         Third party processing 
 
 
EL FAKIH                Expires - August 2003               [Page 17] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
             
            In this context, a company specializes in processing mail 
            for any party wishing to use an external service.  This 
            would act as a post office.  In this configuration the third 
            party becomes the authorized MHF for the domain name, and it 
            can process all outgoing mail. 
           
          The MHF receives its messages from authorized outgoing mail 
          servers (OMG) inside its network.  The communication between 
          servers [20] and [50] should be encrypted to protect it from 
          receiving any forged information. However other methods of 
          authentication can be used, as long as they explicitly have to 
          accept connections from OMG, and deny all by default.  
           
          The MHF will then store and lock the message on the server, 
          and issue a unique identifier (AMDP-MSG-ID) for the message.   
           
          If the message is intended for multiple users, the MHF will 
          associate a different id for each one of the recipients.   
           
          The MHF will then communicate with the Mail Information Server 
          (MIS) 60 to review the public mail policy.  It can optionally 
          access that information from its internal cache if the MIS 
          information has not expired as specified by the MIS in 
          previous queries made to the same domain.  
           
          If postage is required, then payment is made and the receipt 
          number is attached to the header information of the envelope 
          under AMDP-PAYMENT-RCPT. 
           
          If everything is acceptable, the MHF will then build a 
          standard AMDP envelope that will be sent to the recipientĂs 
          incoming mail server [70], i.e. the server identified in the 
          DNS MX record of the domain.  
           
          The MHF server 50 MUST:  
           
          Compose a valid AMDP delivery slip, which is referred to as an 
          envelope.  The envelope can be read by either SMTP or AMDP 
          servers.   
           
          The envelope will include at least the following information: 
           
               All required SMTP headers. 
                
               The sender's name and email address:   
               Syntax: AMDP-FROM-NAME, AMDP-FROM  
               The information is generated from the message received 
               from the email gateway [20].  
 
 
EL FAKIH                Expires - August 2003               [Page 18] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
                 
               The recipient's name and email address 
               Syntax: AMDP-TO-NAME, AMDP-TO  
               This information is generated from the original email 
               message [10], or outgoing mail gateway [20].  
                
               The subject of the letter 
               Syntax: SUBJECT  
               The information is generated from the original email 
               message.  
                
               Mail classification of the letter content 
               Syntax: AMDP-MAIL-CLASS  
               Refer to the Mail classification section for the proposed 
               structure.   
                
               List of attachments 
               Syntax: AMDP-ATTACHMENTS  
               It will include the standard list, size, units used in 
               the size field, name, and type of attachments.  This is 
               required by the recipient servers to know what to expect, 
               such as required space resources.  This list will be 
               matched by the receiving server/client to prevent the 
               message from being altered in transit, or from erroneous 
               reporting of message size.  
                
               Language of the message  
               Syntax: AMDP-LANGUAGE  
               The language flag is set to the ISO 639 code of the 
               content language. It is increasingly important to define 
               the language of a mail message. This flag will help the 
               end user, or other pre-processing tools, to decide how to 
               process the message. i.e. Will translation be required? 
               Does the current platform support display of this 
               language? etc.  The language flag should be set by the 
               sender [10], or mail gateway [20].  It can be overwritten 
               by the mail holding facility [50].  
                
               Encoding of the message 
               Syntax: AMDP-ENCODING  
               The encoding of the message is important and need to be 
               set as per RFC 2277 [iv]. Ideally the MHF should convert 
               all messages it receives into a UTF8 during the 
               transitional stage, and Unicode during the final stage. 
                
               Mail Holding Facility Name and ID 
               Syntax: AMDP-MHF-NAME, AMDP-MHF-ID 
               These identification strings identify the MHF to 
               receiving servers [70].  The AMDP-MHF-NAME is the domain 
 
 
EL FAKIH                Expires - August 2003               [Page 19] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
               name of the MHF, while the AMDP-MHF-ID is a unique 
               identifier for the MHF.  There are two configurations for 
               the AMDP-MHF-NAME and AMDP-MFH-ID 
                
                 
                
               Message unique identification 
               Syntax: AMDP-MSG-ID  
               This is a unique id issued by the MHF [50] holding the 
               message.  The number will become one of the keys used to 
               retrieve the message by the intended recipient.  In the 
               event a sender sends one message and copies five people.  
               Each recipient will receive an envelope with a different 
               MSG-ID.  This id is an important tool is reducing Spam 
               and the manner it is created should by chosen carefully 
               as not to be predictable.  
                
                 
               Expiration date 
               Syntax: AMDP-Expire-On 
               This is expiration date of a message.  The MHF [50] tells 
               the recipient how long the message will be kept in 
               storage before it is removed. This is applicable to 
               marketing materials that have a deadline, or newsletters 
               etc..  These deadlines help the MHF to keep its data up-
               to-date, and to enable automatic removal of un-retrieved 
               message.   
                
               Marketing campaigns, job opening, transaction, among 
               other have deadlines, therefore all will benefit from a 
               deadline after which their message is purged from the 
               delivery cycle.  The AMDP-Expire-On could be used as a 
               key to authenticate a message between servers [50] and 
               [70].  
                
               Timestamp 
               Syntax: AMDP-TIMESTAMP 
               This is simply the timestamp in UTC of when the envelope 
               was created.  This time stamp MUST be between the 
               message's original time, and the delivery time.  This key 
               is used in the authentication process between [50]-[70] 
               MHF-IMG, and [50]-[90] MHF-Final recipient.  
                
               Message Size 
               Syntax: AMDP-Size 
               This is the total size of the message, which includes the 
               attachments as well.  The AMDP-SIZE also specifies the 
               unit of measure in the string. 
                
 
 
EL FAKIH                Expires - August 2003               [Page 20] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
               MHF Authentication Port 
               Syntax: AMDP-Auth-Port 
               The MHF has to answer authentication queries from the 
               recipients' incoming mail gateways [70], and hence it can 
               specify the port on which it answers these queries. 
                
               Authentication keys 
               Syntax: AMDP-AUTH-KEYS 
               This is the list of authentication keys that need to be 
               used by the IMG [70] when contacting the MHF [50].  If 
               not specified then the key are assumed to be AMDP-
               TEMPSTAMP, AMDP-EXPIRE-ON, and AMDP-MSG-ID 
                
               Version Number 
               Syntax: AMDP-VERSION 
               This will include the version number of AMDP used in the 
               envelope. This way servers can negotiate advanced 
               commands as they become available.  
                
               Payment Receipt 
               Syntax: AMDP-PAYMENT-RCPT 
               This will inform receiving servers that postage has been 
               made, and provide the information needed to retrieve the 
               payment information.  
                
                
         Once the envelope is sent by the MHF [50] to the recipient mail 
         server [70], the first task of the MHF is completed.  The MHF 
         will later have to authenticate the existence of the message, 
         issue a confirmation number, serve the message, and notify the 
         sender of the delivery status. 
          
      4. The AMDP recipient server [70] will accept envelopes that meet 
        its business requirements, do not violate the public mail 
        policy [60], and can authenticate themselves.    
         
        The process is presented herein as follows: 
             
            The server will receive the AMDP envelope, and while the 
            connection is still open, return an OK code, then TERMINATE 
            the network connection. Optionally the server checks if this 
            is the first time it has been contacted by this MHF, and 
            enforces a one envelope per unauthenticated MHF rule before 
            it accepts future envelopes for processing.  Once an MHF has 
            passed this test, the server will accept further envelopes 
            from the MHF.  
             
            The IMG server [70] proceeds to authenticate the MHF [50] by 
            checking the IP of the network connection against the 
 
 
EL FAKIH                Expires - August 2003               [Page 21] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
            allowed MHFĂs for the domain in the envelope [40].  It will 
            also authenticate the enclosed AMDP-MHF-NAME, and or the 
            AMDP-MHF-ID within the envelope.  The connecting IP number 
            of the MHF may be different from the one specified in the 
            envelope as AMDP-MHF-NAME, however the IP MUST be explicitly 
            allowed to send messages on behalf of the domain.  For 
            example Yahoo.com can have two sets of MHF servers, some 
            that send notification envelopes, while others store and 
            serve the mail messages. However in both instances these 
            servers are authenticated as MHFs in the DNS entries of 
            Yahoo.com. 
             
            Note: The authentication of the AMDP-MHF-NAME, and  
            AMDP-MHF-ID are discussed in section .                                                 10.  
             
            When the recipient IMG [70] receives an envelope, it will 
            cross check the email category against its public and 
            private mail acceptance policy to decide if it is allowed to 
            proceed to the internal mail servers.  If the message is 
            refused, no further action is taken, and the message will 
            simply expire at the holding MHF, however it is possible for 
            the server to report the incident to external incident 
            reporting services [120] in the event the message was in 
            violation of the public mail policy [60]. 
             
            The receiving IMG [70] will contact the MHF [50], supply the 
            message id, the timestamp of the envelope, and the 
            expiration date of the message.  The MHF within the same 
            network session will reply with a true or false. If the 
            response is True then it will reiterate the email address of 
            the recipient, and issue a confirmation number.  If the 
            provided email address matches the one in the envelope, [70] 
            will acknowledge the message, and hand the mail message to 
            the mail delivery agent [80].  
             
            If at any of these steps, something fails, the envelope is 
            dropped and no further actions are taken by IMG [70].  The 
            reason behind not issuing any error messages is to protect 
            MHFs from being victims of DoS attacks using forged 
            envelopes.  SMTP errors will be generated to non AMDP 
            systems. 
             
            It is also possible that during this transaction, if the 
            recipients IMG policy allows for direct receipt.  i.e. the 
            message sent is within its size limitations, and mail from 
            the MHF is accepted, then the IMG can request from the MHF 
            the message itself, which will be passed on to [80] instead 
            of passing the empty AMDP envelope. 
             
 
 
EL FAKIH                Expires - August 2003               [Page 22] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
             
      5. Before we continue with the email at point [80], we need to 
        check what happens at the mail holding facility [50]. 
         
        This is the second task performed by MHF [50] once it is 
        contacted by an IMG [70] with the correct message id, 
        expiration date, and timestamp.  It acknowledges the existence 
        of the message and issues a confirmation number. It will 
        respond negatively to any future requests using the same 
        message id in any combination until the passing of the 
        expiration date.  Doing so will make it useless for an external 
        source to try guessing ids for a message once it was 
        acknowledged by the recipient server 
         
        The three pieces of information outlined herein will make it 
        tough for an attacker to guess valid message ids, or to 
        retrieve email addresses. And once the MHF has been queried and 
        confirmed by the recipient server, the id can not be used to 
        make any further queries.   The sending MHF can increase the 
        pieces of information it requires for authentication.  In this 
        example we used three keys; however the MHF can ask the 
        receiving server to authenticate with more keys using the AMDP-
        AUTH-KEYS, of course with a reasonable maximum setting. The MHF 
        can also limit itself to queries made by servers it already 
        contacted and have not authenticated awaiting message ids. 
         
        The MHF will also know at this stage whether the message has 
        been accepted for delivery and expect that the final user [90] 
        to retrieve the message before the expiration date if they are 
        available.  These will be made available to the message 
        reporting system.   
         
        Once the authentication has been successfully completed between 
        [50] and [70], the MHF will unlock the message for reading by 
        the end recipient.  This implies that before the authentication 
        process, the message can not be accessed because it is locked, 
        and a confirmation number has not been issued. 
         
        The MHF also keeps track of the email topics also known by 
        threads, by maintaining an active list of threads.  The 
        originating MHF will maintain the master copy of the thread 
        index.  When negotiating message ids, the servers can send the 
        updated thread keys to the receiving server if it requires 
        having the thread tree which is used to reference back the 
        thread.  This is useful to reduce the size of a message if it 
        is a thread so you do not need to send the original message 
        back and forth. A thread is also related to the to the 
        classification scheme, where the originator or sender can 
        classify the message.    
 
 
EL FAKIH                Expires - August 2003               [Page 23] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
         
        The thread information can also be used by the receiving mail 
        server [70] to identify existing communications between two 
        servers and allow mail to be transacted with lesser 
        authentications between the two parties.  
         
      6. Once the message has passed all necessary authentications on 
        the server side [70] a modified envelope is sent to the user 
        mailbox [80], containing the original envelope along with the 
        confirmation number, and other information required to retrieve 
        the mail message by the end user.  The message will then reside 
        in the userĂs mailbox [80] until it is retrieved by the end 
        user using POP or IMAP or other similar protocols. 
         
        In the transitional stage: 
         
        The message continues to be an SMTP mail message.  It is 
        readable by any email client.  The message will have two parts, 
        an SMTP header that includes the name, email, subject, date of 
        the message, etc, and a body.  The header will also include the 
        AMDP headers.  The body of the message will indicate that this 
        is an envelope for a message which is being held at a given 
        URL, it will tell the user the size, classification of the 
        message, expiration time, etc..  A properly formed URL will 
        automatically be highlighted by most mail clients, while in 
        others cases the user can choose to cut and paste the special 
        URL into a browser.    
         
        In the final stage: 
         
        The email message continues to be readable by regular mail 
        clients, but it will carry the AMDP header information that 
        will tell compliant email client to display the information 
        differently. For example instead of showing a message that they 
        have to click on, the message will be retrieved from the MHF 
        using the MSG ID, confirmation number etc..  
         
      7. The delivery cycle is finished when the user opens his email 
        client [90].  The email client will then connect to the IMAP or 
        POP server [80] and retrieve the standard header information.  
        The user will be able to see a list of available messages in 
        the mailbox, along with its senderĂs name, size, category, 
        date, expires etc..   
         
        In the transitional stage:  
         
        When the message is retrieved, they will receive the text 
        message described in the previous section, the user will then 
        proceed to click on the URL to open the content of the message. 
 
 
EL FAKIH                Expires - August 2003               [Page 24] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
         
        In the final stage:  
         
        When the message is clicked, the email client will retrieve the 
        message from the MHF using the HTTP, IMAP, POP or similar 
        protocols.  
         
        However in both cases the recipient must provide the MHF with 
        the following information to retrieve the message.  1) The 
        message ID 2) Expiration date 3)Time stamp, and 4) Confirmation 
        number to be able to retrieve the message.   
         
        Once the message has been downloaded by the client, the client 
        will use the same session to inform the MHF that the message 
        has been delivered.  
         
      8. At this point the message has been successfully delivered by 
        the MHF [50], and the following steps could be taken by [50] 
        such as:  
       
           a. Send a notification back to the sender using a simple 
             envelope to the senderĂs mailbox [80-S] notifying them of 
             the delivery status if it was requested, or make the 
             information available through a web interface. 
              
           b. Delete the message unless other ids are linked to the same 
             message.   
              
           c. Trigger an e-commerce transaction, such as issuing an 
             invoice where the downloaded message could have been a 
             software product, etc.. 
 
 
6.   Private and Public Mail Acceptance Policy 
    
   Historically most mail servers such as sendmail, postfix, etc., 
   allowed mail administrators to build private mail policies.  This is 
   done by installing and defining mail filters used to block unwanted, 
   or virus packed mail.   
    
   AMDP introduces the concept of private and public mail policies.  The 
   private mail policy is used to further restrict mail wishing to be 
   delivered to internal recipients, while the public policy is a method 
   by which the recipient server publishes the rules by which it will 
   accept mail for delivery [60].  Users wishing to email people within 
   a given network are bound by these rules, or the mail will be 
   ignored.   
    

 
 
EL FAKIH                Expires - August 2003               [Page 25] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
   The MIS [60] serves all the information related to the public mail 
   policy, being able to adapt to changing trends in the mail delivery 
   process.  The following is a sample MIS report, also referred to the 
   public mail policy. 
    
      ### START OF SAMPLE REPORT ######## 
      DOMAIN: yahoo.com 
      MIS: mis.yahoo.com 
      SUPER-AUTH: auth0.yahoo.com 
      MAX-MAIL-SIZE: 200kb 
      MSG-PER-MIN: 60 
      DELIVERY-PRIORITY: [90AMDP] [10SMTP] 
      CONTACT-INFO: http://www.yahoo.com/contact/ 
       
      # mail classification and rates 
      ACCEPT-CLASS: *::BULK::* [0.001] 
      ACCEPT-CLASS: *::BUSINESS::* [0.25] 
      ACCEPT-CLASS: *::GOV::* [1.00] 
      ACCEPT-CLASS: *::EDU::* [1.00] 
       
      #no charge for personal email 
      ACCEPT-CLASS: *::PERSONAL::* [0.00] 
       
      #charge $500 for unclassified mail 
      ACCEPT-CLASS: *::*::* [500.00] 
      DENY-CLASS: *::BULK::ADULT 
       
      ACCEPT-REJECT-PCT: 80% 
       
      # mail hours 
      UNSOLICITED_MAIL_HOURS: 18:00-21:00, 00:00-05:00 
       
      # Payment information 
      PAY: PAY.CENTIPAID.COM 
      PAY-METHOD: DIRECT 
      PAY-ACCT: YAHOO 
       
      #subscription servers 
      SUBSCRIBE-SYNCH: SUBSCRIBE.AYNA.COM:9012 
      SUBSCRIBE-AGENT: SUBSCRIBE.AYNA.COM:9012 
      ### END OF SAMPLE REPORT ######## 
    
    
   The public mail policy includes such items as: 
    
   Maximum mail size 
    


 
 
EL FAKIH                Expires - August 2003               [Page 26] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
      It defines the maximum message size allowed for direct delivery. 
      i.e. where a server allows the message to be accepted in its 
      entirety instead of the envelope.   
    
   Number of mail per minute 
    
      It defines the maximum number of mail messages allowed from any 
      domain name to be delivered within a minute.  This is important 
      for servers that are unable to process thousands of messages per 
      minute when receive mail from large mailing lists.  Mass mail 
      software will tailor its speed to match the number to ensure that 
      their messages will pass the mail gateway [70] 
       
      TBD: If [70] can reply to [50] with an ACCEPT-NEXT-IN field.  The 
      field will [50] how many minutes the MHF should have to wait 
      before it attempts a new connection. If the value is set to 0 then 
      the MHF is allowed to contact them immediately after. 
       
   Cache refresh rate 
    
      It defines the amount of hours before an MHF has to check the MIS 
      for an updated copy of the public mail policy.  
    
   Delivery Priority Assignment 
    
      It states what is the delivery priority assigned to incoming mail 
      message. For example a company may wish to assign 70% of its 
      processing resources to AMDP compliant messages and 30% to SMTP 
      based mail.   This way each administrator can make public their 
      level of tolerance of non-complaint mail servers.   
       
      Therefore an organization that will not accept any SMTP mail, it 
      can setup the resource 100% AMDP 0% SMTP.  The same model can be 
      used to allow other types of protocols in the future. 
    
   Contact info 
    
      This defines a non-mail based form to communicate with the mail 
      administrator (such as a URL, fax, phone, etc..).  This is 
      important for administrators of servers that are blocked from a 
      given network, or for law enforcement agencies to contact the 
      appropriate personnel about specific incidents using this method. 
    
   Rejected Classifications 
    
      This defines the classifications that are not accepted by the 
      network administrator i.e. a government agency, or an elementary 
      school do not want to accept any mail from marketing firms. And 

 
 
EL FAKIH                Expires - August 2003               [Page 27] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
      any MHF contacting them with such messages will be reported back 
      to the external incident reporting service [120]. 
    
   Accept Classifications 
    
      This defines the classifications that are accepted by the network 
      administrator. 
       
       
   Mail rates 
    
      Domain administrators can impose fees for accepting mail from 
      certain mail categories, including all.   
       
   Payment information 
       
      If accepting postage for mail received, then all information 
      related to the payment information, are included herein. 
       
       
   Unsolicited Mail hours (Universal Time) 
    
      It tells unsolicited mail providers what are the best times to 
      deliver mail to the network.  This is important for networks that 
      wish to allow unsolicited mail to be accepted however within off 
      peak times. 
    
   Subscription server (used in unsolicited mail delivery) 
    
      This server is used to help marketers build mailing lists that 
      will be allowed through the mail gateway of a given domain.  The 
      subscribe server has two or more levels of subscriber acceptance.  
      A user can accept to subscribe to a specific mail list, or to a 
      mail classification.  
       
      The most popular case is when a company offers its users to signup 
      to its mailing list.  For the subscription to be accepted a few 
      steps need to occur.   
       
         1. The external subscription [110] engine has to check the 
         public policy [60] of the domain name, and if it does not find 
         any problems (i.e. domain or classification banned) then it can 
         automatically apply to be have an entry added to the server.  
         The purpose for seeking this action, is to automatically build 
         the required rules for the mailing list provider that will 
         allow him/her access to the network. 
          
         2. The next step is done by the subscribe server [60], which 
         will send a confirmation URL to the user in question [80], and 
 
 
EL FAKIH                Expires - August 2003               [Page 28] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
         if the subscriber agrees, then user is added to the mailing 
         list database in [60], and a message is sent to the originating 
         subscription engine [110]. The subscribe server will contain 
         similar rules to the ones use in mail gateway, such as one 
         envelope rule, and deny any future requests if a specific 
         number of requests are made from 110. 
       
      The sender must check the mailing list before trying to email any 
      of the users on his list, to insure that their rejected/accepted 
      message ratio is within the limit assigned by the domain admin.  
       
      The server is also used to synchronize information with available 
      mailing lists against the rules set by the domain name 
      administrators where: 
 
         1. Senders that maintain their own mailing lists, will use the 
         subscribe server from time to time to update their mailing 
         lists by removing anyone who has indicated that they do not 
         wish to receive mail from the source, mail messages with a 
         given classification.   
          
         The mailing list update may be done in many ways, but for 
         simplicity we assume that the sender will send a list of all 
         the emails in the given domain name, along with the intended 
         mail classification, the server will then process the list, and 
         return a list of the ones that explicitly accepts receiving 
         mail for this classification.  These providers will then have 
         to unsubscribe any users in their mailing list before 
         attempting to email them. 
          
         2. Businesses that want to email marketing materials to users, 
         can access the subscription server to get information on which 
         accounts will be accepting mailing for a certain topic. The 
         service of providing these email addresses could be free or 
         paid.   
          
          
         3. The server will also be used to synchronize with other 
         subscribe servers if they wish to syndicate or distribute their 
         mailing list.  
 
    
7.   Delegating and authenticating Mail Holding Facilities 
    
    
   There are two ways to configure and setup an MHF [50] so it can be 
   accepted by the recipientĂs Incoming Mail Gateways [70] (IMG) as a 
   valid MHF for the domain it serves: 
    
 
 
EL FAKIH                Expires - August 2003               [Page 29] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
   Static setup: used in simple setups. 
    
      The domain administrator has to explicitly delegate each MHF as a 
      valid mail server by entering their name and IP in the DNS table 
      in a specific format.  The naming convention is mhf-N.domainname, 
      where N is the any positive integer value. This convention is used 
      to make it possible to identify servers that are acting as MHFs on 
      behalf a domain.  
       
      When an MHF sends a notice to other AMDP servers, it identifies 
      itself by entering its domain in AMDP-MHF-NAME header, which is 
      authenticated by making a DNS lookup. 
       
      The ultimate goal is to eventually define a new MH record in the 
      DNS specification that will explicitly delegate which servers can 
      act as an MHF on behalf a domain. 
 
    
   Dynamic setup: used in complex setups involving dynamic, and long 
   list of MHFs 
    
      The AMDP-MHF-NAME included in the envelope points to the domain 
      name of the MIS [60].  The MIS holds the name and IP of all valid 
      MHF for the domain. 
       
      The naming convention for the authentication MIS is amdp-
      mis.domainname. This will make it easier to visually know which 
      servers act as MIS on behalf a domain. 
       
      The AMDP-MHF-ID is a character string unique to that domain, and 
      maintained by the MIS server [60]. The flexibility of having the 
      MIS autheticate the AMDP-MHF-ID is required in cases where 
      redundant servers are in place and in the event a given MHF is 
      down the administrators can setup alternate MHFs to assume the 
      responsibility of the MSG-IDs that were under the care of the 
      downed server. 
       
      This setup is much more flexible for administrators delegating 
      hundreds or thousands of MHFs to third parties, and not having to 
      wait for DNS to resolve.   
    
   In the final stage (optional): 
    
      In the long term, DNS should be upgraded to include: 1) An MH 
      record type, which is equivalent to listing allowed MHFs in the 
      DNS 2) An AX record that denotes the authentication servers to be 
      used for this domain. 
       
      For example yahoo.com authorizes 10 servers to act as primary MHF 
 
 
EL FAKIH                Expires - August 2003               [Page 30] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
      on its behalf by inserting them directly into its DNS table. It 
      also maintains it own MHF authentication server (AUTH-MHF), which 
      is also defined in their DNS table, and it handles another 500 
      MHF. 
       
      If any of the first 10 servers sends a message on behalf of Yahoo, 
      it will include in the header an AMDP-MHF-NAME header pointing to 
      its domain name (mhf-N.yahoo.com), letting the receiving AMDP know 
      that it can make a direct query of the DNS and find its 
      corresponding IP. 
       
      However if any of the other 500 servers managed by the AUTH-MHF 
      sends any messages, then they submit their assigned number as 
      AMDP-MHF-ID along with their authentications server domain name in 
      the AMDP-MHF-NAME tag (example AMDP-MHF-ID: MHF-005 AMDP-MHF-NAME: 
      auth-mhf-501.domainame).  Once an MHF-ID is detected, then the IP 
      of the MHF-NAME is queried from the DNS, and then it is contacted 
      with MHF ID to obtain the domain IP of the MHF hosting the 
      message.. 
 
    
8.   Mail Classifications 
    
   Email classification is a method by which a sender pre-identifies the 
   topic of an electronic message, so it can be properly processed for 
   delivery through the various mail gateways it passes through.  This 
   classification is also used in the optimization of the delivery 
   process and allocation of recourses based on the message priority, 
   which is directly related to its classification.  Classification is 
   also a way to control the type of mail allowed to a given domain.  
   For example a business can make known on their public policy that 
   they will only receive mail from authenticated mail servers, and 
   hence reduce the incoming mail to businesses and companies willing to 
   be authenticated. 
    
   Classifications can be of two forms:  
   1. Authenticated classifications.   
   2. Non-Authenticated classifications.   
    
   When a message is classified using a properly authenticated 
   classification service, the recipient mail server 70 honors the type 
   of mail classification assigned.  This can reduce the steps a 
   receiving gateway will do in checking for abuse.  This also shifts 
   some of the burden to the authenticating third party, which will be 
   involved in any disputes, and manage the active classification of the 
   domain.  It will also reclassify the domain based on its current 
   activity as reported by receiving mail servers.  However in non-
   authenticated classifications, more checks could be made, such as 
   querying other black lists   
 
 
EL FAKIH                Expires - August 2003               [Page 31] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
    
   Structure of the classification string: 
    
      The mail classification string is composed of three or more parts 
      that define the agent type, mail type, and message type. When put 
      together, they provide a standard methodology to describe the 
      message topic. The various types are separated by a common 
      separator such as Š::Ă.   
    
   Agent type 
    
      Defines how the senderĂs mail server behaves. The mail server can 
      be a public mail gateway and hence defined as "Public", the mail 
      server could relay mail directly on behalf of its domain, and is 
      named "Direct", while companies relying on third party servers to 
      relay its mail, represent themselves as "Agent".   As other new 
      agent types surface, they can be assigned a key type.   
       
      This type is defined by the domain administrator but can be 
      overwritten by third party services that authenticate the agent 
      type for a given domain. 
    
   Mail type 
    
      The mail type defines the primary use of the domain, and is set by 
      the mail administrator. For example a domain can be used for 
      business, bulk, education, government, personal, etc.. This is an 
      important classification, and initially will be allowed to be set 
      by the owner of the domain, however it also allows the design to 
      be adaptive and to be changed in the future to overwrite this by 
      known activity of the domain name as kept by third party services 
      such as todayĂs blacklists, which most likely has to occur since 
      some domains will still feel the urge to forge their mail type 
      classification.  Some of the classifications are defined below: 
       
      Bulk - This means that this business mainly deals with bulk email, 
      they are marketers, mass mailing sites, etc.. 
       
      Business - This means the company is a business that deals with 
      other business and it does not use this domain to mass mail, if 
      they do occasionally send bulk mail, then they need to identify 
      those messages as bulk. If the domain administrators, or its 
      agent, fail to comply then it can be blocked from further mail 
      processing. 
       
      Government - This means that the emails generated are mainly 
      official in nature, and mass mailing is not expected from these. 
       
      Educational - This means that the emails generated are mainly 
 
 
EL FAKIH                Expires - August 2003               [Page 32] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
      educational, and not to be confused with messages from .edu 
      domains.  A university may be classified as a business if its 
      emails are to prospective students, while domains or MHFĂs used to 
      server students email, can set this key to "Personal" or "Bulk" 
      depending on the volume of messages generated.  
       
      Commerce - This means that the business is using this message to 
      complete an e-commerce transaction, such as sending in a receipt, 
      invoice, etc.. This domain name can not act as a bulk domain as it 
      will loose its commerce classification.  
       
      Personal ű This means that this domain is mainly used for personal 
      purposes and does not Spam.  If it does, it should use the Bulk 
      key instead. 
    
   Message type 
    
      This is the sub category of mail types and it is defined by the 
      user.  It lets the final recipient know what type of message it 
      is, and it used for informational purposes only, since there is no 
      way to guarantee that the field is used correctly.  However it is 
      included for completeness, making it possible for businesses to 
      use this flag for more advanced functionalities in email.  Some of 
      possible message types are included here for illustration 
      purposes: 
       
      BULK: Legal, Adult, Entertainment, Mailing List, Travel, 
      Computers, Sports 
      BUSINESS: Inquiry, Response, Proposal, Personal 
      GOVERMNET: Subpoena, Information, Request 
      COMMERCE: Invoice, Receipt 
    
    
   Recommendations: 
    
      It is recommended that a domain name use a separate domain name 
      for bulk mailing where they plan to mail hundreds or more 
      unsolicited or solicited messages. For example yahoo.com would use 
      yahoo-bulk.com when emailing few million users. 
    
    
   Mail Classification Examples 
    
      In the following examples the ADMP envelope header will look 
      something like these: 
       
      MAIL-CLASS: Public::Bulk::Entertainment  (1) or, 
      MAIL-CLASS: Direct::Business::Internet Service::Inquiry (2) or, 
      MAIL-CLASS: Agent::Bulk::Mailing List  (3) 
 
 
EL FAKIH                Expires - August 2003               [Page 33] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
       
      In these examples, the separator used is the Š::Ă.  Example (1) is 
      originating from a "Public" mail gateway such as Yahoo.com, or 
      Ayna.com.  The message is classified as "Bulk" by the 
      administrators of the mail system, since they do not have control 
      of publicly available email accounts.  The user has announced that 
      this message is of a "Entertainment" topic, and has been accepted 
      as such. 
       
      Although in example (1) we said that Public gateways send Bulk 
      mail that was just an example, since Yahoo can decide to make 
      available a paid account in which the user tells the mail 
      provider, in this case Yahoo that this account is to be used for 
      business or personal.  
       
      In example (2) a domain name used and managed by a company, sets 
      its agent type to "Direct" since they process their own mail, 
      while the domain is a "Business" domain, and it classifies itself 
      as "Internet Service", and the user mailing 
    
    
    
9.   Automatic reporting and resolution of classification abuse 
    
   The proposed system to be used allows mail servers to transmit abuse 
   reports which can generate notifications send to the administrator of 
   the domain, and a way to resolve those issues.  
    
   Most spammers get away with what they do, because there is no one way 
   to find out who did what.  A spammer who spams one or more domains 
   will trigger automatic notifications to the reporting gateway, which 
   will use a specific criteria to issue an alert or a warning to other 
   mail systems not to receive mail generating from this domain, or to 
   redefine parts of the mail classification.  This entity can become a 
   legal traffic entity dealing with issues arising from mail abuse, and 
   can be supervised by the US postal service as it is done today. 
    
    
10.    AMDP envelope headers 
    
   The protocol used by AMDP follows the same guidelines as SMTP.  Most 
   of SMTP commands are used, while others were added or used in a 
   different way. 
    
   AMDP relies on sending routing and authentication information using a 
   standard format referred to as an AMDP envelope.  It is similar to 
   one used in SMTP, however some changes were made to keep AMDP 
   flexible and be able to grow without the restrictions imposed by 
   certain SMTP headers.  
 
 
EL FAKIH                Expires - August 2003               [Page 34] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
    
10.1     AMDP-About 
    
   This header is used to provide a URL to the website who develops and 
   maintain the AMDP implementation used to mail the mail message.   
    
   Usage 
    
     AMDP-About: http://www.foo.com/ 
    
    
10.2     AMDP-From, AMDP-From-Name 
    
   The AMDP-FROM contains the email address of the user sending the 
   message, while AMDP-FROM NAME contains the name of sender. 
    
   In SMTP envelopes, both the email and name of sender are transmitted 
   under the same header (FROM). Using one heading for the two pieces of 
   information, adds several complications when it comes to encoding and 
   decoding the name or address for internationalization purposes. 
    
   In AMDP these two pieces of data are split into two fields the AMDP-
   FROM and AMDP-FROM-NAME. 
    
   The email address AMDP-FROM of the sender is examined and corrected 
   by the sender's Outgoing Mail Gateway [20] after authentication.  
   This reduces common problems due to the inexperience of some users of 
   the proper notation of their email, especially when we enter the 
   realm of international domain names, and possibly dynamically 
   assigned email addresses used for secure transactions, or to provide 
   anonymous email services.  
   It is also a mechanism to overwrite any attempt made by internal 
   networks to forge their identity in outgoing mail messages.   
       
   The AMDP-FROM NAME is not set by OMG [20] since the user can change 
   the name on the account without affecting the functionality.  This 
   field is optional. 
    
   Usage 
      
     AMDP-FROM:  <adonis@amdpmail.com> 
      
     The header contains the email address enclosed by <> and encoded in 
     UTF8. 
      
     AMDP-FROM NAME: <Last name, First Name> 
      
     The header contains the name of the user in UTF8 enclosed by <>.   
       
 
 
EL FAKIH                Expires - August 2003               [Page 35] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
    
10.3     AMDP-To, AMDP-To-Name  
    
   The AMDP-TO header contains the recipient's email address, while 
   AMDP-TO-NAME contains the recipient name. 
    
   In SMTP envelopes, both email and name of recipient are transmitted 
   together under the same header (TO). Using one heading for the two 
   pieces of information adds many complications when it comes to the 
   encoding of the name or address for internationalizations purposes. 
    
   In AMDP these two pieces of data are split into two fields the AMDP-
   TO and AMDP-TO-NAME. 
    
   The email address of the recipient is entered by the user, and is 
   converted to UTF8 by the email client [10] or the mail gateway [20].  
    
   Usage 
    
     AMDP-TO: <email@address.com> 
      
     The header will contain the email address between <> and it is in 
     UTF8.  Which will enable older systems that support ASCII based 
     email addresses to pass through it easily, while allowing new mail 
     systems that are UTF8 enabled to process the new names. 
      
     AMDP-TO NAME: <Last name, First Name> 
      
     This command will contain the names of the users. It is in UTF8. 
   Since each envelope sent out from MHF [50] belongs to one and only 
   one email user, AMDP-TO and AMDP-TO-NAME do not include usage 
   examples of multiple recipients, however when an email is being sent 
   from the OMG [20] to the MHF [50], multiple recipients are acceptable 
   and the usage is defines as such: 
    
     AMDP-TO: <email1><email2><email3> 
     AMDP-TO-NAME: <name1><><name3> 
      
     Where the name of email2 was not specified 
     
    
10.4     AMDP-SUBJECT 
    
   AMDP-SUBJECT: Email subject 
    
   The subject specified the subject of the message and should be 
   converted to UTF8.  AMDP does not use the SUBJECT set by SMTP since 
   it may contain various encodings that will limit the functionality of 

 
 
EL FAKIH                Expires - August 2003               [Page 36] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
   the subject field.  In the absence of AMDP-SUBJECT, the 
   implementation can use SUBJECT provided by SMTP for that purposes. 
    
   Usage 
    
     AMDP-SUBJECT:  Subject Title of the message 
    
    
10.5     AMDP-ATTACHMENTS 
    
   ATTACHMENT: Email attachment list 
    
   This is the list of attachments used in a message.  (TBD) 
    
   Usage 
    
     AMDP-ATTACHMENT:  
    
    
10.6     AMDP-Mail-Class 
    
    
   This header is used to classify the types of emails sent.  Please 
   refer to section .                    8 titled "Mail Classifications" for details about 
   the mail classification. 
    
   The mail classification string is composed of three or more parts 
   that define the agent type, mail type, and message type. When put 
   together, they provide a standard methodology to describe the message 
   topic 
    
   The first part is mandatory and is usually controlled by the service 
   provider, while the second part is controlled by the sender.  So an 
   ISP can classify accounts as business or personal, and the user can 
   set another level of classification if they want to. 
    
   Usage 
    
      AMDP-MAIL-CLASS: Public::Bulk::Entertainment 
    
    
   Security considerations 
    
   The classification is prone to being abused and need to have various 
   checks.  The design assumes that third party services will be created 
   to acknowledge if a given domain falls within an agent type or 
   another.  It will also promote or demote the mail classification of a 
   given domain. 
    
 
 
EL FAKIH                Expires - August 2003               [Page 37] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
    
10.7     AMDP-Language 
    
   This header defines the language of the content of the email.  It is 
   set to the ISO 639 code. 
    
   It can be set by the email client [20], or by the MHF [50] that can 
   use the UTF8 ranges to determine the language of the message, or use 
   more complex language pattern matching algorithms.   
    
   This is needed to match the server messages to the language of the 
   mail message in case of an error, and also to automate the process of 
   translation from one language to another in the future. 
 
   Usage 
    
      AMDP-LANGUAGE: EN 
    
    
10.8     AMDP-Encoding 
    
   The ENCODING header will be set to the industry standards encoding 
   codes as defined by Unicode documentation, and RFC 2277 iv 
    
    
   It is used to identify the encoding of the mail message.  Ideally 
   this should be set to UTF8, but it is available to be set to whatever 
   the system supports and allows for other programs to know how to deal 
   with the encoding of the message. 
    
   Ideally the MHF should convert all messages it receives into a UTF8 
   encoding message unless it is encrypted by the original sender.  This 
   will make it easy for the mail receiver efforts to focus on Unicode 
   support. 
    
   Usage 
    
      AMDP-ENCODING:  UTF-8 
    
    
10.9     AMDP-Date 
    
   This is the data the message was sent from the user [10] in UTC 
   format. 
    
   Usage 
    
     AMDP-DATE: 2003-01-29 10:10:10 AM UTC 
    
 
 
EL FAKIH                Expires - August 2003               [Page 38] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
10.10      AMDP-OMG-ID 
    
   This is the unique identification string for the outgoing mail 
   gateway OMG [20]. 
    
   It is mainly used in communications between OMG [20] and MHF [50], 
   and it is not forwarded outside the domain.  It is also used to route 
   messages to the sender. 
    
   Usage 
    
     AMDP-OMG-ID: foo.bar.com 
    
    
10.11      AMDP-MSG-Id 
    
   This is a unique id issued by the MHF [50] holding the message.  The 
   number is one of the keys used to retrieve the message by the 
   intended recipient.  In the event a sender sends one message and 
   copies five people.  Each recipient will receive an envelope with a 
   different MSG-ID.  This id is an important tool is reducing Spam and 
   the manner it is created should by chosen carefully as not to be 
   predictable.  
    
   Note: The MSG-ID is used once and can not be reused until it has 
   expired, it MUST be difficult to guess, and SHOULD NOT be built upon 
   any relation with the other pieces of information used to 
   authenticate i.e. email address, expiration, and timestamp.  This 
   will make it much more difficult to impersonate others online. 
    
   Usage 
    
     AMDP-MSG-ID: MMXA-12348754-ABVGS 
    
    
10.12      AMDP-Size 
    
   This is the size of the mail message, including the attachment.  It 
   should include the units used. 
    
   Usage 
    
     AMDP-SIZE: 4068 <MB> 
      
      
10.13      AMDP-MHF-Name, AMDP-MHF-Id 
    


 
 
EL FAKIH                Expires - August 2003               [Page 39] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
   The two vales are used to identify the Mail Holding facility [50] to 
   the recipient servers [70].  Please refer to section 7                                                        . for a detail 
   description of these fields and the values to be assigned to them. 
    
    
10.14      AMDP-Auth-Port 
    
   The header contains the port number at which the authentication 
   server defined in AMDP-MHF-Name will return queries about messages 
   received from a specific MHF [50] 
    
10.15      AMDP-Timestamp 
    
   The header contains the timestamp at which the envelope was created 
   by MHF, before contacting the IMG [70].  It is used as part of the 
   authentication scheme. 
    
10.16      AMDP-Expire-On 
    
   The header contains the date the message expires on. This will allow 
   both sides of the delivery process to clear expired messages. 
    
    
10.17      AMDP-Auth-Keys 
 
   This is the list of authentication keys that need to be used by the 
   IMG [70] when contacting the MHF [50].  If not specified then the key 
   are assumed to be AMDP-TEMPSTAMP, AMDP-EXPIRE-ON, and AMDP-MSG-ID 
    
10.18      AMDP-VERSION 
    
   This includes the version number of AMDP used in the envelope. This 
   allows servers to negotiate advanced features as they become 
   available, and be adaptable to earlier versions of the protocol 
    
10.19      AMDP-PAYMENT-RCPT 
    
   This will inform receiving servers that postage has been made, and 
   provide the information needed to retrieve the payment information. 
 
 
Security Considerations 
    
   Security considerations are outlined in the AMDP design section 
   within the appropriate context. 
    
    
References 
    
 
 
EL FAKIH                Expires - August 2003               [Page 40] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
                                                                         
   i  Bradner, S., "The Internet Standards Process", BCP 9, RFC 2026, 
      October 1996. 
    
   ii  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
      Levels", BCP 14, RFC 2119, March 1997 
    
   iii Postel, J., "Simple Mail Transfer Protocol", RFC 821, August 
      1982. 
       
   iv Alvestrand, H. "IETF Policy on Character Sets and Languages ", BCP 
      18, RFC 2277, January 1998 
    
 
    
Acknowledgments 
    
   <Add any acknowledgements> 
    
    
Author's Addresses 
    
   Adonis El Fakih 
   PO BOX 6048 
   NASHUA, NH 03063, USA 
   phone: +1 (508) 801-0273 
   Email: adonis@aynacorp.com 
 
 
IPR Notices 
 
   Intellectual Property Rights disclosure statement pertaining to AMDP 
    
   Adonis El Fakih has a patent pending that may relate to AMDP internet 
   draft specifically to the work derived from draft-amdp-00.txt. 
    
   Upon approval by the IESG of the relevant Internet standards track 
   specification and if any patents issue to A. El Fakih with claims 
   that are necessary for practicing this standard, any party will be 
   able to obtain the right to implement, use and distribute the 
   technology or works when implementing, using or distributing 
   technology based upon the Specific specification(s) under openly 
   specified, reasonable, non-discriminatory terms. 
    
   Because A. El Fakih wants to make this mail delivery protocol widely 
   available to help control the growing problems associated with 
   unsolicited mail, the non-commercial use of this protocol is free. 
    

 
 
EL FAKIH                Expires - August 2003               [Page 41] 
                   Adaptive Mail Delivery Protocol       January 2003 
 
 
   Requests may be sent to: 
   Adonis El Fakih 
   PO BOX 6048 
   Nashua, NH 03063, USA 
   phone:    +1 (508) 801 0273 
   email:    adonis@aynacorp.com 
    
 
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 
   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." 
    













 
 
EL FAKIH                Expires - August 2003               [Page 42]