< draft-hutzler-spamops-07.txt		draft-hutzler-spamops-08.txt >
	SMTP C. Hutzler		SMTP C. Hutzler
	Internet-Draft		Internet-Draft
	Intended status: Best Current D. Crocker		Intended status: Best Current D. Crocker
	Practice Brandenburg InternetWorking		Practice Brandenburg InternetWorking
	Expires: November 26, 2007 P. Resnick		Expires: January 9, 2008 P. Resnick
	QUALCOMM Incorporated		QUALCOMM Incorporated
	R. Sanders
	E. Allman		E. Allman
	Sendmail, Inc.		Sendmail, Inc.
	May 25, 2007		T. Finch
			University of Cambridge Computing
			Service
			July 8, 2007
	Email Submission: Access and Accountability		Email Submission Operations: Access and Accountability Requirements
	draft-hutzler-spamops-07		draft-hutzler-spamops-08
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 42 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on November 26, 2007.		This Internet-Draft will expire on January 9, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	Email has become a popular distribution service for a variety of		Email has become a popular distribution service for a variety of
	socially unacceptable, mass-effect purposes. The most obvious ones		socially unacceptable, mass-effect purposes. The most obvious ones
	include spam and worms. This note recommends conventions for the		include spam and worms. This note recommends conventions for the
	operation of email submission and transport services between		operation of email submission and transport services between
	independent operators, such as enterprises and Internet Service		independent operators, such as enterprises and Internet Service
	Providers. Its goal is to improve lines of accountability for		Providers. Its goal is to improve lines of accountability for
	controlling abusive uses of the Internet mail service. Consequently		controlling abusive uses of the Internet mail service. To this end
	the document offers recommendations for constructive operational		the document offers recommendations for constructive operational
	policies between independent operators of email transmission		policies between independent operators of email submission and
	services.		transmission services.
	With the recent advent of email authentication technologies aimed at		Email authentication technologies are aimed at providing assurances
	providing assurances and traceability between internetworked		and traceability between internetworked networks. In many email
	networks, the authors recognized that the initial submission of a		services, the weakest link in the chain of assurances is initial
	message became the weakest link. Consequently, the document offers		submission of a message. This document offers recommendations for
	recommendations for constructive operational policies for the first		constructive operational policies for this first step of email
	step of email sending, the submission (or posting) of email into the		sending, the submission (or posting) of email into the transmission
	transmission network. Relaying and delivery entail policies that		network. Relaying and delivery entail policies that occur subsequent
	occur subsequent to submission and are outside the scope of this		to submission and are outside the scope of this document.
	document.
	The document seeks BCP status. Comments and discussion of this		The document seeks BCP status. Comments and discussion of this
	document should be addressed to the ietf-smtp@imc.org mailing list.		document should be addressed to the ietf-smtp@imc.org mailing list.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Submission, Relaying, Delivery . . . . . . . . . . . . . . . . 5		3. Submission, Relaying, Delivery . . . . . . . . . . . . . . . . 5
	3.1. Best Practices for Submission Operation . . . . . . . . . 6		3.1. Best Practices for Submission Operation . . . . . . . . . 6
	3.2. Transitioning to Submission Port . . . . . . . . . . . . . 7		3.2. Transitioning to Submission Port . . . . . . . . . . . . . 7
	4. External Submission . . . . . . . . . . . . . . . . . . . . . 7		4. External Submission . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Best Practices for Support of External Submissions . . . . 8		4.1. Best Practices for Support of External Submissions . . . . 8
	5. Message Submission Authentication/Authorization		5. Message Submission Authentication/Authorization
	Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 10		Technologies . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 10		6. Consideration . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Security Considerations . . . . . . . . . . . . . . . . . 10		6.1. Security Considerations . . . . . . . . . . . . . . . . . 10
	6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 10		6.2. IANA Considerations . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7.1. References -- Normative . . . . . . . . . . . . . . . . . 10		7.1. References -- Normative . . . . . . . . . . . . . . . . . 10
	7.2. References -- Informative . . . . . . . . . . . . . . . . 10		7.2. References -- Informative . . . . . . . . . . . . . . . . 11
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . . . 13		Intellectual Property and Copyright Statements . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The very characteristics that make email such a convenient		The very characteristics that make email such a convenient
	communications medium -- its near ubiquity, rapid delivery and low		communications medium -- its near ubiquity, rapid delivery, low cost
	cost -- have made it a fertile ground for the distribution of		and support for exchanges without prior arrangement -- have made it a
	unwanted or malicious content. Spam, fraud and worms have become a		fertile ground for the distribution of unwanted or malicious content.
	serious problem, threatening the viability of email and costing end		Spam, fraud and worms have become a serious problem, threatening the
	users and providers millions of dollars in damages and lost		viability of email and costing end users and providers millions of
	productivity. In recent years, independent operators including		dollars in damages and lost productivity. In recent years,
	enterprises and ISPs have turned to a number of different		independent operators including enterprises and ISPs have turned to a
	technologies and procedures, in an attempt to combat these problems,		number of different technologies and procedures, in an attempt to
	with varying effect and with vastly different impacts on users and on		combat these problems. They have had varying effect and vastly
	the Internet mail infrastructure.		different impacts on users and on the Internet mail infrastructure.
	Email will often travel between multiple independent providers of		En route to its final destination, email will often travel between
	email transmission services, en route to its final destination. They		multiple independent providers of email transmission services. These
	will generally have no prior arrangement with one another and may		services will generally have no prior arrangement with one another
	employ different rules on the transmission. It is therefore		and may employ different rules on the transmission. It is therefore
	difficult both to debug problems that occur in mail transmission and		difficult both to debug problems that occur in mail transmission and
	to assign accountability if undesired or malicious mail is injected		to assign accountability if undesired or malicious mail is injected
	into the Internet mail infrastructure.		into the Internet mail infrastructure.
	A wide variety of email authentication technologies has been		Many email authentication technologies exist. They provide some
	developed, and more are under development. They provide some
	accountability and traceability between disparate networks. This		accountability and traceability between disparate networks. This
	document aims to build on these technologies by exploring best		document aims to build upon the availability of these technologies by
	practices for authenticating and authorizing the first step of an		exploring best practices for authenticating and authorizing the first
	email's delivery from MUA to MSA, otherwise known as submission.		step of an email's delivery, from a Mail User Agent (MUA) to a Mail
	Without strong practices on email submission, the authentication		Submission Agent (MSA), known as submission. Without strong
	technologies provide limited benefit.		practices on email submission, the use of authentication technologies
			elsewhere in the service provides limited benefit.
	This document specifies operational policies to be used for the first		This document specifies operational policies to be used for the first
	step of email sending, the submission (or posting from an MUA to an		step of email sending, the submission -- or posting from an MUA to an
	MSA as defined below) of email into the transmission service. These		MSA as defined below -- of email into the transmission service.
	policies will permit continued, smooth operation of Internet email,		These policies will permit continued, smooth operation of Internet
	with controls added to improve accountability. Relaying and		email, with controls added to improve accountability. Relaying and
	delivering employ policies that occur after submission and are		delivering employ policies that occur after submission and are
	outside the scope of this document. The policies listed here are		outside the scope of this document. The policies listed here are
	appropriate for operators of all sizes and may be implemented by		appropriate for operators of all sizes of networks and may be
	operators independently, without regard for whether the other side of		implemented by operators independently, without regard for whether
	an email exchange has implemented them.		the other side of an email exchange has implemented them.
	It is important to note that the adoption of these policies alone		It is important to note that the adoption of these policies alone
	will not solve the problems of spam and other undesirable email.		will not solve the problems of spam and other undesirable email.
	However they provide a useful step in clarifying lines of		However they provide a useful step in clarifying lines of
	accountability and interoperability between operators. This helps		accountability and interoperability between operators. This helps
	raise the bar against abusers, and provides a foundation for		raise the bar against abusers, and provides a foundation for
	additional tools to preserve the utility of the Internet email		additional tools to preserve the utility of the Internet email
	infrastructure.		infrastructure.
	This document does not delve into other anti-spam operational issues		NOTE: This document does not delve into other anti-spam operational
	such as standards for rejection of email. The authors note that this		issues such as standards for rejection of email. The authors note
	would be a very valuable effort to undertake and suggest that		that this could be a valuable effort to undertake and encourage
	additional work under another BCP document should be embarked upon.		its pursuit.
	2. Terminology		2. Terminology
	The Internet email architecture distinguishes four message-handling		The Internet email architecture distinguishes four message-handling
	components:		components:
	o Mail User Agents (MUAs)		o Mail User Agents (MUAs)
	o Mail Submission Agents (MSAs)		o Mail Submission Agents (MSAs)
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 38 ¶
	message to an MTA for transmission. MTAs "relay" messages to other		message to an MTA for transmission. MTAs "relay" messages to other
	MTAs, in a sequence reaching a destination MDA that, in turn,		MTAs, in a sequence reaching a destination MDA that, in turn,
	"delivers" the email to the recipient's inbox. The inbox is part of		"delivers" the email to the recipient's inbox. The inbox is part of
	the recipient-side MUA that works on behalf of the end-user to		the recipient-side MUA that works on behalf of the end-user to
	process received mail.		process received mail.
	These architectural components are often compressed, such as having		These architectural components are often compressed, such as having
	the same software do MSA, MTA and MDA functions. However the		the same software do MSA, MTA and MDA functions. However the
	requirements for each of these components of the architecture are		requirements for each of these components of the architecture are
	becoming more extensive, so that their software and even physical		becoming more extensive, so that their software and even physical
	platform separation is increasingly common		platform separation is increasingly common.
	Note: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		Normative Terms: The key words "MUST", "MUST NOT", "REQUIRED",
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
	this document are to be interpreted as described in [RFC2119].		"MAY", and "OPTIONAL" in this document are to be interpreted as
			described in [RFC2119].
	3. Submission, Relaying, Delivery		3. Submission, Relaying, Delivery
	The MSA, MTA and MDA functions used to be considered as the same set		Originally the MSA, MTA and MDA architectural components were
	of functions. This has been reflected in the history of Internet		considered to be a single unit. This was reflected the practice of
	mail by having MSA, MTA and MDA transfers all be performed with SMTP		having MSA, MTA and MDA transfers all be performed with SMTP
	[RFC2821] [RFC0821], over TCP Port 25. Internet mail permits email		[RFC2821] [RFC0821], over TCP Port 25. Internet mail permits email
	to be exchanged with no prior arrangement. Hence Port 25 exchanges		to be exchanged without prior arrangement and without sender
	occur without sender authentication. That is, the confirmed identity		authentication. That is, the confirmed identity of the originator of
	of the originator of the message is not necessarily known by the		the message is not necessarily known by the relaying MTAs or the MDA.
	relaying MTAs or the MDA.
	It is important to distinguish MUA-to-MSA email submission, versus		It is important to distinguish MUA-to-MSA email submission, versus
	MTA relaying, versus the final MTA-to-MDA transmission, prior to MDA-		MTA relaying, versus the final MTA-to-MDA transition. Submission
	to-MUA delivery. Submission typically does entail a pre-established		typically does entail a pre-established relationship between the user
	relationship between the user of the client and operator of the		of the client and operator of the server; equally, the MDA is
	server; equally, the MDA can determine that it will be affecting		performing final delivery and can determine that it has an existing
	final delivery and has an existing relationship with the recipient.		relationship with the recipient. That is, MSAs and MDAs can take
	That is, MSAs and MDAs can take advantage of having prior		advantage of having prior relationships with users, in order to
	relationships with users, in order to constrain their transfer		constrain their transfer activities.
	activities.
	Specifically, an MSA can choose to reject all postings from MUAs for		Specifically, an MSA can choose to reject all postings from MUAs for
	which it has no existing relationship. Similarly, an MDA can choose		which it has no existing relationship. Similarly, an MDA can choose
	to reject all mail to recipients for which that MDA has no		to reject all mail to recipients for which that MDA has no
	arrangement to perform delivery. Indeed, both of these policies are		arrangement to perform delivery. Indeed, both of these policies are
	already in common practice.		already in common practice.
	3.1. Best Practices for Submission Operation		3.1. Best Practices for Submission Operation
	Submission Port Availability:		Submission Port Availability:
	If external submissions are supported -- that is, from outside		If external submissions are supported -- that is, from outside
	a site's administrative domain -- then the domain's MSAs MUST		a site's administrative domain -- then the domain's MSAs MUST
	support the SUBMISSION port 587 [RFC4409]. It is also		support the SUBMISSION port 587 [RFC4409]. Operators MAY
	suggested that operators standardize on the SUBMISSION port for		standardize on the SUBMISSION port for both external AND LOCAL
	both external AND LOCAL users for simplicity.		users; this can significantly simplify submission operations.
	Submission Port Use:		Submission Port Use:
	MUAs SHOULD use the SUBMISSION port for message submission.		MUAs SHOULD use the SUBMISSION port for message submission.
	Submission Authentication:		Submission Authentication:
	MSAs MUST perform authentication on the identity asserted		MSAs MUST perform authentication on the identity asserted
	during all mail transactions on the SUBMISSION port, even for a		during all mail transactions on the SUBMISSION port, even for a
	message having a RCPT TO address that would not cause the		message having a RCPT TO address that would not cause the
	message to be relayed outside of the local administrative		message to be relayed outside of the local administrative
	environment.		environment.
	Submission Authorization:		Submission Authorization:
	Operators of MSAs MUST perform authorization of the		An operator of an MSA MUST ensure that the authenticated
	authenticated identity, for the operations performed during		identity is authorized to submit email, based on an existing
	mail submission and based on an existing relationship with the		relationship between the submitting entity and the operator.
	submitting entity. This requirement applies to all mail		This requirement applies to all mail submission mechanisms (MUA
	submission mechanisms (MUA to MSA).		to MSA).
	Submission Accountability after Submission:		Submission Accountability after Submission:
	Once a message has been submitted, the message SHOULD be later		For a reasonable period of time after submission, the message
	traceable by the MSA operator to the authenticated identity of		SHOULD be traceable by the MSA operator to the authenticated
	the user who sent the message for a reasonable period of time.		identity of the user who sent the message. Such tracing MAY be
	Such tracing MAY be based on transactional identifiers stored		based on transactional identifiers stored in the headers
	in the headers (received lines, etc) or other fields in the		(received lines, etc) or other fields in the message, on audit
	message. The specific length of time, after message		data stored elsewhere, or on any other mechanism that supports
	submission, that traceability is supported is not specified		sufficient post-submission accountability. The specific length
	here. However issues regarding transit often occur as much as		of time, after message submission, that traceability is
	one week after submission.		supported is not specified here. However issues regarding
			transit often occur as much as one week after submission.
			Note that [RFC3848] defines a means of recording submission-
			time information in Received header fields. This component
			mechanism can be useful for accountability assessment by
			receive-side analysis software to identify senders' MSAs and
			therefore apply appropriate policies to the various hops of a
			message transmission.
	3.2. Transitioning to Submission Port		3.2. Transitioning to Submission Port
	In order to promote transition of initial message submission from		In order to promote transition of initial message submission from
	port 25 to port 587, MSAs SHOULD listen on both ports. MSAs MUST		port 25 to port 587, MSAs MUST listen on port 587 by default and
	require authentication on port 587 and SHOULD require authentication		SHOULD have the ability to listen on other ports. MSAs MUST require
	on port 25. MSAs MAY also listen on other ports. Regardless of the		authentication on port 587 and SHOULD require authentication on any
	ports on which messages are accepted, MSAs MUST NOT permit relaying		other port used for submission. MSAs MAY also listen on other ports.
	of unauthenticated messages to other domains (i.e., they must not be		Regardless of the ports on which messages are accepted, MSAs MUST NOT
	open relays).		permit relaying of unauthenticated messages to other domains. That
			is, they must not be open relays.
	As delivered from the factory, MUAs SHOULD attempt to find the best		As a default, MUAs SHOULD attempt to find the best possible
	possible submission port from a list of alternatives. That list		submission port from a list of alternatives. The ordering of that
	SHOULD include the SUBMISSION port 587 as well as port 25. The		list SHOULD try the SUBMISSION port 587 first. Since most MUAs
	ordering of that list SHOULD try the SUBMISSION port 587 before		available today do not permit falling back to alternate ports, sites
	trying port 25, and MAY try other ports before, between, or after		SHOULD pre-configure or encourage their users to connect on the
	those two ports. Since most MUAs available today do not permit		SUBMISSION port 587, assuming that site supports that port.
	falling back to alternate ports, sites SHOULD pre-configure or
	encourage their users to connect on the SUBMISSION port 587, assuming
	that site supports that port.
	4. External Submission		4. External Submission
	An MUA, desiring special services, may need to submit mail across the		An MUA might need to submit mail across the Internet, rather than to
	Internet, rather than to a local MSA, in order to obtain particular		a local MSA, in order to obtain particular services from its home
	services. Examples include active privacy protection against third-		site. Examples include active privacy protection against third-party
	party content monitoring and timely processing. Further the privacy		content monitoring, timely processing, and being subject to the most
	requirement might reasonably include protection against monitoring by		appropriate authentication and accountability protocols. Further the
	the operator of the MUA's access network. This requirement creates a		privacy requirement might reasonably include protection against
	challenge for the provider operating the IP network through which the		monitoring by the operator of the MUA's access network. This
	MUA gains access. It makes that provider an involuntary recruit to		requirement creates a challenge for the provider operating the IP
	the task of solving mass-effect email problems: When the MUA		network through which the MUA gains access. It makes that provider
	participates in a problem that affects large numbers of Internet		an involuntary recruit to the task of solving mass-effect email
	users, the provider is expected to effect remedies and is often		problems: When the MUA participates in a problem that affects large
	expected to prevent such occurrences.		numbers of Internet users, the provider is expected to effect
			remedies and is often expected to prevent such occurrences.
	A proactive technique used by some providers is to block all use of		A proactive technique used by some providers is to block all use of
	Port 25 SMTP for mail that is being sent outbound, or to		Port 25 SMTP for mail that is being sent outbound, or to
	automatically redirect this traffic through a local SMTP proxy,		automatically redirect this traffic through a local SMTP proxy,
	except for hosts that are explicitly authorized. This can be		except for hosts that are explicitly authorized. This can be
	problematic for some users, notably legitimate mobile users		problematic for some users, notably legitimate mobile users
	attempting use their "home" MSA, even though those users might		attempting to use their "home" MSA, even though those users might
	already employ legitimate, Port 25-based authentication.		already employ legitimate, Port 25-based authentication.
	This document offers no recommendation concerning the blocking of		This document offers no recommendation concerning the blocking of
	SMTP Port 25 and similar practices for controlling abuse of the		SMTP Port 25 or similar practices for controlling abuse of the
	standard anonymous mail transfer port. Rather, it pursues the		standard anonymous mail transfer port. Rather, it pursues the
	mutually constructive benefit of using the official SUBMISSION Port		mutually constructive benefit of using the official SUBMISSION Port
	587 [RFC4409].		587 [RFC4409].
	Note: However the authors wish to note that many established		NOTE: Many established practices for controlling abuse of port 25,
	practices for controlling abuse of port 25, for mail that is being		for mail that is being sent outbound, currently do exist. These
	sent outbound, currently exist. These include the proxy of smtp		include the proxy of smtp traffic to local hosts for screening
	traffic to local hosts for screening combined with various forms of		combined with various forms of rate limits. The authors suggest
	rate limits. The authors suggest that this topic should be addressed		that a separate document on this topic would benefit the email
	in a separate BCP that would benefit the operational communities.		operations community.
	4.1. Best Practices for Support of External Submissions		4.1. Best Practices for Support of External Submissions
	Open Submission Port:		Open Submission Port:
	Access Providers MUST NOT block users from accessing the		Access Providers MUST NOT block users from accessing the
	external Internet using the SUBMISSION port 587 [RFC4409].		external Internet using the SUBMISSION port 587 [RFC4409].
	Traffic Identification -- External Posting Versus Relaying:		Traffic Identification -- External Posting (MSA) Versus Relaying
			(MX):
	For email being received from outside their local operational		When receiving email from outside their local operational
	environment, email service providers MUST distinguish between		environment, email service providers MUST distinguish between
	mail that will be delivered inside that environment, versus		unauthenticated email addressed to local domains (MX traffic)
	mail that is to be relayed back out to the internet. This		versus submission-related authenticated email that can be
	allows the MTA to restrict this operation, preventing the		addressed anywhere (MSA traffic). This allows the MTA to
	problem embodied by "open" relays. Note that there are		restrict relaying operations, and thereby prevent "open"
	situations where this may not apply such as secondary MXs and		relays. Note that there are situations where this may not
	related implementations internal to an operator's network and		apply, such as secondary MXs and related implementations
	within their control.		internal to an operator's network and within their control.
	Delivery Authorization:
	MDAs MUST NOT accept mail to recipients for which that MDA has
	no arrangement to perform delivery.
	Figure 1 depicts a local user (MUA.l) submitting a message to an MSA		Figure 1 depicts a local user (MUA.l) submitting a message to an MSA
	(MSA). It also shows a remote user (MUA.r), such as might be in a		(MSA). It also shows a remote user (MUA.r), such as might be in a
	coffee shop offering "hotspot" wireless access, submitting a message		coffee shop offering "hotspot" wireless access, submitting a message
	to their "home" MSA via an Authenticated Port 587 transaction.		to their "home" MSA via an Authenticated Port 587 transaction.
	HOME NETWORK DESTINATION		HOME NETWORK DESTINATION
	+-------+		+-------+
	| MUA.l |		| MUA.l |
	+---+---+		+---+---+
	skipping to change at page 9, line 43 ¶		skipping to change at page 9, line 44 ¶
	\ | /		\ | /
	---^----		---^----
	|		|
	******		******
	AP = Access Provider * AP *		AP = Access Provider * AP *
	******		******
	| Port 587		| Port 587
	+---+----+		+---+----+
	| MUA.r |		| MUA.r |
	+--------+		+--------+
	HOTSPOT		HOTSPOT
			Within the MSA's network, the alternative of using Port 587 or Port
			25 is shown. This document makes no recommendations about the use of
			Port 25 for submission. The diagram merely seeks to note that it is
			in common use and to acknowledge that this can be accomplished with
			sufficient accountability within an organization's network.
	Figure 1: Example of Port 587 Usage Via Internet		Figure 1: Example of Port 587 Usage Via Internet
	5. Message Submission Authentication/Authorization Technologies		5. Message Submission Authentication/Authorization Technologies
	There are many competent technologies and standards for		There are many competent technologies and standards for
	authenticating message submissions. Two mechanisms that have been		authenticating message submissions. Two component mechanisms that
	standardized include SMTP AUTH [RFC2554] and TLS [RFC3207].		have been standardized include SMTP AUTH [RFC2554] and TLS [RFC3207].
	Depending upon the environment, different mechanisms can be more or		Depending upon the environment, different mechanisms can be more or
	less effective and convenient. Organizations SHOULD choose the most		less effective and convenient. Mechanisms might also have to be used
	secure approaches that are practical.		in combination with each other to make a secure system.
			Organizations SHOULD choose the most secure approaches that are
			practical.
	This document does not provide recommendations on specific security		This document does not provide recommendations on specific security
	implementations. It simply provides a warning that transmitting user		implementations. It simply provides a warning that transmitting user
	credentials in clear text over insecure networks SHOULD be avoided in		credentials in clear text over insecure networks SHOULD be avoided in
	all scenarios as this could allow attackers to listen for this		all scenarios as this could allow attackers to listen for this
	traffic and steal account data. In these cases, it is strongly		traffic and steal account data. In these cases, it is strongly
	suggested that an appropriate security technology MUST be used.		suggested that an appropriate security technology MUST be used.
	6. Consideration		6. Consideration
	skipping to change at page 11, line 14 ¶		skipping to change at page 11, line 19 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2554] Myers, J., "SMTP Service Extension for Authentication",		[RFC2554] Myers, J., "SMTP Service Extension for Authentication",
	March .		March .
	[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over		[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
	Transport Layer Security", February 2002.		Transport Layer Security", February 2002.
			[RFC3848] Sun Microsystems, "ESMTP and LMTP Transmission Types
			Registration", RFC 3848, July 2005.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	These recommendations were first formulated during informal		These recommendations were first formulated during informal
	discussions among members of Anti-Spam Technical Alliance (ASTA) and		discussions among members of Anti-Spam Technical Alliance (ASTA) and
	some participants from the Internet Research Task Force's Anti-Spam		some participants from the Internet Research Task Force's Anti-Spam
	Research Group (ASRG).		Research Group (ASRG).
			Later reviews and suggestions were provided by: M. Allman, L.H.
			Aestrand, N. Borenstein, S. Bortzmeyer, K. Chon, R. Clayton, B. Cole,
			W. Dnes, V. Duchovni, E. Edelstein, F. Ellermann, M. Elvey, J.D.
			Falk, N. Freed, J. Glube, A. Herzberg, J. Klensin, J. Levine, S.
			Moonesamy, K. Moore, R. Nelson, C. Newman, C. O'Malley, S.
			Ramasubramanian, R. Rognlie, J. St. Sauver, W. Schlitt, B. Shein, B.
			Sullivan.
	Authors' Addresses		Authors' Addresses
	C. Hutzler		C. Hutzler
	2512 Freetown Drive		2512 Freetown Drive
	Reston, VA 20191		Reston, VA 20191
	Phone: 703-915-6862		Phone: 703-915-6862
	Email: cdhutzler@aol.com		Email: cdhutzler@aol.com
	URI: http://carlhutzler.com/blog/		URI: http://carlhutzler.com/blog/
	D. Crocker		D. Crocker
	Brandenburg InternetWorking		Brandenburg InternetWorking
	675 Spruce Dr.		675 Spruce Dr.
	Sunnyvale, CA 94086		Sunnyvale, CA 94086
	USA		USA
	Phone: +1.408.246.8253		Phone: +1.408.246.8253
	Email: dcrocker@bbiw.net		Email: dcrocker@bbiw.net
	URI: http://bbiw.net		URI: http://bbiw.net
	P. Resnick		P. Resnick
	QUALCOMM Incorporated		QUALCOMM Incorporated
	5775 Morehouse Drive		5775 Morehouse Drive
	San Diego, CA 92121-1714		San Diego, CA 92121-1714
	USA		USA
	Phone: +1 858 651 4478		Phone: +1 858 651 4478
	Email: presnick@qualcomm.com		Email: presnick@qualcomm.com
	URI: http://www.qualcomm.com/~presnick/		URI: http://www.qualcomm.com/~presnick/
	R. Sanders
	Atlanta, GA
	USA
	Phone:
	Email:
	URI:
	E. Allman		E. Allman
	Sendmail, Inc.		Sendmail, Inc.
	Emeryville, CA		Emeryville, CA
	USA		USA
	Phone: +1 510 594 5501		Phone: +1 510 594 5501
	Email: eric+ietf-smtp@sendmail.org		Email: eric+ietf-smtp@sendmail.org
			T. Finch
			University of Cambridge Computing Service
			New Museums Site
			Pembroke Street
			Cambridge CB2 3QH
			ENGLAND
			Phone: +44 797 040 1426
			Email: dot@dotat.at
			URI: http://dotat.at/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
End of changes. 46 change blocks.
	155 lines changed or deleted		176 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/