< draft-ietf-emailcore-as-02.txt		draft-ietf-emailcore-as-03.txt >
	EMAILCORE J. Klensin, Ed.		EMAILCORE J.C. Klensin, Ed.
	Internet-Draft		Internet-Draft
	Intended status: Standards Track K. Murchison		Intended status: Standards Track K. Murchison, Ed.
	Expires: January 12, 2022 Fastmail		Expires: 7 February 2022 Fastmail
	E. Sam		E. Sam, Ed.
	July 11, 2021		6 August 2021
	Applicability Statement for IETF Core Email Protocols		Applicability Statement for IETF Core Email Protocols
	draft-ietf-emailcore-as-02		draft-ietf-emailcore-as-03
	Abstract		Abstract
	Electronic mail is one of the oldest Internet applications that is		Electronic mail is one of the oldest Internet applications that is
	still in very active use. While the basic protocols and formats for		still in very active use. While the basic protocols and formats for
	mail transport and message formats have evolved slowly over the		mail transport and message formats have evolved slowly over the
	years, events and thinking in more recent years have supplemented		years, events and thinking in more recent years have supplemented
	those core protocols with additional features and suggestions for		those core protocols with additional features and suggestions for
	their use. This Applicability Statement describes the relationship		their use. This Applicability Statement describes the relationship
	among many of those protocols and provides guidance and makes		among many of those protocols and provides guidance and makes
	recommendations for the use of features of the core protocols.		recommendations for the use of features of the core protocols.
	Note on draft-ietf-emailcore-as-01
	This version is provided as a document management convenience to
	update the author list and make an un-expired version available to
	the WG. There are no substantive changes from the prior version.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on January 12, 2022.		This Internet-Draft will expire on 7 February 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Applicability of Some SMTP Provisions . . . . . . . . . . . . 3		2. Applicability of Some SMTP Provisions . . . . . . . . . . . . 3
	3. Applicability of Message Format Provisions . . . . . . . . . 3		2.1. Handling of the Domain Argument to the EHLO Command . . . 3
	4. Use of IP addresses/domain names in EHLO . . . . . . . . . . 4		2.2. Use of Address Literals . . . . . . . . . . . . . . . . . 4
	5. Extension Keywords Starting in X- . . . . . . . . . . . . . . 4		2.3. Use of Addresses in Top-Level Domains . . . . . . . . . . 4
	6. IP address literals in EHLO . . . . . . . . . . . . . . . . . 4		3. Applicability of Message Format Provisions . . . . . . . . . 4
	7. Use of empty quote strings in email messages . . . . . . . . 5		3.1. Use of Empty Quoted Strings . . . . . . . . . . . . . . . 4
	8. MIME and Its Implications . . . . . . . . . . . . . . . . . . 5		4. MIME and Its Implications . . . . . . . . . . . . . . . . . . 5
	9. Other Stuff . . . . . . . . . . . . . . . . . . . . . . . . . 6		5. Other Stuff . . . . . . . . . . . . . . . . . . . . . . . . . 5
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 6		8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 6		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
	13.1. Normative References . . . . . . . . . . . . . . . . . . 6		9.1. Normative References . . . . . . . . . . . . . . . . . . 6
	13.2. Informative References . . . . . . . . . . . . . . . . . 7		9.2. Informative References . . . . . . . . . . . . . . . . . 6
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7
	A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30)		A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to
	to draft-ietf-emailcore-as-00 . . . . . . . . . . . . 8		draft-ietf-emailcore-as-00 . . . . . . . . . . . . . . . 7
	A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to		A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to
	-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to		A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to
	-02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		-02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
			A.4. Changes from draft-ietf-emailcore-as-02 (2021-08-06) to
			-03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	In its current form, this draft is a placeholder and beginning of an		In its current form, this draft is a placeholder and beginning of an
	outline for the Applicability Statement that has been discussed as a		outline for the Applicability Statement that has been discussed as a
	complement for proposed revisions of the base protocol specifications		complement for proposed revisions of the base protocol specifications
	for SMTP [RFC5321] (being revised as ID.RFC5321bis [ID.RFC5321bis])		for SMTP [RFC5321] (being revised as [I-D.ietf-emailcore-rfc5321bis])
	and Internet Message Format [RFC5322] (being revised as ID.RFC5322bis		and Internet Message Format [RFC5322] (being revised as
			[I-D.ietf-emailcore-rfc5322bis]). Among other things, it is expected
	[ID.RFC5322bis]). Among other things, it is expected to capture		to capture topics that a potential WG concludes are important but
	topics that a potential WG concludes are important but that should		that should not become part of those core documents.
	not become part of those core documents.
	As discussed in RFC 2026 [RFC2026],
			As discussed in [RFC2026],
	"An Applicability Statement specifies how, and under what		"An Applicability Statement specifies how, and under what
	circumstances, one or more TSs may be applied to support a		circumstances, one or more TSs may be applied to support a
	particular Internet capability."		particular Internet capability."
	That form of a standards track document is appropriate because one of		That form of a standards track document is appropriate because one of
	the roles of such a document is to explain the relationship among		the roles of such a document is to explain the relationship among
	technical specification, describe how they are used together, and		technical specifications, describe how they are used together, and
	make statements about what is "required, recommended, or elective".		make statements about what is "required, recommended, or elective".
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119] and		document are to be interpreted as described in [RFC2119] and
	RFC 8174 [RFC8174].		[RFC8174].
	2. Applicability of Some SMTP Provisions		2. Applicability of Some SMTP Provisions
	Over the years since RFC 5321 was published in October 2008, usage of		Over the years since RFC 5321 was published in October 2008, usage of
	SMTP has evolved, machines and network speeds have increased, and the		SMTP has evolved, machines and network speeds have increased, and the
	frequency with which SMTP senders and receivers have to be prepared		frequency with which SMTP senders and receivers have to be prepared
	to deal with systems that are disconnected from the Internet for long		to deal with systems that are disconnected from the Internet for long
	periods or that require many hops to reach has decreased. During the		periods or that require many hops to reach has decreased. During the
	same period, the IETF has become much more sensitive to privacy and		same period, the IETF has become much more sensitive to privacy and
	security issues and the need to be more resistant or robust against		security issues and the need to be more resistant or robust against
	spam and other attacks. In addition SMTP (and Message Format)		spam and other attacks. In addition SMTP (and Message Format)
	extensions have been introduced that are expected to evolve the		extensions have been introduced that are expected to evolve the
	Internet's mail system to better accommodate environments in which		Internet's mail system to better accommodate environments in which
	Basic Latin Script is not the norm.		Basic Latin Script is not the norm.
	This section describes adjustments that may be appropriate for SMTP		This section describes adjustments that may be appropriate for SMTP
	under various circumstances and discusses the applicability of other		under various circumstances and discusses the applicability of other
	protocols that represent newer work or that are intended to deal with		protocols that represent newer work or that are intended to deal with
	relatively newer issues.		relatively newer issues.
	[[CREF1: ... Actual content to be supplied after WG consideration.		2.1. Handling of the Domain Argument to the EHLO Command
	]]
	3. Applicability of Message Format Provisions
	Placeholder:
	I am not sure what, if anything, goes here. If nothing does, we drop
	the section.
	[[CREF2: ... Actual content to be supplied after WG consideration.]]
	4. Use of IP addresses/domain names in EHLO
	There has been a suggestion to update RFC 5321 [RFC5321] to clarify
	that servers may verify the domain name in the EHLO command to see if
	it matches up with the IP address of the client. The reasoning
	behind this was that many mail servers were already verifying the
	domain name provided with the EHLO command for anti spam purposes,
	and that mail servers that don't have a matching domain name/IP
	address are more likely to have their mail rejected.
	People for this change say that this is the "de facto" practice and
	that it should be formally specified since basically all mail servers
	are verifying the EHLO domain name anyway.
	People against this argue that the domain names supplied with the
	EHLO command won't always have a matching IP because they are
	internal domain names or a custom domain convention.
	The consensus was that this should be specified within RFC 5231 due
	to the fact it is already taking place to prevent spam.
	5. Extension Keywords Starting in X-		If the "Domain" argument to the EHLO command does not have an address
			record in the DNS that matches the IP address of the client, the SMTP
			server may refuse any mail from the client as part of established
			anti-abuse practice. Operational experience has demonstrated that
			the lack of a matching address record for the the domain name
			argument is at best an indication of a poorly-configured MTA, and at
			worst that of an abusive host.
	Since the release of the SMTP RFC, opinons on "X" extensions have		2.2. Use of Address Literals
	changed over the years. These opinions can best be represented by
	RFC 6648 [RFC6648]. In short, people are beginning to "shy away"
	from the usage of "X" extensions.
	The proposed changes would involve the removal of the "X" extension		The "address-literal" ABNF non-terminal is used in various places in
	provisions in Section 2.2.2 of the SMTP RFC, and also called for the		[I-D.ietf-emailcore-rfc5321bis] grammar however, for SMTP connections
	removal of how to deal with "X" extensinos in the IANA considerations		over the public internet, an "address-literal" as the argument to
	and private-use commands.		EHLO command or the "Domain" part of the "Mailbox" argument to the
			MAIL FROM command is quite likely to result in the message being
			rejected as a matter of policy at many sites, since they are deemed
			to be signs of at best a misconfigured server, and at worst either a
			compromised host or a server that's intentionally configured to hide
			its identity.
	While the exact solution is being talked about, the general consensus		2.3. Use of Addresses in Top-Level Domains
	is that its a good idea for this part of the RFC to be removed or
	reformed.
	6. IP address literals in EHLO		While addresses in top-level domains (TLDs) are syntactically valid,
			mail to these addresses has never worked reliably. A handful of
			country code TLDs have top level MX records but they have never been
			widely used nor well supported. In 2013 [RFC7085] found 18 TLDs with
			MX records, which dropped to 17 in 2021 despite many new TLDs having
			been added.
	One of the proposed ideas on the mailing list was to clarify if IP		Mail sent to addresses with single label domains has typically
	addresses are allowed to be used as a EHLO parameter. While the		expected the address to be an abbreviation to be completed by a
	original specification allowed for the use of IP addresses instead of		search list, so mail to bob@sales would be completed to
	a domain name, it didn't say if the mail server was required to		bob@sales.example.com. This shortcut has led to unfortunate
	accept IP addresses		consequnces; in one famous case, in 1991 when the .CS domain was
	The people that suggest that the specification should not require IP		added to the root, mail in computer science departments started to
	addresses to be accepted say that anti-spam systems already reject		fail as mail to bob@cs was now treated as mail to Czechoslovakia.
	emails with IP addresses in EHLO commands, just like how they reject		Hence, for reliable service, mail SHOULD NOT use addreses that
	domain names that don't match up with a valid IP.		contain single label domains.
	However, some say there are some valid use cases for EHLO commands to		3. Applicability of Message Format Provisions
	have IP literals, for example in private networks.
	The general opinion is that the specification should have a section		This section describes adjustments to the Internet Message Format
	explaining why IP addresses are not recommended as an EHLO parameter,		that may be appropriate under various circumstances.
	but should not ban IP literals outright.
	7. Use of empty quote strings in email messages		3.1. Use of Empty Quoted Strings
	quoted-string ABNF non terminal is used in various places in		The "quoted-string" ABNF non-terminal is used in various places in
	rfc5322bis grammar. While it allows for empty quoted string, such		rfc5322bis grammar. While it allows for empty quoted string, such
	construct is going to cause interoperability issues when used in		construct is going to cause interoperability issues when used in
	certain header fields. In particular, use of empty quoted strings is		certain header fields. In particular, use of empty quoted strings is
	NOT RECOMMENDED in "received-token" (a component of a Received header		NOT RECOMMENDED in "received-token" (a component of a Received header
	field), "keywords" (a component of a Keywords header field) and		field), "keywords" (a component of a Keywords header field) and
	"local-part" (left hand side of email addresses). Use of empty		"local-part" (left hand side of email addresses). Use of empty
	quoted strings is in particular problematic in the "local-part". For		quoted strings is in particular problematic in the "local-part". For
	example, all of the following email addresses are non interoperable:		example, all of the following email addresses are non interoperable:
	"".bar@example.com		"".bar@example.com
	foo.""@example.net		foo.""@example.net
	""@example.com		""@example.com
	Use of empty quoted strings is fine in "display-name".		Use of empty quoted strings is fine in "display-name".
	8. MIME and Its Implications		4. MIME and Its Implications
	When the work leading to the original version of the MIME		When the work leading to the original version of the MIME
	specification was completed in 1992 [RFC1341], the intention was that		specification was completed in 1992 [RFC1341], the intention was that
	it be kept separate from the specification for basic mail headers in		it be kept separate from the specification for basic mail headers in
	RFC 822 [RFC0822]. That plan was carried forward into RFC 822's		RFC 822 [RFC0822]. That plan was carried forward into RFC 822's
	successors, RFC 2822 [RFC2822] and RFC 5322 [RFC5322] and the		successors, [RFC2822] and [RFC5322] and the successors of that
	successors of that original MIME specification including RFC 2045		original MIME specification including [RFC2045]. The decision to do
	[RFC2045]. The decision to do so was different from the one made for		so was different from the one made for SMTP, for which the core
	SMTP, for which the core specification was changed to allow for the		specification was changed to allow for the extension mechanism
	extension mechanism [RFC1425] which was then incorporated into RFC		[RFC1425] which was then incorporated into RFC 5321 and its
	5321 and its predecessor [RFC2821].		predecessor [RFC2821].
	Various uses of MIME have become nearly ubiquitous in contemporary		Various uses of MIME have become nearly ubiquitous in contemporary
	email while others may have fallen into disuse or been repurposed		email while others may have fallen into disuse or been repurposed
	from the intent of their original design.		from the intent of their original design.
	It may be appropriate to make some clear statements about the		It may be appropriate to make some clear statements about the
	applicability of MIME and its features.		applicability of MIME and its features.
	9. Other Stuff		5. Other Stuff
	It is fairly clear that there will be things that do not fit into the		It is fairly clear that there will be things that do not fit into the
	sections outlined above. As one example, if the IETF wants to say		sections outlined above. As one example, if the IETF wants to say
	something specific about signatures over headers or what (non-trace)		something specific about signatures over headers or what (non-trace)
	headers may reasonably be altered in transit, that may be more		headers may reasonably be altered in transit, that may be more
	appropriate to other sections than to any of the three suggested		appropriate to other sections than to any of the three suggested
	above.		above.
	10. Acknowledgments		6. Acknowledgments
	The Emailcore group arose out of discussions on the ietf-smtp group		The Emailcore group arose out of discussions on the ietf-smtp group
	over changes and additions that should be made to the core email		over changes and additions that should be made to the core email
	protocols. It was agreed upon that it was time to create a working		protocols. It was agreed upon that it was time to create a working
	group that would fix many potential errors and opportunities for		group that would fix many potential errors and opportunities for
	misunderstandings within the RFCs		misunderstandings within the RFCs.
	11. IANA Considerations		7. IANA Considerations
	This memo includes no requests to or actions for IANA. The IANA		This memo includes no requests to or actions for IANA. The IANA
	registries associated with the protocol specifications it references		registries associated with the protocol specifications it references
	are specified in their respective documents.		are specified in their respective documents.
	12. Security Considerations		8. Security Considerations
	All drafts are required to have a security considerations section and		All drafts are required to have a security considerations section and
	this one eventually will.		this one eventually will.
	... To be supplied ...		... To be supplied ...
	13. References		9. References
	13.1. Normative References		9.1. Normative References
	[RFC2026] Bradner, S., "The Internet Standards Process -- Revision		[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
	3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,		3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
	<https://www.rfc-editor.org/info/rfc2026>.		<https://www.rfc-editor.org/info/rfc2026>.
	[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part One: Format of Internet Message		Extensions (MIME) Part One: Format of Internet Message
	Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,		Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
	<https://www.rfc-editor.org/info/rfc2045>.		<https://www.rfc-editor.org/info/rfc2045>.
	[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,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	13.2. Informative References		9.2. Informative References
	[ID.RFC5321bis]		[I-D.ietf-emailcore-rfc5321bis]
	Klensin, J., "Simple Mail Transfer Protocol", Feburary		Klensin, J. C., "Simple Mail Transfer Protocol", Work in
	2021, <https://datatracker.ietf.org/doc/draft-klensin-		Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis-
	rfc5321bis/>.		03, 10 July 2021, <https://www.ietf.org/archive/id/draft-
			ietf-emailcore-rfc5321bis-03.txt>.
	[ID.RFC5322bis]		[I-D.ietf-emailcore-rfc5322bis]
	Resnick, P., "Internet Message Format", March 2021,		Resnick, P. W., "Internet Message Format", Work in
	<https://datatracker.ietf.org/doc/draft-resnick-		Progress, Internet-Draft, draft-ietf-emailcore-rfc5322bis-
	rfc5322bis/>.		01, 29 March 2021, <https://www.ietf.org/archive/id/draft-
			ietf-emailcore-rfc5322bis-01.txt>.
	[RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET		[RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
	TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822,		TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822,
	August 1982, <https://www.rfc-editor.org/info/rfc822>.		August 1982, <https://www.rfc-editor.org/info/rfc822>.
	[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet		[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
	Mail Extensions): Mechanisms for Specifying and Describing		Mail Extensions): Mechanisms for Specifying and Describing
	the Format of Internet Message Bodies", RFC 1341,		the Format of Internet Message Bodies", RFC 1341,
	DOI 10.17487/RFC1341, June 1992,		DOI 10.17487/RFC1341, June 1992,
	<https://www.rfc-editor.org/info/rfc1341>.		<https://www.rfc-editor.org/info/rfc1341>.
	skipping to change at page 8, line 9 ¶		skipping to change at page 7, line 35 ¶
	<https://www.rfc-editor.org/info/rfc2822>.		<https://www.rfc-editor.org/info/rfc2822>.
	[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,		[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
	DOI 10.17487/RFC5321, October 2008,		DOI 10.17487/RFC5321, October 2008,
	<https://www.rfc-editor.org/info/rfc5321>.		<https://www.rfc-editor.org/info/rfc5321>.
	[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,		[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
	DOI 10.17487/RFC5322, October 2008,		DOI 10.17487/RFC5322, October 2008,
	<https://www.rfc-editor.org/info/rfc5322>.		<https://www.rfc-editor.org/info/rfc5322>.
	[RFC6648] Saint-Andre, P., Nottingham, N., Ed., and D. Crocker,		[RFC7085] Levine, J. and P. Hoffman, "Top-Level Domains That Are
	"Deprecating the "X-" Prefix and Similar Constructs in		Already Dotless", RFC 7085, DOI 10.17487/RFC7085, December
	Application Protocols", June 2012,		2013, <https://www.rfc-editor.org/info/rfc7085>.
	<https://www.rfc-editor.org/info/rfc6648>.
	Appendix A. Change Log		Appendix A. Change Log
	RFC Editor: Please remove this appendix before publication.		RFC Editor: Please remove this appendix before publication.
	A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to draft-		A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to draft-
	ietf-emailcore-as-00		ietf-emailcore-as-00
	o Change of filename, metadata, and date to reflect transition to WG		* Change of filename, metadata, and date to reflect transition to WG
	document for new emailcore WG. No other substantive changes		document for new emailcore WG. No other substantive changes
	A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to -01		A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to -01
	o Added co-authors (list is in alphabetical order for the present).		* Added co-authors (list is in alphabetical order for the present).
	o Updated references to 5321bis and 5322bis.		* Updated references to 5321bis and 5322bis.
	o Added note at top, "This version is provided as a document		* Added note at top, "This version is provided as a document
	management convenience to update the author list and make an un-		management convenience to update the author list and make an un-
	expired version available to the WG. There are no substantive		expired version available to the WG. There are no substantive
	changes from the prior version", which should be removed for		changes from the prior version", which should be removed for
	version -02.		version -02.
	A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to -02		A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to -02
	o Added new editors and also added some issues the emailcore group		* Added new editors and also added some issues the emailcore group
	will be dealing with.		will be dealing with.
	o Added reference to RFC 6648.		* Added reference to RFC 6648.
			A.4. Changes from draft-ietf-emailcore-as-02 (2021-08-06) to -03
			* Moved discussion of address-literals (issue #1) and domain names
			in EHLO (issue #19) under SMTP Provisions section
			* Moved discussion of empty quoted-strings under Message Format
			Provisions section
			* Added text on use of addresses in TLDs (issue #50)
			* Marked all authors as editors.
			* Miscellaneous editorial changes.
	Authors' Addresses		Authors' Addresses
	John C Klensin (editor)		John C Klensin (editor)
	1770 Massachusetts Ave, Ste 322		1770 Massachusetts Ave, Ste 322
	Cambridge, MA 02140		Cambridge, MA 02140
	USA		United States of America
	Phone: +1 617 245 1457		Phone: +1 617 245 1457
	Email: john-ietf@jck.com		Email: john-ietf@jck.com
	Kenneth Murchison
			Kenneth Murchison (editor)
	Fastmail US LLC		Fastmail US LLC
	1429 Walnut Street - Suite 1201		1429 Walnut Street - Suite 1201
	Philadelphia, PA 19102		Philadelphia, PA 19102
	USA		United States of America
	Email: murch@fastmailteam.com		Email: murch@fastmailteam.com
			E Sam (editor)
	E Sam
	Email: winshell64@gmail.com		Email: winshell64@gmail.com
End of changes. 47 change blocks.
	149 lines changed or deleted		136 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/