wdiff draft-ietf-emailcore-as-02.txt draft-ietf-emailcore-as-03.txt

EMAILCORE J. J.C. Klensin, Ed.
Internet-Draft
Intended status: Standards Track K. Murchison Murchison, Ed.
Expires: January 12, 7 February 2022 Fastmail
E. Sam
July 11, Sam, Ed.
6 August 2021

Applicability Statement for IETF Core Email Protocols
draft-ietf-emailcore-as-02
draft-ietf-emailcore-as-03

Abstract

Electronic mail is one of the oldest Internet applications that is
still in very active use. While the basic protocols and formats for
mail transport and message formats have evolved slowly over the
years, events and thinking in more recent years have supplemented
those core protocols with additional features and suggestions for
their use. This Applicability Statement describes the relationship
among many of those protocols and provides guidance and makes
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

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on January 12, 7 February 2022.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applicability of Some SMTP Provisions . . . . . . . . . . . . 3
3. Applicability
2.1. Handling of Message Format Provisions the Domain Argument to the EHLO Command . . . 3
2.2. Use of Address Literals . . . . . . . 3
4. Use of IP addresses/domain names in EHLO . . . . . . . . . . 4
5. Extension Keywords Starting
2.3. Use of Addresses in X- . . . . Top-Level Domains . . . . . . . . . . 4
6. IP address literals in EHLO
3. Applicability of Message Format Provisions . . . . . . . . . 4
3.1. Use of Empty Quoted Strings . . . . . . . . 4
7. Use of empty quote strings in email messages . . . . . . . . 5
8. 4
4. MIME and Its Implications . . . . . . . . . . . . . . . . . . 5
9.
5. Other Stuff . . . . . . . . . . . . . . . . . . . . . . . . . 6
10. 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
11. 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
12.
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
13.
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
13.1.
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
13.2.
9.2. Informative References . . . . . . . . . . . . . . . . . 7 6
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 7
A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to
draft-ietf-emailcore-as-00 . . . . . . . . . . . . 8 . . . 7
A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7
A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to
-02 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
A.4. Changes from draft-ietf-emailcore-as-02 (2021-08-06) to
-03 . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8

1. Introduction

In its current form, this draft is a placeholder and beginning of an
outline for the Applicability Statement that has been discussed as a
complement for proposed revisions of the base protocol specifications
for SMTP [RFC5321] (being revised as ID.RFC5321bis [ID.RFC5321bis]) [I-D.ietf-emailcore-rfc5321bis])
and Internet Message Format [RFC5322] (being revised as ID.RFC5322bis

[ID.RFC5322bis]).
[I-D.ietf-emailcore-rfc5322bis]). Among other things, it is expected
to capture topics that a potential WG concludes are important but
that should not become part of those core documents.

As discussed in RFC 2026 [RFC2026],
"An Applicability Statement specifies how, and under what
circumstances, one or more TSs may be applied to support a
particular Internet capability."

That form of a standards track document is appropriate because one of
the roles of such a document is to explain the relationship among
technical specification, specifications, describe how they are used together, and
make statements about what is "required, recommended, or elective".

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 RFC 2119 [RFC2119] and
RFC 8174
[RFC8174].

2. Applicability of Some SMTP Provisions

Over the years since RFC 5321 was published in October 2008, usage of
SMTP has evolved, machines and network speeds have increased, and the
frequency with which SMTP senders and receivers have to be prepared
to deal with systems that are disconnected from the Internet for long
periods or that require many hops to reach has decreased. During the
same period, the IETF has become much more sensitive to privacy and
security issues and the need to be more resistant or robust against
spam and other attacks. In addition SMTP (and Message Format)
extensions have been introduced that are expected to evolve the
Internet's mail system to better accommodate environments in which
Basic Latin Script is not the norm.

This section describes adjustments that may be appropriate for SMTP
under various circumstances and discusses the applicability of other
protocols that represent newer work or that are intended to deal with
relatively newer issues.

[[CREF1: ... Actual content to be supplied after WG consideration.
]]

3. Applicability

2.1. Handling of Message Format Provisions

Placeholder:
I am not sure what, if anything, goes here. If nothing does, we drop the section.

[[CREF2: ... Actual content Domain Argument to be supplied after WG consideration.]]

