draft-ietf-uta-email-tls-certs-07.txt | draft-ietf-uta-email-tls-certs-08.txt | |||
---|---|---|---|---|
Network Working Group A. Melnikov | Network Working Group A. Melnikov | |||
Internet-Draft Isode Ltd | Internet-Draft Isode Ltd | |||
Updates: 2595, 3207, 3501, 5804 (if December 9, 2015 | Updates: 2595, 3207, 3501, 5804 (if December 17, 2015 | |||
approved) | approved) | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: June 11, 2016 | Expires: June 19, 2016 | |||
Updated TLS Server Identity Check Procedure for Email Related Protocols | Updated TLS Server Identity Check Procedure for Email Related Protocols | |||
draft-ietf-uta-email-tls-certs-07 | draft-ietf-uta-email-tls-certs-08 | |||
Abstract | Abstract | |||
This document describes TLS server identity verification procedure | This document describes TLS server identity verification procedure | |||
for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces | for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces | |||
Section 2.4 of RFC 2595, updates Section 4.1 of RFC 3207, updates | Section 2.4 of RFC 2595, updates Section 4.1 of RFC 3207, updates | |||
Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804. | Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 June 11, 2016. | This Internet-Draft will expire on June 19, 2016. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 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 | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://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 | |||
skipping to change at page 2, line 18 | skipping to change at page 2, line 18 | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 | 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 | |||
3. Email Server Certificate Verification Rules . . . . . . . . . 3 | 3. Email Server Certificate Verification Rules . . . . . . . . . 3 | |||
4. Compliance Checklist for Certification Authorities . . . . . 5 | 4. Compliance Checklist for Certification Authorities . . . . . 5 | |||
4.1. Notes on handling of SRV-ID by Certification Authorities 5 | 4.1. Notes on handling of SRV-ID by Certification Authorities 5 | |||
5. Compliance Checklist for Mail Service Providers and | 5. Compliance Checklist for Mail Service Providers and | |||
Certificate Signing Request generation tools . . . . . . . . 6 | Certificate Signing Request generation tools . . . . . . . . 6 | |||
5.1. Notes on hosting multiple domains . . . . . . . . . . . . 6 | 5.1. Notes on hosting multiple domains . . . . . . . . . . . . 6 | |||
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 7. Operational Considerations . . . . . . . . . . . . . . . . . 8 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 10 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 | 10.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 11 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 | Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 12 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
1. Introduction | 1. Introduction | |||
Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is | Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is | |||
described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804] | described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804] | |||
respectively. Each of the documents describes slightly different | respectively. Each of the documents describes slightly different | |||
rules for server certificate identity verification (or doesn't define | rules for server certificate identity verification (or doesn't define | |||
any rules at all). In reality, email client and server developers | any rules at all). In reality, email client and server developers | |||
implement many of these protocols at the same time, so it would be | implement many of these protocols at the same time, so it would be | |||
good to define modern and consistent rules for verifying email server | good to define modern and consistent rules for verifying email server | |||
identities using TLS. | identities using TLS. | |||
This document describes the updated TLS server identity verification | This document describes the updated TLS server identity verification | |||
procedure for SMTP Submission [RFC6409] [RFC3207], IMAP [RFC3501], | procedure for SMTP Submission [RFC6409] [RFC3207], IMAP [RFC3501], | |||
POP [RFC1939] and ManageSieve [RFC5804] clients. It replaces | POP [RFC1939] and ManageSieve [RFC5804] clients. Section 3 of this | |||
Section 2.4 of RFC 2595. | document replaces Section 2.4 of [RFC2595]. | |||
Note that this document doesn't apply to use of TLS in MTA-to-MTA | Note that this document doesn't apply to use of TLS in MTA-to-MTA | |||
SMTP. | SMTP. | |||
This document provides a consistent TLS server identity verification | This document provides a consistent TLS server identity verification | |||
procedure across multiple email related protocols. This should make | procedure across multiple email related protocols. This should make | |||
it easier for Certification Authorities and ISPs to deploy TLS for | it easier for Certification Authorities and ISPs to deploy TLS for | |||
email use, and would enable email client developers to write more | email use, and would enable email client developers to write more | |||
secure code. | secure code. | |||
2. Conventions Used in This Document | 2. Conventions Used in This Document | |||
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 [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
The following terms or concepts are used through the document: | The following terms or concepts are used through the document: | |||
reference identifier: (as defined in [RFC6125]) One of the domain | reference identifier: (formally defined in [RFC6125]) One of the | |||
names associated by the email (i.e., an SMTP, IMAP, POP3 or | domain names that the email client (an SMTP, IMAP, POP3 or | |||
ManageSieve) client with the target email server and optionally an | ManageSieve client) associates with the target email server. For | |||
some identifier types, the identifier can also include an | ||||
application service type for performing name checks on the server | application service type for performing name checks on the server | |||
certificate. When name checks are applicable, at least one of the | certificate. When name checks are applicable, at least one of the | |||
reference identifiers MUST match an [RFC6125] DNS-ID or SRV-ID (or | reference identifiers MUST match an [RFC6125] DNS-ID or SRV-ID (or | |||
if none are present the [RFC6125] CN-ID) of the server | if none are present the [RFC6125] CN-ID) of the server | |||
certificate. | certificate. | |||
CN-ID, DNS-ID, SRV-ID and URI-ID are identifier types (see [RFC6125] | CN-ID, DNS-ID, SRV-ID and URI-ID are identifier types (see [RFC6125] | |||
for details). For convenience, their short definitions from | for details). For convenience, their short definitions from | |||
[RFC6125] are listed below: | [RFC6125] are listed below: | |||
skipping to change at page 4, line 42 | skipping to change at page 4, line 43 | |||
3. URI-ID identifier type (subjectAltName of | 3. URI-ID identifier type (subjectAltName of | |||
uniformResourceIdentifier type [RFC5280]) MUST NOT be used by | uniformResourceIdentifier type [RFC5280]) MUST NOT be used by | |||
clients for server verification, as URI-ID were not historically | clients for server verification, as URI-ID were not historically | |||
used for email. | used for email. | |||
4. For backward compatibility with deployed software CN-ID | 4. For backward compatibility with deployed software CN-ID | |||
identifier type (CN attribute from the subject name, see | identifier type (CN attribute from the subject name, see | |||
[RFC6125]) MAY be used for server identity verification. | [RFC6125]) MAY be used for server identity verification. | |||
5. Email protocols allow use of certain wilcards in identifiers | 5. Email protocols allow use of certain wildcards in identifiers | |||
presented by email servers. The "*" wildcard character MAY be | presented by email servers. The "*" wildcard character MAY be | |||
used as the left-most name component of DNS-ID or CN-ID in the | used as the left-most name component of DNS-ID or CN-ID in the | |||
certificate. For example, a DNS-ID of *.example.com would match | certificate. For example, a DNS-ID of *.example.com would match | |||
a.example.com, foo.example.com, etc. but would not match | a.example.com, foo.example.com, etc. but would not match | |||
example.com. Note that the wildcard character MUST NOT be used | example.com. Note that the wildcard character MUST NOT be used | |||
as a fragment of the left-most name component (e.g., | as a fragment of the left-most name component (e.g., | |||
*oo.example.com, f*o.example.com, or foo*.example.com). | *oo.example.com, f*o.example.com, or foo*.example.com). | |||
4. Compliance Checklist for Certification Authorities | 4. Compliance Checklist for Certification Authorities | |||
skipping to change at page 5, line 31 | skipping to change at page 5, line 31 | |||
4.1. Notes on handling of SRV-ID by Certification Authorities | 4.1. Notes on handling of SRV-ID by Certification Authorities | |||
[RFC6186] provides an easy way for organizations to autoconfigure | [RFC6186] provides an easy way for organizations to autoconfigure | |||
email clients. It also allows for delegation of email services to an | email clients. It also allows for delegation of email services to an | |||
email hosting provider. When connecting to such delegated hosting | email hosting provider. When connecting to such delegated hosting | |||
service an email client that attempts to verify TLS server identity | service an email client that attempts to verify TLS server identity | |||
needs to know that if it connects to imap.hosting.example.net that | needs to know that if it connects to imap.hosting.example.net that | |||
such server is authorized to provide email access for an email such | such server is authorized to provide email access for an email such | |||
as alice@example.org. In absence of SRV-IDs, users of compliant | as alice@example.org. In absence of SRV-IDs, users of compliant | |||
email clients would be forced to manual confirm exception, because | email clients would be forced to manually confirm exception, because | |||
TLS server certificate verification procedures specified in this | the TLS server certificate verification procedures specified in this | |||
document would result in failure to match TLS server certificate | document would result in failure to match the TLS server certificate | |||
against the expected domains. One way to provide such authorization | against the expected domain(s). One way to provide such | |||
is for the TLS certificate for imap.hosting.example.net to include | authorization is for the TLS certificate for imap.hosting.example.net | |||
SRV-ID(s) (or DNS-ID) for example.org domain. (Another way is for | to include SRV-ID(s) (or DNS-ID) for the example.org domain. | |||
SRV lookups to be protected by DNSSEC, but this solution depends | (Another way is for SRV lookups to be protected by DNSSEC, but this | |||
reliance of DNSSEC and thus is not discussed in this document. A | solution depends on DNSSEC and thus is not discussed in this | |||
future update to this document might rectify this.) | document. A future update to this document might rectify this.) | |||
The ability of issuing certificates that contain SRV-ID implies the | The ability to issue certificates that contain SRV-ID implies the | |||
ability to verify that entities requesting them are authorized to run | ability to verify that entities requesting them are authorized to run | |||
email service for these SRV-IDs. In particular, certification | email service for these SRV-IDs. In particular, certification | |||
authorities that can't verify such authorization MUST NOT include | authorities that can't verify such authorization MUST NOT include | |||
email SRV-IDs in certificates they issue. This document doesn't | email SRV-IDs in certificates they issue. This document doesn't | |||
specify exact mechanism(s) that can be used to achieve this. | specify exact mechanism(s) that can be used to achieve this. | |||
However, a few special case recommendations are listed below. | However, a few special case recommendations are listed below. | |||
A certification authority willing to sign a certificate containing a | A certification authority willing to sign a certificate containing a | |||
particular DNS-ID SHOULD also support signing a certificate | particular DNS-ID SHOULD also support signing a certificate | |||
containing one or more of email SRV-IDs for the same domain, because | containing one or more of email SRV-IDs for the same domain, because | |||
the SRV-ID effectively provides more restricted access to an email | the SRV-ID effectively provides more restricted access to an email | |||
service for the domain (as opposed to unrestricted use of any | service for the domain (as opposed to unrestricted use of any | |||
services for the same domain, as specified by DNS-ID). | services for the same domain, as specified by DNS-ID). | |||
A certification authority which also provides DNS service for a | A certification authority which also provides DNS service for a | |||
domain can use DNS information to validate SRV-IDs for the domain. | domain can use DNS information to validate SRV-IDs for the domain. | |||
A certification authority MAY treat a certificate for a subdomain of | ||||
example.com (e.g. imap.sub1.example.com or imap.example.com) that | ||||
contains one or more SRV-ID for example.com as validated. | ||||
5. Compliance Checklist for Mail Service Providers and Certificate | 5. Compliance Checklist for Mail Service Providers and Certificate | |||
Signing Request generation tools | Signing Request generation tools | |||
1. MUST include the DNS-ID identifier type in Certificate Signing | 1. MUST include the DNS-ID identifier type in Certificate Signing | |||
Requests for the host name(s) where the email server(s) are | Requests for the host name(s) where the email server(s) are | |||
running. SHOULD include the DNS-ID identifier type in | running. SHOULD include the DNS-ID identifier type in | |||
Certificate Signing Requests for the domain portion of served | Certificate Signing Requests for the domain portion of served | |||
email addresses. | email addresses. | |||
2. If the email services provided are discoverable using DNS SRV as | 2. If the email services provided are discoverable using DNS SRV as | |||
skipping to change at page 6, line 45 | skipping to change at page 6, line 41 | |||
CN-ID can be used). | CN-ID can be used). | |||
4. MAY include "*" (wildcard) as the left-most name component of | 4. MAY include "*" (wildcard) as the left-most name component of | |||
DNS-ID or CN-ID in Certificate Signing Requests. | DNS-ID or CN-ID in Certificate Signing Requests. | |||
5.1. Notes on hosting multiple domains | 5.1. Notes on hosting multiple domains | |||
A server that hosts multiple domains needs to do one of the following | A server that hosts multiple domains needs to do one of the following | |||
(or some combination thereof): | (or some combination thereof): | |||
1. Use a single TLS certificate that includes a complete list of all | 1. Use DNS SRV records to redirect each hosted email service to a | |||
fixed domain, deploy TLS certificate(s) for that single domain, | ||||
and instruct users to configure their clients with appropriate | ||||
pinning (unless the SRV records can always be obtained via | ||||
DNSSEC). Some email clients come with preloaded list of pinned | ||||
certificates for some popular domains, which can avoid the need | ||||
for manual confirmation. | ||||
2. Use a single TLS certificate that includes a complete list of all | ||||
the domains it is serving. | the domains it is serving. | |||
2. Serve each domain on its own IP/port, using separate TLS | 3. Serve each domain on its own IP/port, using separate TLS | |||
certificates on each IP/port. | certificates on each IP/port. | |||
3. Use Server Name Indication (SNI) TLS extension [RFC6066] to | 4. Use Server Name Indication (SNI) TLS extension [RFC6066] to | |||
select the right certificate to return during TLS negotiation. | select the right certificate to return during TLS negotiation. | |||
Each domain has its own TLS certificate in this case. | Each domain has its own TLS certificate in this case. | |||
Each of these deployment choices have their scaling disadvantages | Each of these deployment choices have their scaling disadvantages | |||
when the list of domains changes. A single certificate (the first | when the list of domains changes. Use of DNS SRV without SRV-ID | |||
choice) requires that when a domain is added, then a new Certificate | requires manual confirmation from users. While preloading pinned | |||
Signing Request that includes a complete list of all the domains | certificates avoids the need for manual confirmation, this | |||
needs to be issued and passed to a CA in order to generate a new | information can get stale quickly or would require support for a new | |||
certificate. Separate IP/port can avoid regenerating the | mechanism for distributing preloaded pinned certificates. A single | |||
certificate, but requires more transport layer resources. Use of TLS | certificate (the second choice) requires that when a domain is added, | |||
SNI requires each email client to support it. | then a new Certificate Signing Request that includes a complete list | |||
of all the domains needs to be issued and passed to a CA in order to | ||||
generate a new certificate. Separate IP/port can avoid regenerating | ||||
the certificate, but requires more transport layer resources. Use of | ||||
TLS SNI requires each email client to support it. | ||||
Several Mail Service Providers host hundreds and even thousands of | Several Mail Service Providers host hundreds and even thousands of | |||
domain. This document, as well as its predecessors RFC 2595, RFC | domains. This document, as well as its predecessors RFC 2595, RFC | |||
3207, RFC 3501 and RFC 5804 don't address scaling issues caused by | 3207, RFC 3501 and RFC 5804 don't address scaling issues caused by | |||
use of TLS in multi-tenanted environments. Further work is needed to | use of TLS in multi-tenanted environments. Further work is needed to | |||
address this issue, possibly using DNSSEC or something like POSH | address this issue, possibly using DNSSEC or something like POSH | |||
[RFC7711]. | [RFC7711]. | |||
6. Examples | 6. Examples | |||
Consider an IMAP-accessible email server which supports both IMAP and | Consider an IMAP-accessible email server which supports both IMAP and | |||
IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email | IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email | |||
addresses of the form "user@example.net". A certificate for this | addresses of the form "user@example.net". A certificate for this | |||
skipping to change at page 8, line 29 | skipping to change at page 8, line 37 | |||
domain "example.net", which runs SMTP Submission, IMAPS and POP3S | domain "example.net", which runs SMTP Submission, IMAPS and POP3S | |||
(POP3-over-TLS) and ManageSieve services. Each of the servers can | (POP3-over-TLS) and ManageSieve services. Each of the servers can | |||
use their own certificate specific to their service (see examples | use their own certificate specific to their service (see examples | |||
above). Alternatively they can all share a single certificate that | above). Alternatively they can all share a single certificate that | |||
would include SRV-IDs of "_submission.example.net", | would include SRV-IDs of "_submission.example.net", | |||
"_imaps.example.net", "_pop3s.example.net" and "_sieve.example.net" | "_imaps.example.net", "_pop3s.example.net" and "_sieve.example.net" | |||
along with DNS-IDs of "example.net" and "mail.example.net". It might | along with DNS-IDs of "example.net" and "mail.example.net". It might | |||
also include CN-ID of "mail.example.net" for backward compatibility | also include CN-ID of "mail.example.net" for backward compatibility | |||
with deployed infrastructure. | with deployed infrastructure. | |||
7. IANA Considerations | 7. Operational Considerations | |||
Section 5 covers operational considerations (in particular use of DNS | ||||
SRV for autoconfiguration) related to generating TLS certificiates | ||||
for email servers so that they can be successfully verified by email | ||||
clients. Additionally, Section 5.1 talks about operational | ||||
considerations related to hosting multiple domains. | ||||
8. IANA Considerations | ||||
This document doesn't require any action from IANA. | This document doesn't require any action from IANA. | |||
8. Security Considerations | 9. Security Considerations | |||
The goal of this document is to improve interoperability and thus | The goal of this document is to improve interoperability and thus | |||
security of email clients wishing to access email servers over TLS | security of email clients wishing to access email servers over TLS | |||
protected email protocols, by specifying a consistent set of rules | protected email protocols, by specifying a consistent set of rules | |||
that email service providers, email client writers and Certification | that email service providers, email client writers and Certification | |||
Authorities can use when creating server certificates. | Authorities can use when creating server certificates. | |||
TLS Server Identity Check for Email relies on use of trustworthy DNS | TLS Server Identity Check for Email relies on use of trustworthy DNS | |||
hostnames when constructing "reference identifiers" that are checked | hostnames when constructing "reference identifiers" that are checked | |||
against an email server certificate. Such trustworthy names are | against an email server certificate. Such trustworthy names are | |||
either entered manually (for example if they are advertised on a Mail | either entered manually (for example if they are advertised on a Mail | |||
Service Provider's website), explicitly confirmed by the user (e.g. | Service Provider's website), explicitly confirmed by the user (e.g. | |||
if they are a target of a DNS SRV lookup) or derived using a secure | if they are a target of a DNS SRV lookup) or derived using a secure | |||
third party service (e.g. DNSSEC-protected SRV records which are | third party service (e.g. DNSSEC-protected SRV records which are | |||
verified by the client or trusted local resolver). Future work in | verified by the client or trusted local resolver). Future work in | |||
this area might benefit from integration with DANE [RFC6698], but it | this area might benefit from integration with DANE [RFC6698], but it | |||
is not covered by this document. | is not covered by this document. | |||
9. References | 10. References | |||
9.1. Normative References | 10.1. Normative References | |||
[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, | |||
<http://www.rfc-editor.org/info/rfc1939>. | <http://www.rfc-editor.org/info/rfc1939>. | |||
[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, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
skipping to change at page 10, line 9 | skipping to change at page 10, line 27 | |||
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email | [RFC6186] Daboo, C., "Use of SRV Records for Locating Email | |||
Submission/Access Services", RFC 6186, | Submission/Access Services", RFC 6186, | |||
DOI 10.17487/RFC6186, March 2011, | DOI 10.17487/RFC6186, March 2011, | |||
<http://www.rfc-editor.org/info/rfc6186>. | <http://www.rfc-editor.org/info/rfc6186>. | |||
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", | [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", | |||
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, | STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, | |||
<http://www.rfc-editor.org/info/rfc6409>. | <http://www.rfc-editor.org/info/rfc6409>. | |||
9.2. Informative References | 10.2. Informative References | |||
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", | [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", | |||
RFC 2595, DOI 10.17487/RFC2595, June 1999, | RFC 2595, DOI 10.17487/RFC2595, June 1999, | |||
<http://www.rfc-editor.org/info/rfc2595>. | <http://www.rfc-editor.org/info/rfc2595>. | |||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifier (URI): Generic Syntax", STD 66, | Resource Identifier (URI): Generic Syntax", STD 66, | |||
RFC 3986, DOI 10.17487/RFC3986, January 2005, | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
<http://www.rfc-editor.org/info/rfc3986>. | <http://www.rfc-editor.org/info/rfc3986>. | |||
End of changes. 21 change blocks. | ||||
48 lines changed or deleted | 66 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |