Internet DRAFT - draft-weinman-amtp
draft-weinman-amtp
Network Working Group W. Weinman
Internet-Draft bw.org
Expires: October 23, 2004 April 24, 2004
AMTP - Authenticated Mail Transfer Protocol
draft-weinman-amtp-03.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 October 23, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). 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 October 23, 2004 [Page 1]
Internet-Draft AMTP April 2004
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-03 . . . . . . . . . . . . . . . . . . . 25
B.2 draft-weinman-amtp-02 . . . . . . . . . . . . . . . . . . . 25
B.3 draft-weinman-amtp-01 . . . . . . . . . . . . . . . . . . . 26
B.4 draft-weinman-amtp-00 . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . 28
Weinman Expires October 23, 2004 [Page 2]
Internet-Draft AMTP April 2004
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 to replace 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/or enforce policies. A server can
decide whether to accept a particular message based on any
combination of fixed, recipient-based, or sender-based policies.
Authentication provides the receiving MTA the ability to enforce its
policies, and/or deny access to sending MTAs based on any number of
criteria.
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 October 23, 2004 [Page 3]
Internet-Draft AMTP April 2004
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 client 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 October 23, 2004 [Page 4]
Internet-Draft AMTP April 2004
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 at least
three different 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 using mutually understood terminology.
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 can run in parallel with SMTP, providing for a smooth
transition, and eventually a clean break, from SMTP.
Weinman Expires October 23, 2004 [Page 5]
Internet-Draft AMTP April 2004
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. Both client and server MUST present valid X.509
certificates [RFC3280], each 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 clients so that the server may refuse connections from
those it deems non-compliant.
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 October 23, 2004 [Page 6]
Internet-Draft AMTP April 2004
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 both client and server MTAs MUST present valid
X.509 Certificates [RFC3280] to each other. 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 October 23, 2004 [Page 7]
Internet-Draft AMTP April 2004
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 client's provided certificate. An MUA
Weinman Expires October 23, 2004 [Page 8]
Internet-Draft AMTP April 2004
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-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 October 23, 2004 [Page 9]
Internet-Draft AMTP April 2004
an EHLO argument that did not agree with the certificate it
presented, 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 October 23, 2004 [Page 10]
Internet-Draft AMTP April 2004
(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:<CATS-L@list.example.com> MPC=individual/confirmed
S: 250 Okay
C: RCPT TO:<bertha@example.com>
S: 250 Okay
The above represents a discussion list message sent to one address at
the server. It was accepted.
C: MAIL FROM:<vote-for-bob@list.example.gov> 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:<hotdeals@list.example.biz> MPC=com/optin
S: 250 Okay
C: RCPT TO:<john@beatles.example.com>
S: 550 MPC policy violation
C: RCPT TO:<paul@beatles.example.com>
S: 550 MPC policy violation
C: RCPT TO:<george@beatles.example.com>
S: 550 MPC policy violation
C: RCPT TO:<ringo@beatles.example.com>
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 October 23, 2004 [Page 11]
Internet-Draft AMTP April 2004
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 / "-")
A server MTA MUST NOT accept or deliver any message with an MPC value
with any component not explicitly defined in this section.
Weinman Expires October 23, 2004 [Page 12]
Internet-Draft AMTP April 2004
The mpc-role part describes the role of the sender of the mail
message. The complete list of mpc-role values are defined here:
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.
Weinman Expires October 23, 2004 [Page 13]
Internet-Draft AMTP April 2004
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",
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
Weinman Expires October 23, 2004 [Page 14]
Internet-Draft AMTP April 2004
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.
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 October 23, 2004 [Page 15]
Internet-Draft AMTP April 2004
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 October 23, 2004 [Page 16]
Internet-Draft AMTP April 2004
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 October 23, 2004 [Page 17]
Internet-Draft AMTP April 2004
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 October 23, 2004 [Page 18]
Internet-Draft AMTP April 2004
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 a client establishing
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. The server in a private network connection MAY
use either a public or private CA.
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 client authentication.
See Section 8 for important security considerations.
o A server SHOULD 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 October 23, 2004 [Page 19]
Internet-Draft AMTP April 2004
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 (privately 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 October 23, 2004 [Page 20]
Internet-Draft AMTP April 2004
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 October 23, 2004 [Page 21]
Internet-Draft AMTP April 2004
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 October 23, 2004 [Page 22]
Internet-Draft AMTP April 2004
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 October 23, 2004 [Page 23]
Internet-Draft AMTP April 2004
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 <http://bw.org/contact/> so that
the omission may be corrected before this draft is submitted for RFC
consideration.
Weinman Expires October 23, 2004 [Page 24]
Internet-Draft AMTP April 2004
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-03
Released (date).
o Changed "Authentication" and "X.509 Certificate Requirements", and
made other grammatical changes, to require servers to have
certificates. This was necessary because most (or all?)
implementations of TLS require servers to authenticate.
o Added language prohibiting a server from accepting or delivering
mail with undefined MPC parts.
o Grammatical changes in Introduction
B.2 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"
Weinman Expires October 23, 2004 [Page 25]
Internet-Draft AMTP April 2004
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.3 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
"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.
Weinman Expires October 23, 2004 [Page 26]
Internet-Draft AMTP April 2004
o Myriad grammatical and typographical changes.
B.4 draft-weinman-amtp-00
Released 2003-08-19. Original version.
Weinman Expires October 23, 2004 [Page 27]
Internet-Draft AMTP April 2004
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 (2004). 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 October 23, 2004 [Page 28]
Internet-Draft AMTP April 2004
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 October 23, 2004 [Page 29]
