[Text version]

Network Working Group Internet-Draft Expires: February 17, 2004

W. Weinman bw.org August 19, 2003

Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on February 17, 2004.

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

This document is the specification of a protocol for Internet electronic mail transfer. It replaces Simple Mail Transfer Protocol (SMTP) with a more secure derivative called Authenticated Mail Transfer Protocol (AMTP).

Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1   Requirements notation  . . . . . . . . . . . . . . . . . . .  3
   1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.    Rationale  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.    The AMTP Model . . . . . . . . . . . . . . . . . . . . . . .  6
   3.1   Authentication . . . . . . . . . . . . . . . . . . . . . . .  6
   3.2   Codification . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.    Overall Operation  . . . . . . . . . . . . . . . . . . . . .  7
   4.1   X.509 Certificate Requirements . . . . . . . . . . . . . . .  7
   4.2   Command Syntax . . . . . . . . . . . . . . . . . . . . . . .  7
   4.2.1 Hello Command (HELO) . . . . . . . . . . . . . . . . . . . .  7
   4.2.2 Extended Hello Command (EHLO)  . . . . . . . . . . . . . . .  7
   4.2.3 Mail Policy Code (MPC) . . . . . . . . . . . . . . . . . . .  9
   4.3   MPC Syntax . . . . . . . . . . . . . . . . . . . . . . . . .  9
   5.    Security Considerations  . . . . . . . . . . . . . . . . . . 13
   6.    IANA Considerations  . . . . . . . . . . . . . . . . . . . . 14
         Normative References . . . . . . . . . . . . . . . . . . . . 15
         Informative References . . . . . . . . . . . . . . . . . . . 16
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 16
         Intellectual Property and Copyright Statements . . . . . . . 17

1. Introduction

Internet electronic mail is becoming expensive to use and to deliver due to widespread subversion of security precautions for the purpose of delivering Unsolicited Bulk Email (UBE). This problem can be mitigated by shifting the transfer of email to a protocol that authenticates mail transfer agents (MTAs) and enables codification and enforcement of a set of concise rules.

Authenticated Mail Transfer Protocol (AMTP) uses TLS and X.509 certificates to authenticate MTAs, and introduces a Mail Policy Code that allows MTAs to advertise policies. A server can decide whether to accept a particular message based on its own policies. Using the authentication capability, a server can manage traffic at any stage in the transaction by denying access to clients that have a history of abusive behavior.

1.1 Requirements notation

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 [RFC2119].

1.2 Terminology

This document uses specific terminology to refer to the various components, methods, techniques and other technologies involved in the transport and delivery of electronic mail. The definitions here describe the usage of these terms in this document.

   System Operator
      The person or corporate entity responsible for the operation of a
      system that exchanges mail over the public Internet using AMTP.
   Client MTA
      The transaction partner that initiates the connection is called
      the client MTA, or simply the client. The client MTA sends mail to
      the server. Traffic from the client is represented by "C:" in
      transaction listings.
   Server MTA
      The transaction partner that listens for incoming connections is
      called the server MTA. The server MTA receives mail from the
      client. Traffic from the server is represented by "S:" in
      transaction listings.
   Transaction
      The conversation between client and server, from the time the
      client connects to the server, to the end of the connection.
   Transaction Partner
      Either one of the two parties involved in a transaction. A
      transaction partner may act as a server or a client.

2. Rationale

In recent years Internet mail has been plagued by a proliferation of Unsolicited Bulk Email (UBE). A number of remedies have been applied to the problem, including Realtime Block Lists (RBLs), server- and client-side filters, and legislative and other legal solutions. UBE continues to proliferate for a number of reasons, two of which stand out as particularly causal:

   Authentication
      SMTP servers allow connections from anonymous sources.
      There are many good arguments for preserving the possibility of
      anonymous email, but somewhere along the trail followed by each
      message, someone must be held responsible for abuse of the system.
      Without such accountability chaos will continue to prevail.
      Authentication of Mail Transfer Agents (MTAs) designates a point
      of responsibility short of authenticating users. This preserves
      the possibility of anonymity while allowing system operators to
      enforce their own policies.
   Codification
      There is no universally recognized code of behavior.
      Before a set of policies can be enforced, terminology must be
      defined that can be understood by all the parties involved.
      It is desirable to allow each system operator to establish and
      enforce their own policies. Clear and concise codification of
      policies will allow system operators to post their own set of
      requirements, based on a universally recognized code, at their
      borders.

