Network Working Group W. Weinman Internet-Draft bw.org Expires: March 28, 2004 September 28, 2003 AMTP - Authenticated Mail Transfer Protocol draft-weinman-amtp-01.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 March 28, 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 March 28, 2004 [Page 1] Internet-Draft AMTP September 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 Normative References . . . . . . . . . . . . . . . . . . . . 23 Informative References . . . . . . . . . . . . . . . . . . . 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . 24 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 26 B.1 draft-weinman-amtp-01 . . . . . . . . . . . . . . . . . . . 26 B.2 draft-weinman-amtp-00 . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . 28 Weinman Expires March 28, 2004 [Page 2] Internet-Draft AMTP September 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 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 fixed, recipient-based, and/ or sender-based policies. Authentication provides the receiving MTA the ability to 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. 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 March 28, 2004 [Page 3] Internet-Draft AMTP September 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. 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 March 28, 2004 [Page 4] Internet-Draft AMTP September 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. Before a set of policies can be enforced, 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 define and advertise their policies. Weinman Expires March 28, 2004 [Page 5] Internet-Draft AMTP September 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 March 28, 2004 [Page 6] Internet-Draft AMTP September 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 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 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 MAY establish different criteria for use with private network connections. For example, an ISP may act as a private CA to provide X.509 certificates for use by its customers from dynamically-allocated address space, or a corporate mail system administrator may act as a private CA to provide X.509 certificates for use by traveling users or users in remote locations. 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). Weinman Expires March 28, 2004 [Page 7] Internet-Draft AMTP September 2003 4.3.1 SRV RRs When a client MTA delivers mail to a server MTA, it MUST perform a 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 Weinman Expires March 28, 2004 [Page 8] Internet-Draft AMTP September 2003 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 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-roll / "*") "/" (mpc-class / "*") mpc-roll = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") mpc-class = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") An asterisk ("*") may be used as a wildcard in place of mpc-roll or mpc-class to match all legitimate values. Specific values for mpc-roll 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. 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 an EHLO argument that did not agree with the presented certificate, or the certificate was invalid, or some other authentication-related failure occurred. Weinman Expires March 28, 2004 [Page 9] Internet-Draft AMTP September 2003 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 (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. Weinman Expires March 28, 2004 [Page 10] Internet-Draft AMTP September 2003 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 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 Weinman Expires March 28, 2004 [Page 11] Internet-Draft AMTP September 2003 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-roll "/" mpc-class mpc-roll = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") mpc-class = (ALPHA / DIGIT) *(ALPHA / DIGIT / "-") The mpc-roll part describes the roll of the sender of the mail message. The complete list of mpc-roll values are defined here: per The email message was sent by an individual person in a non-commercial context. The "per" mpc-roll value MUST NOT be used to solicit or prospect for new business or donations. Weinman Expires March 28, 2004 [Page 12] Internet-Draft AMTP September 2003 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-roll 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-roll 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-roll 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", or another mpc-roll with the mpc-class of "individual", the mpc-roll MUST NOT be "per". The "per" mpc-class MUST NOT be used to solicit or prospect for new business or donations. Weinman Expires March 28, 2004 [Page 13] Internet-Draft AMTP September 2003 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, addressed to a list from a third party, or any source other than direct subscription by the addressees. Weinman Expires March 28, 2004 [Page 14] Internet-Draft AMTP September 2003 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 March 28, 2004 [Page 15] Internet-Draft AMTP September 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 March 28, 2004 [Page 16] Internet-Draft AMTP September 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 MTAs and ultimately to the recipient(s) addressed in the message. In order to satisfy the requirements of AMTP, certain requirements are necessary on the part of the MUA. 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 "rolls" (or "personalities"), the MUA configuration process should allow each roll to select an MPC value to be associated with that roll. 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) Weinman Expires March 28, 2004 [Page 17] Internet-Draft AMTP September 2003 or an Autoresponder (Section 6.4) MUST also follow the requirements 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 an MUA 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 March 28, 2004 [Page 18] Internet-Draft AMTP September 2003 7. Private Network Considerations This specification requires strong authentication of a client MTA before it can deliver mail to a server MTA. There are circumstances where a network operator may need to accept mail from client MTAs that are not easily authenticated with the methods provided by AMTP. In these circumstances, a server MTA MAY establish a private network connection. A private network connection is established by authenticating a connection using an X.509 certificate signed by a private CA. A private CA is recognized by the transaction partners in the private network, and MUST NOT be recognized by any MTA outside of the private network. When using a private network connection, a server MTA MAY relax some restrictions otherwise required by AMTP, in order to accommodate a more flexible network topology in a controlled environment. For example, an ISP that provides consumer Internet access may use dynamically assigned IP addresses, each with a fixed PTR RR. This would mean that a client MTA (in this case, an MUA) would not have a PTR RR that matches the X.509 certificate subject. The ISP could resolve this discrepancy by establishing a private CA to issue X.509 certificates to its customers. The ISP could then provide AMTP service to its customers over private network connections. A private network connection SHOULD also employ user authentication. See Section 8 for important security considerations. The following relaxed restrictions MAY be applied to a private network connection. o A private network connection MAY use a port number other than xxx. (Section 4.1) o A server 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 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. While many of the restrictions in this document may be relaxed for a private network connection, there are some important additional restrictions. Weinman Expires March 28, 2004 [Page 19] Internet-Draft AMTP September 2003 o A client MUST NOT use DNS SRV RRs to determine the address of a server for a private network connection. Weinman Expires March 28, 2004 [Page 20] Internet-Draft AMTP September 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 March 28, 2004 [Page 21] Internet-Draft AMTP September 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 March 28, 2004 [Page 22] Internet-Draft AMTP September 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 March 28, 2004 [Page 23] Internet-Draft AMTP September 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 March 28, 2004 [Page 24] Internet-Draft AMTP September 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 Jos Hulzink Chris Paul, William Rose, Stephen Samuel, Brian Stafford, 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 March 28, 2004 [Page 25] Internet-Draft AMTP September 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-01 Released 2003-09-24. o Added section: "Private Network Considerations" o Updated MPC syntax. A few clarifications, and changed "entity" to "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 gramatical and typographical changes. Weinman Expires March 28, 2004 [Page 26] Internet-Draft AMTP September 2003 B.2 draft-weinman-amtp-00 Released 2003-08-19. Original version. Weinman Expires March 28, 2004 [Page 27] Internet-Draft AMTP September 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 March 28, 2004 [Page 28] Internet-Draft AMTP September 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 March 28, 2004 [Page 29]