Network Working Group W. Weinman Internet-Draft bw.org Expires: February 17, 2004 August 19, 2003 AMTP - Authenticated Mail Transfer Protocol draft-weinman-amtp-00.txt 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). Weinman Expires February 17, 2004 [Page 1] Internet-Draft AMTP August 2003 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 Weinman Expires February 17, 2004 [Page 2] Internet-Draft AMTP August 2003 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. Weinman Expires February 17, 2004 [Page 3] Internet-Draft AMTP August 2003 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. Weinman Expires February 17, 2004 [Page 4] Internet-Draft AMTP August 2003 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. Weinman Expires February 17, 2004 [Page 5] Internet-Draft AMTP August 2003 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. Weinman Expires February 17, 2004 [Page 6] Internet-Draft AMTP August 2003 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 Weinman Expires February 17, 2004 [Page 7] Internet-Draft AMTP August 2003 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 Weinman Expires February 17, 2004 [Page 8] Internet-Draft AMTP August 2003 The above server does not accept any optout mail. 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 Weinman Expires February 17, 2004 [Page 9] Internet-Draft AMTP August 2003 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. Weinman Expires February 17, 2004 [Page 10] Internet-Draft AMTP August 2003 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 Weinman Expires February 17, 2004 [Page 11] Internet-Draft AMTP August 2003 another system administrator about an MPC policy violation. All systems MUST accept and deliver all messages with this MPC code. Weinman Expires February 17, 2004 [Page 12] Internet-Draft AMTP August 2003 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. Weinman Expires February 17, 2004 [Page 13] Internet-Draft AMTP August 2003 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]. Weinman Expires February 17, 2004 [Page 14] Internet-Draft AMTP August 2003 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. Weinman Expires February 17, 2004 [Page 15] Internet-Draft AMTP August 2003 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/ Weinman Expires February 17, 2004 [Page 16] Internet-Draft AMTP August 2003 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 Weinman Expires February 17, 2004 [Page 17] Internet-Draft AMTP August 2003 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. Weinman Expires February 17, 2004 [Page 18]