Skip to content

Start of emailcore-as-27 (IETF LC comments) #5

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ksmurchison wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Start of emailcore-as-27 (IETF LC comments) #5

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 35 additions & 15 deletions draft-ietf-emailcore-as.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@
<?rfc subcompact="no" ?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
docName="draft-ietf-emailcore-as-26"
docName="draft-ietf-emailcore-as-27"
ipr="trust200902"
category="std"
obsoletes=""
Expand All @@ -41,7 +41,7 @@
<front>
<title abbrev="Core Email A/S">Applicability Statement for IETF
Core Email Protocols</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-emailcore-as-26"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-emailcore-as-27"/>

<author fullname="John C Klensin" initials="J.C."
surname="Klensin" role="editor">
Expand Down Expand Up @@ -182,7 +182,7 @@
<section numbered="true" toc="default">
<name>Handling of the Domain Argument to the EHLO Command</name>
<t> If the <tt>Domain</tt> argument to
the EHLO command does not have an address record in the
the EHLO command does not have an address (A/AAAA) 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.
Expand Down Expand Up @@ -328,10 +328,11 @@

<section numbered="true" toc="default">
<name>Generation</name>
<t>Email addresses are commonly classified as Personally
Identifiable Information (PII). Improper application of the
FOR clause in Received header fields can result in disclosure
of PII. As such, the FOR clause SHOULD NOT be generated if the
<t>Email addresses are commonly classified as Personal Data
(see <xref target="RFC6973" section="3.2"/>).
Improper application of the FOR clause in Received header
fields can result in disclosure of personal data.
As such, the FOR clause SHOULD NOT be generated if the
message copy is associated with multiple recipients from
multiple SMTP RCPT commands.
Otherwise, the value of the FOR clause MUST contain the RCPT
Expand Down Expand Up @@ -516,9 +517,9 @@

<t>Email addresses are frequently used as input to, or
validated by, forms managed by various libraries, some
tied to Versions of HyperText Markup Language (HTML) or
tied to versions of HyperText Markup Language (HTML) or
other specs and others to client-side libraries developed
in Javascript or other languages.
in JavaScript or other languages.
In some cases, those who define or supply those systems
may have found and corrected errors long ago, but old
versions or interpretations are still in use. The allowed
Expand Down Expand Up @@ -629,7 +630,7 @@

<ul spacing="normal">
<li>
<xref target="RFC8446">TLS</xref>,
<xref target="TLS">TLS</xref>,
<xref target="RFC3207">STARTTLS</xref>,
<xref target="RFC8689">Require TLS</xref>,
<xref target="RFC8461">MTA-STS</xref>, and
Expand Down Expand Up @@ -674,7 +675,7 @@
<name>Security at the Transport Layer</name>
<t>The Internet email environment has evolved over the years so that
the SMTP protocol itself can be used in conjunction with
<xref target="RFC8446">Transport Layer Security (TLS)</xref>
<xref target="TLS">Transport Layer Security (TLS)</xref>
protocol
to provide both confidentiality and server authentication in the
transmission of messages.</t>
Expand All @@ -683,7 +684,7 @@
the terms "Authentication" and "Confidentiality" in this
context, and for that
we will borrow directly from the TLS specification
<xref target="RFC8446"/> (although the pointers to other
<xref target="TLS"/> (although the pointers to other
sections given are to this document).
</t>

Expand All @@ -710,7 +711,7 @@

<section anchor="tls" numbered="true" toc="default">
<name> The TLS Protocol </name>
<t>The TLS Protocol <xref target="RFC8446"/>
<t>The TLS Protocol <xref target="TLS"/>
provides confidentiality while the message is in
transit from an SMTP client to the next SMTP server.
Both client and server will have access to the plain
Expand Down Expand Up @@ -741,7 +742,7 @@
<t>Opportunistic TLS is optional confidentiality due
to provision for falling back to
transmission in the clear if
a secure connection cannot be established.
a TLS_protected connection cannot be established.
Opportunistic TLS is often configured to provide
confidentiality without authentication, where no effort is
made to authenticate the receiving server
Expand Down Expand Up @@ -858,6 +859,8 @@
SMTP AUTH is for a person to present a username and password
to their mailbox provider's outbound SMTP server when
configuring their MUA for sending mail.</t>
<t>Credentials MUST NOT be sent without TLS, and deployments
should require use of TLS with SMTP AUTH.</t>
<t>SMTP AUTH MAY be used to limit unauthorized use of VRFY and
EXPN commands as described in
<xref target="I-D.ietf-emailcore-rfc5321bis" section="7.3"/>.</t>
Expand Down Expand Up @@ -986,7 +989,6 @@
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8617.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8461.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7672.xml"/>
Expand All @@ -997,6 +999,7 @@
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6522.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3464.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8689.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3207.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6854.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-emailcore-rfc5321bis.xml"/>
Expand All @@ -1019,6 +1022,12 @@
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6532.xml"/>
</referencegroup>

<referencegroup anchor="TLS">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9325.xml"/>
</referencegroup>


<reference anchor="SMTP-IANA-cleanup"
target="https://datatracker.ietf.org/doc/draft-ietf-emailcore-iana-cleanup/">
<front>
Expand Down Expand Up @@ -1442,6 +1451,17 @@
</ul>
</section>

<section numbered="true" toc="default">
<name>Changes from draft-ietf-emailcore-as-26 to -27</name>
<ul spacing="normal">
<li>Specified actual DNS address record types.</li>
<li>Changed PII to Personal Data with reference to RFC 6973.</li>
<li>Noted that SMTP AUTH should be used with TLS.</li>
<li>Added reference to RFC 9325.</li>
<li>Miscellaneous editoral changes.</li>
</ul>
</section>

</section>
</back>
</rfc>