3. The AMTP Model

Authenticated Mail Transfer Protocol (AMTP) is based upon Simple Mail Transfer Protocol (SMTP, [RFC2821]) and addresses the twin problems of authentication and codification. AMTP uses Transport Layer Security (TLS, [RFC2246]) to create an environment of trust between Mail Transfer Agents (MTAs) involved in a transaction. MTAs then exchange Mail Policy Codes (MPCs) to establish permission for mail delivery.

AMTP inherits the specification of SMTP and builds upon it. This document specifies only the changes to SMTP and therefore implicitly incorporates the latest SMTP specification [RFC2821] except where indicated.

3.1 Authentication

AMTP uses authentication to create a trust relationship between MTAs. This trust relationship requires an identifiable party on each end of the transaction who can be contacted in the event of a policy violation. It is important to note that the sender does not need to be identifiable as long as there is an intermediary (e.g., a service provider) who is willing and able to assume responsibility for policy compliance.

AMTP uses TLS to create a secure and authenticated connection between the client and the server. Both server and client MUST present a valid X.509 certificate [RFC2459] signed by a trusted Certificate Authority (CA) in order to begin a session. This requirement provides each mail system operator with confidence that their transaction partner can be identified and contacted in the event of a policy violation.

3.2 Codification

The goal of codification is to allow those responsible to enforce their own policies and obey the policies of the other MTAs they exchange messages with.

A Mail Policy Code (MPC) is used to codify mailing practices and policies. A client MTA provides the MPC for a particular message as part of its envelope. Conversely, a server MTA MAY advertise MPCs that it allows or disallows. The MPC specification (Section 4.3) strives to be policy-neutral while allowing system operators to establish policies that work for their systems and their users.

4. Overall Operation

This section provides the specification of the AMTP protocol and its requirements.

4.1 X.509 Certificate Requirements

The AMTP protocol REQUIRES that each connection be secured using TLS and that each party to a transaction over the public Internet MUST present a valid X.509 Certificate [RFC2459]. A valid certificate meets the following minimum conditions:

   o  The certificate has been be signed by a CA recognized by the
      transaction partner.
   o  The Subject of the certificate MUST have a fully-qualified domain
      name in the Common Name (CN) field that matches the PTR record
      found by a DNS query of the associated IPv4 address in the
      IN-ADDR.ARPA zone. Equivalent tests SHALL apply to connections
      using IPv6 or other non-IPv4 protocols.
   o  Each certificate MUST have been issued on a date prior to the date
      of the connection, and expire on a date later than the date of the
      connection.

A system operator MAY establish different criteria for use over a private network. For example, an ISP may provide self-signed certificates for use by its customers from dynamically-allocated address space. The ISP system operator must use its own precautions to ensure that those self-signed certificates are considered valid only when presented from connections under its control.

4.2 Command Syntax

AMTP inherits the syntax of SMTP, with a few important exceptions and changes. The areas in which AMTP syntax differs from SMTP are described here. This document implicitly incorporates RFC-2821 except where indicated.

4.2.1 Hello Command (HELO)

AMTP does not support the legacy HELO command. A compliant server MUST return a failure code 504 for a HELO command. AMTP requires the extended EHLO response space to advertise MPC policies.

4.2.2 Extended Hello Command (EHLO)

