draft-ietf-uta-smtp-require-tls-02.txt | draft-ietf-uta-smtp-require-tls-03.txt | |||
---|---|---|---|---|
Internet Engineering Task Force J. Fenton | Internet Engineering Task Force J. Fenton | |||
Internet-Draft Altmode Networks | Internet-Draft Altmode Networks | |||
Intended status: Standards Track April 6, 2018 | Intended status: Standards Track June 22, 2018 | |||
Expires: October 8, 2018 | Expires: December 24, 2018 | |||
SMTP Require TLS Option | SMTP Require TLS Option | |||
draft-ietf-uta-smtp-require-tls-02 | draft-ietf-uta-smtp-require-tls-03 | |||
Abstract | Abstract | |||
The SMTP STARTTLS option, used in negotiating transport-level | The SMTP STARTTLS option, used in negotiating transport-level | |||
encryption of SMTP connections, is not as useful from a security | encryption of SMTP connections, is not as useful from a security | |||
standpoint as it might be because of its opportunistic nature; | standpoint as it might be because of its opportunistic nature; | |||
message delivery is, by default, prioritized over security. This | message delivery is, by default, prioritized over security. This | |||
document describes an SMTP service extension, REQUIRETLS, and message | document describes an SMTP service extension, REQUIRETLS, and message | |||
header field, RequireTLS. If the REQUIRETLS option or RequireTLS | header field, RequireTLS. If the REQUIRETLS option or RequireTLS | |||
message header field is used when sending a message, it asserts a | message header field is used when sending a message, it asserts a | |||
skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
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 October 8, 2018. | This Internet-Draft will expire on December 24, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are 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 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 3 | 2. The REQUIRETLS Service Extension . . . . . . . . . . . . . . 4 | |||
3. The RequireTLS Header Field . . . . . . . . . . . . . . . . . 4 | 3. The RequireTLS Header Field . . . . . . . . . . . . . . . . . 4 | |||
4. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 5 | 4. REQUIRETLS Semantics . . . . . . . . . . . . . . . . . . . . 5 | |||
4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 5 | 4.1. REQUIRETLS Receipt Requirements . . . . . . . . . . . . . 5 | |||
4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 5 | 4.2. REQUIRETLS Sender Requirements . . . . . . . . . . . . . 5 | |||
4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 5 | 4.2.1. Sending with TLS Required . . . . . . . . . . . . . . 5 | |||
4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 6 | 4.2.2. Sending with TLS Optional . . . . . . . . . . . . . . 6 | |||
4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 7 | 4.3. REQUIRETLS Submission . . . . . . . . . . . . . . . . . . 7 | |||
4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 7 | 4.4. Delivery of REQUIRETLS messages . . . . . . . . . . . . . 7 | |||
5. Non-delivery message handling . . . . . . . . . . . . . . . . 7 | 5. Non-delivery message handling . . . . . . . . . . . . . . . . 7 | |||
6. Mailing list considerations . . . . . . . . . . . . . . . . . 8 | 6. Mailing list considerations . . . . . . . . . . . . . . . . . 8 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 9 | 8.1. Passive attacks . . . . . . . . . . . . . . . . . . . . . 10 | |||
8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 9 | 8.2. Active attacks . . . . . . . . . . . . . . . . . . . . . 10 | |||
8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 10 | 8.3. Bad Actor MTAs . . . . . . . . . . . . . . . . . . . . . 10 | |||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10. Revision History . . . . . . . . . . . . . . . . . . . . . . 10 | 10. Revision History . . . . . . . . . . . . . . . . . . . . . . 11 | |||
10.1. Changes since -01 Draft . . . . . . . . . . . . . . . . 10 | 10.1. Changes since -02 Draft . . . . . . . . . . . . . . . . 11 | |||
10.2. Changes since -00 Draft . . . . . . . . . . . . . . . . 10 | 10.2. Changes since -01 Draft . . . . . . . . . . . . . . . . 11 | |||
10.3. Changes since fenton-03 Draft . . . . . . . . . . . . . 11 | 10.3. Changes since -00 Draft . . . . . . . . . . . . . . . . 11 | |||
10.4. Changes Since -02 Draft . . . . . . . . . . . . . . . . 11 | 10.4. Changes since fenton-03 Draft . . . . . . . . . . . . . 11 | |||
10.5. Changes Since -01 Draft . . . . . . . . . . . . . . . . 11 | 10.5. Changes Since -02 Draft . . . . . . . . . . . . . . . . 12 | |||
10.6. Changes Since -00 Draft . . . . . . . . . . . . . . . . 11 | 10.6. Changes Since -01 Draft . . . . . . . . . . . . . . . . 12 | |||
10.7. Changes Since -00 Draft . . . . . . . . . . . . . . . . 12 | ||||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 13 | 11.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
1. Introduction | 1. Introduction | |||
The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a | The SMTP [RFC5321] STARTTLS service extension [RFC3207] provides a | |||
means by which an SMTP server and client can establish a Transport | means by which an SMTP server and client can establish a Transport | |||
Layer Security (TLS) protected session for the transmission of email | Layer Security (TLS) protected session for the transmission of email | |||
messages. By default, TLS is used only upon mutual agreement | messages. By default, TLS is used only upon mutual agreement | |||
(successful negotiation) of STARTTLS between the client and server; | (successful negotiation) of STARTTLS between the client and server; | |||
if this is not possible, the message is sent without transport | if this is not possible, the message is sent without transport | |||
encryption. Furthermore, it is common practice for the client to | encryption. Furthermore, it is common practice for the client to | |||
skipping to change at page 7, line 47 ¶ | skipping to change at page 7, line 51 ¶ | |||
with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS | with the REQUIRETLS SMTP option, whether resulting from a REQUIRETLS | |||
error or some other, MUST also specify the REQUIRETLS SMTP option | error or some other, MUST also specify the REQUIRETLS SMTP option | |||
unless redacted as described below. | unless redacted as described below. | |||
The path from the origination of an error bounce message back to the | The path from the origination of an error bounce message back to the | |||
MAIL FROM address may not share the same REQUIRETLS support as the | MAIL FROM address may not share the same REQUIRETLS support as the | |||
forward path. Therefore, users requiring TLS are advised to make | forward path. Therefore, users requiring TLS are advised to make | |||
sure that they are capable of receiving mail using REQUIRETLS as | sure that they are capable of receiving mail using REQUIRETLS as | |||
well. Otherwise, such non-delivery messages will be lost. | well. Otherwise, such non-delivery messages will be lost. | |||
If unable to send a bounce message due to a REQUIRETLS failure (the | If a REQUIRETLS message is bounced, the server MUST behave as if | |||
return path not supporting the TLS requirements in the original | RET=HDRS was present as described in [RFC3461]. If both RET=FULL and | |||
message), the MTA sending the bounce message MAY send a redacted non- | REQUIRETLS are present, the RET=FULL MUST be disregarded and MAY be | |||
delivery message to the postmaster of the domain identified in the | transformed to RET=HDRS on relay. The SMTP client for a REQUIRETLS | |||
envelope-From address identifying the message only by Message-ID and | bounce message MUST use an empty MAIL FROM return-path as required by | |||
indicating the type of failure. The original From, Return-path, To, | [RFC5321]. When the MAIL FROM return-path is empty, the REQUIRETLS | |||
Sender, Cc, and related header fields MUST NOT be included in this | parameter SHOULD NOT cause a bounce message to be discarded even if | |||
message. | the next-hop relay does not advertise REQUIRETLS. | |||
Senders of messages requiring TLS are advised to consider the | Senders of messages requiring TLS are advised to consider the | |||
increased likelihood that bounce messages will be lost as a result of | possibility that bounce messages will be lost as a result of | |||
REQUIRETLS return path failure. | REQUIRETLS return path failure, and that some information could be | |||
leaked if a bounce message is not able to be transmitted with | ||||
REQUIRETLS. | ||||
6. Mailing list considerations | 6. Mailing list considerations | |||
Mailing lists, upon receipt of a message, originate new messages to | Mailing lists, upon receipt of a message, originate new messages to | |||
list addresses. This is distinct from an aliasing operation that | list addresses. This is distinct from an aliasing operation that | |||
redirects the original message, in some cases to multiple recipients. | redirects the original message, in some cases to multiple recipients. | |||
The requirement to preserve the REQUIRETLS tag therefore does not | The requirement to preserve the REQUIRETLS tag therefore does not | |||
necessarily extend to mailing lists, although the inclusion of the | necessarily extend to mailing lists, although the inclusion of the | |||
RequireTLS header field MAY cause messages sent to mailing lists to | RequireTLS header field MAY cause messages sent to mailing lists to | |||
inherit this characteristic. REQUIRETLS users SHOULD be made aware | inherit this characteristic. REQUIRETLS users SHOULD be made aware | |||
skipping to change at page 8, line 32 ¶ | skipping to change at page 8, line 38 ¶ | |||
list operator to list members. | list operator to list members. | |||
Mailing list operators MAY apply REQUIRETLS requirements in incoming | Mailing list operators MAY apply REQUIRETLS requirements in incoming | |||
messages to the resulting messages they originate. If this is done, | messages to the resulting messages they originate. If this is done, | |||
they SHOULD also apply these requirements to administrative traffic, | they SHOULD also apply these requirements to administrative traffic, | |||
such as messages to moderators requesting approval of messages. | such as messages to moderators requesting approval of messages. | |||
7. IANA Considerations | 7. IANA Considerations | |||
If published as an RFC, this draft requests the addition of the | If published as an RFC, this draft requests the addition of the | |||
keyword REQUIRETLS to the SMTP Service Extensions Registry | following keyword to the SMTP Service Extensions Registry | |||
[MailParams]. | [MailParams]: | |||
Textual name: RequireTLS | ||||
EHLO keyword value: REQUIRETLS | ||||
Syntax and parameters: (no parameters) | ||||
Additional SMTP verbs: none | ||||
MAIL and RCPT parameters: REQUIRETLS parameter on MAIL | ||||
Behavior: Use of the REQUIRETLS parameter on the | ||||
MAIL verb causes that message to require | ||||
the use of TLS and tagging with REQUIRETLS | ||||
for all onward relay. | ||||
Command length increment: 11 characters | ||||
If published as an RFC, this draft requests the addition of an entry | If published as an RFC, this draft requests the addition of an entry | |||
to the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes | to the Simple Mail Transfer Protocol (SMTP) Enhanced Status Codes | |||
Registry [SMTPStatusCodes] in the 5.7.YYY range to indicate lack of | Registry [SMTPStatusCodes]: | |||
REQUIRETLS support by an SMTP server to which a message is being | ||||
routed. | ||||
If published as an RFC, this draft requests the addition of the | Code: 5.7.YYY | |||
header field name RequireTLS to the Permanent Message Header Field | Sample Text: REQUIRETLS support required | |||
Names Registry [PermMessageHeaderFields]. | Associated basic status code: 530 | |||
Description: This indicates that the message was not | ||||
able to be forwarded because it was | ||||
received with a REQUIRETLS requirement | ||||
and none of the SMTP servers to which | ||||
the message should be forwarded provide | ||||
this support. | ||||
Reference: (this document) | ||||
Submitter: J. Fenton | ||||
Change controller: IESG | ||||
This section is to be removed during conversion into an RFC by the | If published as an RFC, this draft requests the addition of an entry | |||
RFC Editor. | to the Permanent Message Header Field Names Registry | |||
[PermMessageHeaderFields]: | ||||
Header field name: RequireTLS | ||||
Applicable protocol: mail | ||||
Status: provisional | ||||
Author/change controller: IETF UTA Working Group | ||||
Specification document: (this document) | ||||
This section is to be updated for publication by the RFC Editor. | ||||
8. Security Considerations | 8. Security Considerations | |||
The purpose of REQUIRETLS is to improve communications security for | The purpose of REQUIRETLS is to improve communications security for | |||
email by giving the originator of a message an expectation that it | email by giving the originator of a message an expectation that it | |||
will be transmitted in an encrypted form "over the wire". When used, | will be transmitted in an encrypted form "over the wire". When used, | |||
REQUIRETLS changes the traditional behavior of email transmission, | REQUIRETLS changes the traditional behavior of email transmission, | |||
which favors delivery over the ability to send email messages using | which favors delivery over the ability to send email messages using | |||
transport-layer security, to one in which requested security takes | transport-layer security, to one in which requested security takes | |||
precedence over delivery and domain-level policy. | precedence over delivery and domain-level policy. | |||
skipping to change at page 10, line 25 ¶ | skipping to change at page 11, line 9 ¶ | |||
security protocol, messages sent using REQUIRETLS are not encrypted | security protocol, messages sent using REQUIRETLS are not encrypted | |||
end-to-end and are visible to MTAs that are part of the message | end-to-end and are visible to MTAs that are part of the message | |||
delivery path. Messages containing sensitive information that MTAs | delivery path. Messages containing sensitive information that MTAs | |||
should not have access to MUST be sent using end-to-end content | should not have access to MUST be sent using end-to-end content | |||
encryption such as OpenPGP [RFC4880] or S/MIME [RFC5751]. | encryption such as OpenPGP [RFC4880] or S/MIME [RFC5751]. | |||
9. Acknowledgements | 9. Acknowledgements | |||
The author would like to acknowledge many helpful suggestions on the | The author would like to acknowledge many helpful suggestions on the | |||
ietf-smtp and uta mailing lists, in particular those of Viktor | ietf-smtp and uta mailing lists, in particular those of Viktor | |||
Dukhovni, Tony Finch, Jeremy Harris, Arvel Hathcock, John Klensin, | Dukhovni, Chris Newman, Tony Finch, Jeremy Harris, Arvel Hathcock, | |||
John Levine, Rolf Sonneveld, and Per Thorsheim. | John Klensin, John Levine, Rolf Sonneveld, and Per Thorsheim. | |||
10. Revision History | 10. Revision History | |||
To be removed by RFC Editor upon publication as an RFC. | To be removed by RFC Editor upon publication as an RFC. | |||
10.1. Changes since -01 Draft | 10.1. Changes since -02 Draft | |||
o More complete documentation for IANA registration requests. | ||||
o Changed bounce handling to use RET parameters of RFC 3461, along | ||||
with slightly more liberal transmission of bounces even if | ||||
REQUIRETLS can't be negotiated. | ||||
10.2. Changes since -01 Draft | ||||
o Converted DEEP references to RFC 8314. | o Converted DEEP references to RFC 8314. | |||
o Removed REQUIRETLS options: CHAIN, DANE, and DNSSEC. | o Removed REQUIRETLS options: CHAIN, DANE, and DNSSEC. | |||
o Editorial corrections, notably making the header field name | o Editorial corrections, notably making the header field name | |||
consistent (RequireTLS rather than Require-TLS). | consistent (RequireTLS rather than Require-TLS). | |||
10.2. Changes since -00 Draft | 10.3. Changes since -00 Draft | |||
o Created new header field, Require-TLS, for use by "NO" option. | o Created new header field, Require-TLS, for use by "NO" option. | |||
o Removed "NO" option from SMTP service extension. | o Removed "NO" option from SMTP service extension. | |||
o Recommend DEEP requirements for delivery of messages requiring | o Recommend DEEP requirements for delivery of messages requiring | |||
TLS. | TLS. | |||
o Assorted copy edits | o Assorted copy edits | |||
10.3. Changes since fenton-03 Draft | 10.4. Changes since fenton-03 Draft | |||
o Wording improvements from Rolf Sonneveld review 22 July 2017 | o Wording improvements from Rolf Sonneveld review 22 July 2017 | |||
o A few copy edits | o A few copy edits | |||
o Conversion from individual to UTA WG draft | o Conversion from individual to UTA WG draft | |||
10.4. Changes Since -02 Draft | 10.5. Changes Since -02 Draft | |||
o Incorporation of "MAY TLS" functionality as REQUIRETLS=NO per | o Incorporation of "MAY TLS" functionality as REQUIRETLS=NO per | |||
suggestion on UTA WG mailing list. | suggestion on UTA WG mailing list. | |||
o Additional guidance on bounce messages | o Additional guidance on bounce messages | |||
10.5. Changes Since -01 Draft | 10.6. Changes Since -01 Draft | |||
o Specified retries when multiple MX hosts exist for a given domain. | o Specified retries when multiple MX hosts exist for a given domain. | |||
o Clarified generation of non-delivery messages | o Clarified generation of non-delivery messages | |||
o Specified requirements for application of REQUIRETLS to mail | o Specified requirements for application of REQUIRETLS to mail | |||
forwarders and mailing lists. | forwarders and mailing lists. | |||
o Clarified DNSSEC requirements to include MX lookup only. | o Clarified DNSSEC requirements to include MX lookup only. | |||
o Corrected terminology regarding message retrieval vs. delivery. | o Corrected terminology regarding message retrieval vs. delivery. | |||
o Changed category to standards track. | o Changed category to standards track. | |||
10.6. Changes Since -00 Draft | 10.7. Changes Since -00 Draft | |||
o Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM | o Conversion of REQUIRETLS from an SMTP verb to a MAIL FROM | |||
parameter to better associate REQUIRETLS requirements with | parameter to better associate REQUIRETLS requirements with | |||
transmission of individual messages. | transmission of individual messages. | |||
o Addition of an option to require DNSSEC lookup of the remote mail | o Addition of an option to require DNSSEC lookup of the remote mail | |||
server, since this affects the common name of the certificate that | server, since this affects the common name of the certificate that | |||
is presented. | is presented. | |||
o Clarified the wording to more clearly state that TLS sessions must | o Clarified the wording to more clearly state that TLS sessions must | |||
skipping to change at page 12, line 29 ¶ | skipping to change at page 13, line 20 ¶ | |||
[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>. | |||
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | |||
Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, | Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, | |||
February 2002, <https://www.rfc-editor.org/info/rfc3207>. | February 2002, <https://www.rfc-editor.org/info/rfc3207>. | |||
[RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service | ||||
Extension for Delivery Status Notifications (DSNs)", | ||||
RFC 3461, DOI 10.17487/RFC3461, January 2003, | ||||
<https://www.rfc-editor.org/info/rfc3461>. | ||||
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced | [RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced | |||
Mail System Status Codes", BCP 138, RFC 5248, | Mail System Status Codes", BCP 138, RFC 5248, | |||
DOI 10.17487/RFC5248, June 2008, | DOI 10.17487/RFC5248, June 2008, | |||
<https://www.rfc-editor.org/info/rfc5248>. | <https://www.rfc-editor.org/info/rfc5248>. | |||
[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>. | |||
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | |||
skipping to change at page 13, line 21 ¶ | skipping to change at page 14, line 21 ¶ | |||
Internet Assigned Numbers Authority (IANA), "Simple Mail | Internet Assigned Numbers Authority (IANA), "Simple Mail | |||
Transfer Protocol (SMTP) Enhanced Status Codes Registry", | Transfer Protocol (SMTP) Enhanced Status Codes Registry", | |||
2008, <http://www.iana.org/assignments/ | 2008, <http://www.iana.org/assignments/ | |||
smtp-enhanced-status-codes>. | smtp-enhanced-status-codes>. | |||
11.2. Informative References | 11.2. Informative References | |||
[I-D.ietf-uta-mta-sts] | [I-D.ietf-uta-mta-sts] | |||
Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., | Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., | |||
and J. Jones, "SMTP MTA Strict Transport Security (MTA- | and J. Jones, "SMTP MTA Strict Transport Security (MTA- | |||
STS)", draft-ietf-uta-mta-sts-15 (work in progress), April | STS)", draft-ietf-uta-mta-sts-21 (work in progress), June | |||
2018. | 2018. | |||
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | |||
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, | STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, | |||
<https://www.rfc-editor.org/info/rfc1939>. | <https://www.rfc-editor.org/info/rfc1939>. | |||
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | |||
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | |||
<https://www.rfc-editor.org/info/rfc3501>. | <https://www.rfc-editor.org/info/rfc3501>. | |||
End of changes. 23 change blocks. | ||||
46 lines changed or deleted | 88 lines changed or added | |||
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |