Network Working Group W. Weinman Internet-Draft bw.org Expires: April 22, 2004 October 23, 2003 AMTP - Authenticated Mail Transfer Protocol draft-weinman-amtp-02.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 April 22, 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 April 22, 2004 [Page 1] Internet-Draft AMTP October 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. Operational Specification . . . . . . . . . . . . . . . . . 7 4.1 Connection Requirements . . . . . . . . . . . . . . . . . . 7 4.2 X.509 Certificate Requirements . . . . . . . . . . . . . . . 7 4.3 DNS Requirements . . . . . . . . . . . . . . . . . . . . . . 7 4.3.1 SRV RRs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.2 IN-ADDR.ARPA zone (Reverse DNS) . . . . . . . . . . . . . . 8 4.4 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 8 4.4.1 Hello Command (HELO) . . . . . . . . . . . . . . . . . . . . 8 4.4.2 Extended Hello Command (EHLO) . . . . . . . . . . . . . . . 8 4.4.3 Mail Policy Code (MPC) Parameter . . . . . . . . . . . . . . 10 4.4.4 MPC Value Propagation . . . . . . . . . . . . . . . . . . . 11 4.5 MPC Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. MTA Requirements . . . . . . . . . . . . . . . . . . . . . . 16 5.1 Unauthorized Relay Prevention . . . . . . . . . . . . . . . 16 5.2 Rewriting MPC Values . . . . . . . . . . . . . . . . . . . . 16 6. MUA Requirements . . . . . . . . . . . . . . . . . . . . . . 17 6.1 MPC settings . . . . . . . . . . . . . . . . . . . . . . . . 17 6.2 Email Service Providers . . . . . . . . . . . . . . . . . . 17 6.3 List Delivery Agents . . . . . . . . . . . . . . . . . . . . 18 6.4 Autoresponders . . . . . . . . . . . . . . . . . . . . . . . 18 7. Private Network Considerations . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21 Normative References . . . . . . . . . . . . . . . . . . . . 22 Informative References . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . 23 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 25 B.1 draft-weinman-amtp-02 . . . . . . . . . . . . . . . . . . . 25 B.2 draft-weinman-amtp-01 . . . . . . . . . . . . . . . . . . . 25 B.3 draft-weinman-amtp-00 . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . 27 Weinman Expires April 22, 2004 [Page 2] Internet-Draft AMTP October 2003 1. Introduction Internet electronic mail is becoming expensive to receive, process, deliver, and use 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 mail policies. Authenticated Mail Transfer Protocol (AMTP) is derivative of SMTP [RFC2821] and is intended as a replacement of SMTP for Internet electronic mail transfer. AMTP uses TLS [RFC2246] with X.509 certificates [RFC3280] to authenticate MTAs, and introduces a Mail Policy Code that allows MTAs to advertise and enforce policies. A server can decide whether to accept a particular message based on fixed, recipient-based, and/or sender-based policies. Authentication provides the receiving MTA the ability to enforce its policies, and/ or deny access to sending MTAs 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 using AMTP. MTA Mail Transfer Agent. A program that exchanges mail with another program. An MTA may be a client (sender) or a server (receiver). MUA Mail User Agent. A subclass of Mail Transfer Agent (MTA) that usually includes a user interface. An MUA may be a desktop application or another program that acts as an endpoint (originator or destination) for mail messages. Weinman Expires April 22, 2004 [Page 3] Internet-Draft AMTP October 2003 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. Private network connection A connection authenticated with a certificate signed by a private CA is considered a private network connection (see Section 7). Public network connection Any connection that does not qualify as a private network connection. Private CA A certificate authority (CA) that is exclusively recognized by a set of trusted MTAs in a private network. A CA that is trusted outside of the private network MUST NOT be trusted as a private CA. Public CA Usually a trusted third party, a public certificate authority CA is any CA that does not qualify as a private CA. Relay As a verb, the retransmission of a message to another MTA for delivery. As a noun, an MTA that performs a relaying function. Weinman Expires April 22, 2004 [Page 4] Internet-Draft AMTP October 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 DNS Block Lists, 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 establish and enforce policies. Codification There is no universally recognized code of behavior. If you ask two people for a definition of mail abuse, you'll get three answers. Before a set of policies can be enforced, common terminology must be defined that can be understood by all the parties involved. Clear and concise codification of policies will allow message senders and system operators to advertise and enforce their policies. There has been a great deal of discussion about the advisability of replacing SMTP. Good arguments have been presented both for and against. Eventually this author came to the conclusion that the benefits of a replacement can be realized while mitigating the costs. By remaining as similar to SMTP as possible, AMTP protects investments in existing code. By operating on a different TCP port, AMTP provides for a smooth transition, and eventually a clean break, from SMTP. Weinman Expires April 22, 2004 [Page 5] Internet-Draft AMTP October 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 most recent 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 authenticate the connection between the client and server MTAs. The client MUST present a valid X.509 certificate [RFC3280] signed by a trusted Certificate Authority (CA) in order to begin a transaction. This requirement provides the server's system operator with confidence that the client's system operator can be identified and contacted in the event of a policy violation. It also provides the server a reliable method of identifying a non-compliant client so that the server may refuse its connections. 3.2 Codification A Mail Policy Code (MPC) is used to codify mailing policies. A client MTA provides an MPC value for a particular message as part of its envelope. Conversely, a server allows or disallows messages based on the provided MPC value. A server MTA may advertise MPC values that it accepts and/or denies. The MPC specification (Section 4.5) strives to be policy-neutral while allowing system operators to establish policies that work for their systems and their users. The goal of MPC is to allow a server MTA to establish its own policies, and obey the policies of the other MTAs that it may exchange messages with. Weinman Expires April 22, 2004 [Page 6] Internet-Draft AMTP October 2003 4. Operational Specification This section provides the specification of the AMTP protocol and its requirements. 4.1 Connection Requirements A client MTA makes a connection to a server MTA on system port number xxx using TCP. An alternative user port number outside of the 0-1024 system port range MAY be used for a private network connection (Section 7). A server MTA MUST NOT accept public network connections on any alternative port number. 4.2 X.509 Certificate Requirements The AMTP protocol REQUIRES that each connection be established using TLS [RFC2246] and that the client MTA MUST present a valid X.509 Certificate [RFC3280] to the server. 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 presented by the client MTA MUST have a fully-qualified domain name in the Common Name (CN) field, and that fully-qualified domain name MUST match 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. Different criteria apply for use with private network connections. See Section 7 for private network considerations and Section 8 for security considerations. 4.3 DNS Requirements The requirements in this section apply to public network connections. Sessions established using private network connections are not subject to these DNS requirements (Section 7, Private network considerations). 4.3.1 SRV RRs When a client MTA delivers mail to a server MTA, it MUST perform a Weinman Expires April 22, 2004 [Page 7] Internet-Draft AMTP October 2003 DNS query for an SRV RR using the host part of the envelope recipient address. The server MTA SHALL be determined according to the procedures specified in DNS SRV RR [RFC2782]. This requirement replaces the use of A or MX records in SMTP. In order to receive mail addressed to a given host name, the host DNS zone MUST include one or more SRV records [RFC2782] that meet the following requirements: o The Service field is "amtp". o The Proto field is "tcp". o The Name field matches the DNS name used in the host part of the message envelope. o A server MTA that receives mail for a given host name MUST be specified in a Target field of an SRV record associated with that host name. 4.3.2 IN-ADDR.ARPA zone (Reverse DNS) Any client MTA that connects to a server MTA MUST have a DNS PTR RR in the IN-ADDR.ARPA zone corresponding to the IP address used to initiate the connection. The PTR RR MUST match the Subject field of the client MTA's X.509 certificate, and MUST also match the host name in the EHLO argument that the client MTA presents to the server MTA. 4.4 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.4.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 syntax to support the MPC semantics. 4.4.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. A server MUST issue a response code 504 if the EHLO argument does not agree with the provided certificate. An MUA operating with a Weinman Expires April 22, 2004 [Page 8] Internet-Draft AMTP October 2003 certificate from a private CA MUST ensure that the EHLO argument matches the CA subject. 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 (Mail Policy Code, see Section 4.5) declaration line as part of its EHLO reply. The syntax of an MPC declaration line is: mpc-ehlo-line = "MPC" 1*(SP mpc-declaration) mpc-declaration = mpc-keyword "=" mpc-value mpc-keyword = "ALLOW" / "DENY" mpc-value = (mpc-role / "*") "/" (mpc-class / "*") mpc-role = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") mpc-class = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") An asterisk ("*") may be used as a wildcard in place of mpc-role or mpc-class to match all legitimate values. Specific values for mpc-role and mpc-class are specified in Section 4.5. MPC declarations SHALL be evaluated in the order presented. If the first mpc-keyword is ALLOW, a preceding declaration of "DENY */*" is implied; conversely, if the first mpc-keyword is DENY, a preceding permission line of "ALLOW */*" is implied. If there is no MPC declaration in the EHLO reply, "ALLOW */*" is implied and the client may proceed. If the MPC value of message to be delivered matches any DENY declaration in the EHLO reply, the client MUST issue a QUIT command and refrain from retrying the message, and the client SHOULD deliver a corresponding bounce message to the sender. 4.4.2.1 Examples Examples of possible AMTP EHLO responses are presented here. C: EHLO dastardly.example.org S: 504 Authentication failed The above connection did not authenticate. The client may have issued Weinman Expires April 22, 2004 [Page 9] Internet-Draft AMTP October 2003 an EHLO argument that did not agree with the presented certificate, or the certificate was invalid, or some other authentication-related failure occurred. C: EHLO amtp.example.org S: 250-Greetings and felicitations S: 250-MPC DENY com/* ALLOW com/individual ALLOW com/confirmed S: 250-PIPELINING S: 250 8BITMIME The above server allows only confirmed or individual mail from commercial senders; all mail from non-commercial senders is allowed. 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 mail. 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.4.3 Mail Policy Code (MPC) Parameter The MPC parameter is provided with the MAIL command to bind a Mail Policy Code (MPC) with the message being transferred as part its envelope. The client MUST issue the MPC parameter with the MAIL command. The client MUST provide exactly one MPC parameter per transaction. The MPC parameter is provided as a "Mail-parameter" according to sections 4.1.1.2 an 4.1.2 of [RFC2821]. The syntax of the MPC parameter is: "MPC=" mpc-value The mpc-value is defined in Section 4.5. The server MAY reject mail based on the MPC parameter even when it does not publish a corresponding MPC declaration in the EHLO response Weinman Expires April 22, 2004 [Page 10] Internet-Draft AMTP October 2003 (Section 4.4.2). The MPC parameter may be used to implement policies based on specific recipients, senders, or combinations of the two. The server MAY reject mail based on the MPC parameter after the MAIL command or after a particular RCPT command. The following result codes SHALL be used to accept or reject mail based on the MPC parameter: 250 Okay 451 MPC temporary failure, try again later 550 MPC policy violation Examples of MAIL and RCPT commands: C: MAIL FROM: MPC=individual/confirmed S: 250 Okay C: RCPT TO: S: 250 Okay The above represents a discussion list message sent to one address at the server. It was accepted. C: MAIL FROM: MPC=pol/optout S: 550 MPC policy violation C: QUIT S: 221 amtp.example.com -- Goodbye. The above server does not accept this MPC from this client. C: MAIL FROM: MPC=com/optin S: 250 Okay C: RCPT TO: S: 550 MPC policy violation C: RCPT TO: S: 550 MPC policy violation C: RCPT TO: S: 550 MPC policy violation C: RCPT TO: S: 250 Okay C: DATA S: 354 Start mail input. The above server has different users with different mail policies. 4.4.4 MPC Value Propagation When a server delivers a message to a user mail spool, or other destination, it must preserve the MPC value with the envelope of the Weinman Expires April 22, 2004 [Page 11] Internet-Draft AMTP October 2003 message. When a server delivers a message to a user's mail spool, it MUST insert an MPC header line in the message headers [RFC2822]. Likewise, When a server relays a message to another server using another protocol, it MUST insert an MPC header line in the message headers. When inserting the MPC header line, the server MUST first search the message header for a pre-existing MPC header line. If a pre-existing MPC header line is found in the message header, the server MUST NOT relay or deliver the message. A server MUST NOT rewrite an MPC value. The syntax of the mpc-header line is: "MPC:" SP mpc-value CRLF The mpc-value is defined in Section 4.5. The "MPC:" token SHALL be considered case-insensitive. When a server relays a message to another AMTP server, it MUST NOT insert an MPC header line in the message headers. Instead, the sending MTA (now acting as a client) MUST propagate the MPC value by using the mpc-parameter as specified in Section 4.4.3. 4.5 MPC Syntax A Mail Policy Code (MPC) is used for the purpose of establishing and enforcing server policy. It is used in two contexts: as a preemptory declaration of policy by a server MTA (Section 4.4.2); and as a policy classification of an individual message (Section 4.4.3). The purpose of MPC is to normalize and codify mail policy, not to proscribe any particular class of mail. In particular, the association of messages with MPC parameters does not "outlaw" any mail, it simply requires that each mail message identify itself in certain terms. Each MPC value consists of two parts separated by a slash (ASCII 0x2F): mpc-value = mpc-role "/" mpc-class mpc-role = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") mpc-class = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") The mpc-role part describes the role of the sender of the mail message. The complete list of mpc-role values are defined here: Weinman Expires April 22, 2004 [Page 12] Internet-Draft AMTP October 2003 per The email message was sent by an individual person in a non-commercial context. The "per" mpc-role value MUST 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, or a person representing a commercial entity. ngo The email message was sent on behalf of a non-governmental, or non-profit, organization, or a person representing 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" mpc-role value MUST NOT be used to solicit or prospect for new business or donations. gov The email message was sent on behalf of a government, or a person representing a government. 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". The "mpc" mpc-role value, when combined with any mpc-class other than "individual", MUST be treated as invalid. The mpc-class part describes the manner in which the recipient email address (or addresses) was acquired by the sender: individual A special token used for individually addressed non-bulk mail. The individual type MUST NOT be used to solicit or prospect for new business or contributions. It is understood that the mpc-role part may not always be clear when mpc-class is "individual". In the case where a message may be part "per/individual" and part "com/individual", "ngo/individual", Weinman Expires April 22, 2004 [Page 13] Internet-Draft AMTP October 2003 or another mpc-role with the mpc-class of "individual", the mpc-role MUST NOT be "per". The "per" mpc-class MUST NOT be used to solicit or prospect for new business or donations. autoresponse Automated response to the sender of a per/individual message, or any message triggered by a user action. The "autoresponse" mpc-class MUST be used for all automated messages triggered by user action, including messages confirming transactions or other user actions and messages requesting confirmation from a user (see Section 6.4). customer Bulk mail to addressees who are customers of this sender and have agreed to receive this mailing 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. The "optin" mpc-class MUST NOT be used when there is a possibility that a mailing may be sent to one or more addressees that did not request the mailing. confirmed Bulk mail to addressees who have confirmed by return mail that they have asked for this mailing from this sender. The "confirmed" mpc-class MUST NOT be used when there is a possibility that a mailing may be sent to one or more addressees that did not confirm their request for the mailing by return-email. The following examples are offered to illustrate the use of these MPC values: 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, Weinman Expires April 22, 2004 [Page 14] Internet-Draft AMTP October 2003 addressed to a list from a third party, or any source other than direct subscription by the addressees. 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 value. Weinman Expires April 22, 2004 [Page 15] Internet-Draft AMTP October 2003 5. MTA Requirements When exchanging mail over a public network connection, every MTA MUST conform to a common set of operating practices for the purpose of preserving the security of the public email infrastructure. 5.1 Unauthorized Relay Prevention Each message transmitted using AMTP over a public network connection MUST NOT be relayed over another public network connection. Relay deliveries to end users or intermediate mail servers MUST use private network connections. 5.2 Rewriting MPC Values An MTA MUST NOT rewrite MPC values. When an MTA determines that an MPC value is incorrect, invalid, or otherwise unacceptable, it MUST NOT relay or deliver the message. Weinman Expires April 22, 2004 [Page 16] Internet-Draft AMTP October 2003 6. MUA Requirements A Mail User Agent (MUA) is a process or service that originates messages that are then transmitted to an MTA for delivery to one or more destination addresses. This section describes considerations and requirements that an MUA must satisfy to be compliant with the AMTP protocol. 6.1 MPC settings An MUA MUST make provision for assignment of an MPC value that will be used when transmitting messages to a server MTA. The MUA SHOULD bind a single MPC value to each email address configured for use as an envelope sender or "From:" header value. An MUA should provide a configuration option, along with the configuration of sender email addresses, that allows the user (or email administrator) to select from a list of applicable MPC values during the configuration process. Once set, this value should rarely require updating. In the case of an MUA that allows for multiple sender "roles" (or "personalities"), the MUA configuration process should allow each role to select an MPC value to be associated with that role. The configuration process MUST NOT allow MPC values that are not explicitly enumerated in this specification. The configured MPC setting MUST be provided as the mpc-argument to the MAIL FROM: command during transmission of each associated message. A conforming MUA MUST NOT use MPC values that are not explicitly enumerated in this specification when transferring mail to an MTA. 6.2 Email Service Providers Email Service Providers (ESPs) provide third-party email services to individuals and companies. Such services may include email user services (e.g., "web mail" services), List Delivery Agents (LDAs, Section 6.3), Autoresponders (Section 6.4), or other email-related services. ESP services that allow a user to compose and send mail to arbitrary recipients act as an MUA and therefore MUST adhere to the requirements in Section 6.1. ESP services that provide the functionality of an LDA (Section 6.3) or an Autoresponder (Section 6.4) MUST also follow the requirements Weinman Expires April 22, 2004 [Page 17] Internet-Draft AMTP October 2003 in this specification for those services. 6.3 List Delivery Agents A List Delivery Agent (LDA) is a service that sends messages to a list of more than one recipient, not including any addresses used for the purpose of administering the LDA. An LDA may receive messages from an MUA, or may generate its own messages or receive them from another process or service. An LDA that receives messages from a public network MUST NOT accept messages with any mpc-class value other than "individual". When sending messages to more than one recipient, not including any addresses used for the purpose of administering the LDA, an LDA MUST use one of the following mpc-class values: optout optin confirmed customer 6.4 Autoresponders An autoresponder is a service that responds to an email message, or other user action, by sending a message back to the sender or user who initiated it. Such services are often used to announce that a recipient is unavailable (out of the office, on vacation, etc.), or to provide informational messages (technical documents, mailing list past issues, advertisements, etc.). An autoresponder MUST NOT respond to messages with any mpc-class value other than "individual". An autoresponder MUST NOT respond with more than one message and MUST NOT respond to more than one recipient address, not including any addresses used for the purpose of administering the service. Any message triggered by a user action, including but not limited to out-of-office messages, vacation messages, purchase confirmations, subscription confirmations, etc.,MUST use the mpc-class value, "autoresponder". Messages sent by an MTA notifying a sender of trouble related to the delivery of a message (bounce messages) MUST always use the MPC value, "net/autoresponse". Weinman Expires April 22, 2004 [Page 18] Internet-Draft AMTP October 2003 7. Private Network Considerations This specification requires strong authentication of a client MTA before it can deliver mail to a server MTA. For circumstances where a network operator may need to accept mail from client MTAs that do not meet the criteria for a public network connection (Section 4.1), a private network connection may be used. A private network connection is established by authenticating a connection with an X.509 certificate signed by a private CA. A private CA is recognized by the transaction partners participating in the private network, and MUST NOT be recognized by any MTA outside of the private network. For example, an ISP that provides consumer Internet access over dynamically allocated IP addresses may establish a private network for customer access to its mail servers; or a corporate IT department may issue certificates to its sales force, so that they may use the company's mail servers while traveling. In order to accommodate more flexible network topologies in controlled environments, the following considerations apply to private network connections: o A private network connection SHOULD employ user authentication in addition to the X.509 certificate used for host authentication. See Section 8 for important security considerations. o A server MAY require that an X.509 certificate subject match another authentication token, for example, a user name provided with RFC-2554 authentication, to help prevent abuse of its certificates. o A private network connection MAY use a port number other than xxx. (Section 4.1) o A server on a private network connection MAY accept a certificate subject and/or an EHLO argument without a matching DNS PTR RR. (Section 4.3.2, Section 4.2, Section 4.4.2) o A client MUST NOT use DNS SRV RRs to determine the address of a server for a private network connection. Weinman Expires April 22, 2004 [Page 19] Internet-Draft AMTP October 2003 8. Security Considerations This specification addresses authentication issues not addressed by SMTP [RFC2821]. In particular, AMTP employs TLS [RFC2246] with X.509 certificates [RFC3280] 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 mail 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. AMTP requires strong host authentication that can be used by a server to block further connections from a client that is no longer trusted, but AMTP does not claim to provide a mechanism to prevent the initial abuse. Some amount of diligence on the part of system administrators will always be necessary to prevent abuse. The authentication and codification provisions aim to make such diligence more effective. This specification allows for a system operator to designate certain connections as private network connections using certificates signed by a private CA (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 also possible that a user with a privately-signed certificate may loose control over that certificate or otherwise make it available to a third party. If a server accepts a private network connection, the server SHOULD require additional client authentication, such as that provided by the SMTP Authentication Extension [RFC2554], to mitigate any damage from lost or stolen X.509 certificates. It is possible for a malicious party to provide false information to a Certificate Authority or otherwise contrive to acquire or 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 April 22, 2004 [Page 20] Internet-Draft AMTP October 2003 9. IANA Considerations This protocol requires a system port number, to be determined by the Internet Assigned Numbers Authority (IANA). This specification calls for registration of the email message header, "MPC:". This specification calls for a new IANA registry for the registration of MPC values. Weinman Expires April 22, 2004 [Page 21] Internet-Draft AMTP October 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. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. Weinman Expires April 22, 2004 [Page 22] Internet-Draft AMTP October 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. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [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 April 22, 2004 [Page 23] Internet-Draft AMTP October 2003 Appendix A. Acknowledgements The author gratefully acknowledges the contributions of the following people: Sven Anders, Matthew Parke Bostrom, Martin R. Calsyn, Peter Conrad, Dave Crocker, Ray Everett-Church, Daniel Foesch, Edward Ned Harvey, Ken Hirsch, Jos Hulzink, Phil Miller, Chris Paul, William Rose, Stephen Samuel, Yakov Shafranovich, Brian Stafford, Markus Stumpf, Thomas Tuttle, and any others who have written to me about AMTP. Thank you for your indispensable assistance. If you have made a contribution to this document and your name is not listed, please contact the author so that the omission may be corrected before this draft is submitted for RFC consideration. Weinman Expires April 22, 2004 [Page 24] Internet-Draft AMTP October 2003 Appendix B. Revision History This section provides a running log of the changes made to this draft and will be removed when the document is finalized. B.1 draft-weinman-amtp-02 Released 2003-10-23. o Rewrote a lot of the "Private Network Considerations" section, mostly for clarity. o Clarified "Connection Requirements" section. o Expanded "Autoresponders" section. o Updated and clarified some of the language in the MPC definitions. o Updated and clarified the X.509 section to clarify the use of certificates in private networks. o Updated and clarified the "DNS Requirements" section. o Updated and added some prose to "Rationale" section. o Updated Introduction. o Updated Terminology to clarify private vs. public distinctions. o Renumbered and Reorganized some sections. o Renamed "Overall Operation" to "Operational Specification" o Globally changed "roll" to "role". o Added language clarifying client behavior in response to MPC declarations in the EHLO reply. o Even more grammatical and typographical upgrades! B.2 draft-weinman-amtp-01 Released 2003-09-28. o Added section: "Private Network Considerations" o Updated MPC syntax. A few clarifications, and changed "entity" to Weinman Expires April 22, 2004 [Page 25] Internet-Draft AMTP October 2003 "roll". o Added section: "MPC Value Propagation" o Updated EHLO response to be more streamlined for non-PIPELINING clients. o Changed MPC command to a parameter of the MAIL command, to be more streamlined for non-PIPELINING clients. o Added better examples of mail transactions. o Servers are no longer required to present an X.509 certificate to the client. Only the client must have a certificate. o Updated X.509 Certificate Requirements to clarify provisions for private networks. o Replaced references to RFC-2459 with RFC-3280. o Added section: "MUA Requirements" o Added section: "MTA Requirements" o Added section: "Connection Requirements" o Added section: "DNS Requirements" o Added IANA request for the email message header, "MPC:" o Per the request of IANA, the system port request was added to the "IANA Considerations" section. o Myriad grammatical and typographical changes. B.3 draft-weinman-amtp-00 Released 2003-08-19. Original version. Weinman Expires April 22, 2004 [Page 26] Internet-Draft AMTP October 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 April 22, 2004 [Page 27] Internet-Draft AMTP October 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 April 22, 2004 [Page 28]