A client MUST start an AMTP session by issuing the EHLO command. The argument field contains the fully qualified domain name of the client, if available. A server MUST issue a response code 504 if the EHLO argument does not agree with the provided certificate.

   The syntax of the EHLO command is
     ehlo = "EHLO" SP Domain CRLF

A server responds to EHLO as described in SMTP [RFC2821]. A server MAY include an MPC declaration as part of its EHLO reply. An MPC declaration consists of one or more permission lines. The syntax of a permission line is:

     permission-line  = keyword ehlo-mpc-object
     keyword          = "MPC-ALLOW" / "MPC-DENY"
     ehlo-mpc-object  = (mpc-entity / "*") "/" (mpc-class / "*")
     mpc-entity       = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
     mpc-class        = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")

An asterisk ("*") may be used as a wildcard in place of mpc-entity or mpc-class to match all legitimate values. Specific values for mpc-entity and mpc-class are specified in Section 4.3.

Permission lines SHALL be evaluated in the order presented. If the first keyword is MPC-ALLOW, a preceding permission line of "MPC-DENY */*" is implied; conversely, if the first keyword is MPC-DENY, a preceding permission line of "MPC-ALLOW */*" is implied.

4.2.2.1 Examples

Examples of possible AMTP EHLO responses are presented here.

     C: EHLO dastardly.example.org
     S: 504 Invalid certificate

The above client issued an argument that did not agree with its certificate. This error may also be used for other certificate violations.

     C: EHLO amtp.example.org
     S: 250-Greetings and felicitations
     S: 250-MPC-DENY */optout
     S: 250-PIPELINING
     S: 250 8BITMIME

The above server does not accept any optout C: EHLO amtp.example.org S: 250-Greetings and felicitations S: 250-MPC-DENY com/* S: 250-MPC-ALLOW com/individual S: 250-MPC-ALLOW com/confirmed S: 250-PIPELINING S: 250 8BITMIME

The above server allows only confirmed or individual mail from commercial entities; all mail from non-commercial entities is allowed.

     C: EHLO amtp.example.org
     S: 250-Greetings and felicitations
     S: 250-MPC-ALLOW */individual
     S: 250-PIPELINING
     S: 250 8BITMIME

The above server allows only individually addressed mail. No other mail is allowed at all.

4.2.3 Mail Policy Code (MPC)

The MPC command provides the Mail Policy Code (MPC) for the mail message being transferred as part its envelope. The client MUST issue the MPC command after the MAIL command and before the RCPT command. The client MUST provide exactly one MPC command per transaction.

The argument to this command is one mpc-object [Section 4.3].

Syntax:

     "MPC" SP mpc-object

The server MUST respond to the MPC command with one of the following result codes:

     250 Okay
     451 MPC temporary failure, try again later
     503 Command out of sequence
     550 MPC policy violation

4.3 MPC Syntax

A Mail Policy Code (MPC) is used to identify codified mailing policies for the purpose of establishing and enforcing rules of behavior between MTAs. They are used in two contexts: as a preemptory declaration of policy by a server MTA (Section 4.2.2); and as a generic classification of an individual message (Section 4.2.3).

The current set of MPC codes and their meanings are presented here. In the future, a canonical list of MPC codes may be maintained by the Internet Assigned Numbers Authority (IANA) in accordance with their policies [RFC3232].

Each MPC consists of two parts separated by a slash (ASCII 0x2F):

     mpc-object     = mpc-entity "/" mpc-class
     mpc-entity     = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")
     mpc-class      = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-")

The mpc-entity part describes the person or corporate entity that initiated the mail message. The following mpc-entity values are defined as of the writing of this document:

   per
      The email message was sent by an individual person on behalf of
      herself/himself in a non-commercial context. The "per"
      classification SHALL NOT be used to solicit or prospect for new
      business or donations.
   com
      The email message was sent on behalf of a commercial entity,
      individual or corporate.
   ngo
      The email message was sent on behalf of a non-governmental, or
      non-profit, organization.
   net
      The email message was sent on behalf of network-administration
      staff and directly related to network operations. The "net"
      classification SHALL NOT be used to solicit or prospect for new
      business or donations.
   gov
      The email message was sent on behalf of a governmental entity.
   pol
      The email message was sent on behalf a politician in public office
      or a candidate in the process of campaigning for public office.
   mpc
      Reserved for messages from one system administrator to another
      system administrator about MPC policy violations. Valid only with
      the "individual" mpc-class. All systems MUST accept and deliver
      all messages marked as "mpc/individual". This mpc-entity combined
      with any mpc-class other than "individual" SHOULD be treated as
      invalid.

The mpc-class part describes the manner in which the email address or addresses were acquired by the sender:

   individual
      A special token used for individually addressed non-bulk mail. The
      individual type SHALL NOT be used to solicit or prospect for new
      business or contributions.
   autoresponse
      Automated response to the sender of a per/individual message.
   customer
      Bulk mail to addressees who are customers of this sender and have
      agreed to receive this class of mail from this sender.
   optout
      Bulk mail to addressees who have not asked for this mailing from
      this sender.
   optin
      Bulk mail to addressees who have asked for this mailing from this
      sender.
   confirmed
      Bulk mail to addressees who have confirmed by return mail that
      they have asked for this mailing from this sender.
   The following examples are offered to illustrate the use of MPC
   codes:
       per/individual     An individual person on behalf of herself.
       net/individual     A non-bulk message from a network provider.
       pol/confirmed      A bulk message from a politician, addressed
                          using a list of confirmed subscribers.
       com/optout         A bulk message from a commercial business,
                          addressed to a list from unspecified sources.
       mpc/individual     A message from one system administrator to
                          another system administrator about an MPC
                          policy violation. All systems MUST accept and
                          deliver all messages with this MPC code.

5. Security Considerations

This specification addresses authentication issues not addressed by SMTP [RFC2821]. In particular, AMTP employs TLS [RFC2246] with X.509 certificates [RFC2459] to authenticate MTAs involved in a mail transfer transaction.

This specification addresses the issue of Unsolicited Bulk Email (UBE) by providing coded tokens to identify mailing handling policies. It is possible for a sender to use a trusted MTA to transmit false tokens and thereby subvert an MTA's policies.

This specification does not claim to eliminate UBE entirely. Some amount of diligence on the part of system administrators will always be necessary to prevent abuse.

This specification allows for a system operator to designate certain connections as private network connections using self-signed certificates. It is possible for a user on such a private network to abuse the trust of the system by sending bulk mail encoded as personally-addressed mail.

It is possible for a malicious party to provide false information to a Certificate Authority or otherwise contrive to present a fraudulent certificate.

This specification does not address the issue of authenticating senders. It is possible for a sender to transmit false headers through a trusted MTA and thereby assume a false identity.

Because this specification relies on SMTP, TLS, and X.509, any security issues with those protocols may also apply to AMTP.

6. IANA Considerations

In the future, a canonical list of MPC codes may be maintained by the Internet Assigned Numbers Authority (IANA) in accordance with their policies [RFC3232].

Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
   [RFC2246]  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A.
              and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246,
              January 1999.
   [RFC2459]  Housley, R., Ford, W., Polk, T. and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and CRL
              Profile", RFC 2459, January 1999.
   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

Informative References

   [CCITT.X509.1988]
              International Telephone and Telegraph Consultative
              Committee, "Information Technology - Open Systems
              Interconnection - The Directory: Authentication
              Framework", CCITT Recommendation X.509, November 1988.
   [RFC2234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.
   [RFC2693]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
              B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
              September 1999.
   [RFC3232]  Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
              an On-line Database", RFC 3232, January 2002.

Author's Address

   William E. Weinman
   bw.org
   908 Audelia Road
   Ste. 200, PMB 335
   Richardson, TX  75081
   US

EMail: amtp-wew@bearnet.com URI: http://amtp.bw.org/

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003). 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 assignees.

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.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.