4. Use of IP addresses/domain names in the EHLO

There has been a suggestion to update RFC 5321 [RFC5321] to clarify
that servers may verify Command

If the domain name in "Domain" argument to the EHLO command to see if
it does not have an address
record in the DNS that 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 client, the EHLO command for anti spam purposes,
and that SMTP
server may refuse any mail servers from the client as part of established
anti-abuse practice. Operational experience has demonstrated that don't have
the lack of a matching domain name/IP address are more likely to have their mail rejected.

People record 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
argument is at best an indication of a custom domain convention.

The consensus was poorly-configured MTA, and at
worst that this should be specified within RFC 5231 due
to the fact it of an abusive host.

2.2. Use of Address Literals

The "address-literal" ABNF non-terminal is already taking place to prevent spam.

5. Extension Keywords Starting used in X-

Since the release of the various places in
[I-D.ietf-emailcore-rfc5321bis] grammar however, for SMTP RFC, opinons on "X" extensions have
changed connections
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 public internet, an "address-literal" as the removal of argument to
EHLO command or the "X" extension
provisions in Section 2.2.2 "Domain" part of the SMTP RFC, and also called for "Mailbox" argument to the
removal of how
MAIL FROM command is quite likely to deal with "X" extensinos result in the IANA considerations
and private-use commands.

While the exact solution is message being talked about, the general consensus
is that its
rejected as a good idea for this part matter of the RFC policy at many sites, since they are deemed
to be removed or
reformed.

6. IP address literals in EHLO

One signs of the proposed ideas on the mailing list was at best a misconfigured server, and at worst either a
compromised host or a server that's intentionally configured to clarify if IP hide
its identity.

2.3. Use of Addresses in Top-Level Domains

While addresses in top-level domains (TLDs) are allowed syntactically valid,
mail to be used as a EHLO parameter. While the
original specification allowed for the use of IP these addresses instead of
a domain name, it didn't say if the mail server was required 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.

Mail sent to
accept IP addresses
The people that suggest that with single label domains has typically
expected the specification should not require IP
addresses address to be accepted say that anti-spam systems already reject
emails with IP addresses an abbreviation to be completed by a
search list, so mail to bob@sales would be completed to
bob@sales.example.com. This shortcut has led to unfortunate
consequnces; in EHLO commands, just like how they reject one famous case, in 1991 when the .CS domain names that don't match up with a valid IP.

However, some say there are some valid use cases for EHLO commands was
added to
have IP literals, for example the root, mail in private networks.

The general opinion is computer science departments started to
fail as mail to bob@cs was now treated as mail to Czechoslovakia.
Hence, for reliable service, mail SHOULD NOT use addreses that the specification should have a
contain single label domains.

3. Applicability of Message Format Provisions

This section
explaining why IP addresses are not recommended as an EHLO parameter,
but should not ban IP literals outright.

7. describes adjustments to the Internet Message Format
that may be appropriate under various circumstances.

3.1. Use of empty quote strings in email messages

quoted-string Empty Quoted Strings

The "quoted-string" ABNF non terminal non-terminal is used in various places in
rfc5322bis grammar. While it allows for empty quoted string, such
construct is going to cause interoperability issues when used in
certain header fields. In particular, use of empty quoted strings is
NOT RECOMMENDED in "received-token" (a component of a Received header
field), "keywords" (a component of a Keywords header field) and
"local-part" (left hand side of email addresses). Use of empty
quoted strings is in particular problematic in the "local-part". For
example, all of the following email addresses are non interoperable:

"".bar@example.com

foo.""@example.net

""@example.com

Use of empty quoted strings is fine in "display-name".

4. MIME and Its Implications

When the work leading to the original version of the MIME
specification was completed in 1992 [RFC1341], the intention was that
it be kept separate from the specification for basic mail headers in
RFC 822 [RFC0822]. That plan was carried forward into RFC 822's
successors, RFC 2822 [RFC2822] and RFC 5322 [RFC5322] and the successors of that
original MIME specification including RFC 2045 [RFC2045]. The decision to do
so was different from the one made for SMTP, for which the core
specification was changed to allow for the extension mechanism
[RFC1425] which was then incorporated into RFC 5321 and its
predecessor [RFC2821].

Various uses of MIME have become nearly ubiquitous in contemporary
email while others may have fallen into disuse or been repurposed
from the intent of their original design.

It may be appropriate to make some clear statements about the
applicability of MIME and its features.

5. Other Stuff

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
something specific about signatures over headers or what (non-trace)
headers may reasonably be altered in transit, that may be more
appropriate to other sections than to any of the three suggested
above.

10.

6. Acknowledgments

The Emailcore group arose out of discussions on the ietf-smtp group
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
group that would fix many potential errors and opportunities for
misunderstandings within the RFCs

11. RFCs.

7. IANA Considerations

This memo includes no requests to or actions for IANA. The IANA
registries associated with the protocol specifications it references
are specified in their respective documents.

12.

8. Security Considerations

All drafts are required to have a security considerations section and
this one eventually will.

... To be supplied ...

13.

9. References

13.1.

9.1. Normative References

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
<https://www.rfc-editor.org/info/rfc2026>.

[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

13.2.

9.2. Informative References

[ID.RFC5321bis]

[I-D.ietf-emailcore-rfc5321bis]
Klensin, J., J. C., "Simple Mail Transfer Protocol", Feburary Work in
Progress, Internet-Draft, draft-ietf-emailcore-rfc5321bis-
03, 10 July 2021, <https://datatracker.ietf.org/doc/draft-klensin-
rfc5321bis/>.

[ID.RFC5322bis] <https://www.ietf.org/archive/id/draft-
ietf-emailcore-rfc5321bis-03.txt>.

[I-D.ietf-emailcore-rfc5322bis]
Resnick, P., P. W., "Internet Message Format", Work in
Progress, Internet-Draft, draft-ietf-emailcore-rfc5322bis-
01, 29 March 2021,
<https://datatracker.ietf.org/doc/draft-resnick-
rfc5322bis/>. <https://www.ietf.org/archive/id/draft-
ietf-emailcore-rfc5322bis-01.txt>.

[RFC0822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822,
August 1982, <https://www.rfc-editor.org/info/rfc822>.

[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
Mail Extensions): Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1341,
DOI 10.17487/RFC1341, June 1992,
<https://www.rfc-editor.org/info/rfc1341>.

[RFC1425] Klensin, J., Freed, N., Ed., Rose, M., Stefferud, E., and
D. Crocker, "SMTP Service Extensions", February 1993,
<https://www.rfc-editor.org/info/rfc1425>.

[RFC2821] Klensin, J., Ed., "Simple Mail Transfer Protocol",
RFC 2821, DOI 10.17487/RFC2821, April 2001,
<https://www.rfc-editor.org/info/rfc2821>.

[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
DOI 10.17487/RFC2822, April 2001,
<https://www.rfc-editor.org/info/rfc2822>.

[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.

[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.

[RFC6648] Saint-Andre, P., Nottingham, N., Ed., and D. Crocker,
"Deprecating the "X-" Prefix

[RFC7085] Levine, J. and Similar Constructs in
Application Protocols", June 2012,
<https://www.rfc-editor.org/info/rfc6648>. P. Hoffman, "Top-Level Domains That Are
Already Dotless", RFC 7085, DOI 10.17487/RFC7085, December
2013, <https://www.rfc-editor.org/info/rfc7085>.

Appendix A. Change Log

RFC Editor: Please remove this appendix before publication.

A.1. Changes from draft-klensin-email-core-as-00 (2020-03-30) to draft-
ietf-emailcore-as-00

* Change of filename, metadata, and date to reflect transition to WG
document for new emailcore WG. No other substantive changes

A.2. Changes from draft-ietf-emailcore-as-00 (2020-10-06) to -01

* Added co-authors (list is in alphabetical order for the present).

* Updated references to 5321bis and 5322bis.

* Added note at top, "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", which should be removed for
version -02.

A.3. Changes from draft-ietf-emailcore-as-01 (2021-04-09) to -02

* Added new editors and also added some issues the emailcore group
will be dealing with.

* 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

John C Klensin (editor)
1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140
USA
United States of America

Phone: +1 617 245 1457
Email: john-ietf@jck.com

Kenneth Murchison (editor)
Fastmail US LLC
1429 Walnut Street - Suite 1201
Philadelphia, PA 19102
USA
United States of America

Email: murch@fastmailteam.com
E Sam (editor)

Email: winshell64@gmail.com