< draft-moore-email-addrquery-00.txt   draft-moore-email-addrquery-01.txt >
Network Working Group K. Moore Network Working Group K. Moore
Internet-Draft Network Heretics Internet-Draft Network Heretics
Updates: 5231, 6409 (if approved) C. Newman Updates: 5231, 6409 (if approved) C. Newman
Intended status: Standards Track Oracle Intended status: Standards Track Oracle
Expires: January 7, 2016 July 6, 2015 Expires: January 20, 2016 July 19, 2015
SMTP and SUBMISSION Service Extensions For Address Query SMTP and SUBMISSION Service Extensions For Address Query
draft-moore-email-addrquery-00.txt draft-moore-email-addrquery-01.txt
Abstract Abstract
This document defines several mechanisms which can be used by a This document defines several mechanisms which can be used by a
client such as a Mail User Agent or Mail Submission Agent, to query client such as a Mail User Agent or Mail Submission Agent, to query
an SMTP server which is configured to accept incoming mail for a mail an SMTP server which is configured to accept incoming mail for a mail
domain, to obtain information associated with an email address based domain, to obtain information associated with an email address based
in that domain. Among other purposes, these mechanisms are intended in that domain. Among other purposes, these mechanisms are intended
to facilitate discovery of senders' and/or recipients' public keys to facilitate discovery of senders' and/or recipients' public keys
for use in automatic verification of whole-message digital signatures for use in automatic verification of whole-message digital signatures
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 January 7, 2016. This Internet-Draft will expire on January 20, 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 16 skipping to change at page 2, line 16
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
2. Conventions and Terminology Used In This Document . . . . . . 3 2. Conventions and Terminology Used In This Document . . . . . . 3
3. SMTP Service Extension for Address Query . . . . . . . . . . 4 3. SMTP Service Extension for Address Query . . . . . . . . . . 4
3.1. AQRY SMTP Command . . . . . . . . . . . . . . . . . . . . 4 3.1. AQRY SMTP Command . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Client Use of AQRY command . . . . . . . . . . . . . 5 3.1.1. Client Use of AQRY command . . . . . . . . . . . . . 5
3.1.2. Normal AQRY Response . . . . . . . . . . . . . . . . 6 3.1.2. Normal AQRY Response . . . . . . . . . . . . . . . . 7
3.1.3. Redirect AQRY Response . . . . . . . . . . . . . . . 7 3.1.3. Redirect AQRY Response . . . . . . . . . . . . . . . 8
3.1.4. Other response codes . . . . . . . . . . . . . . . . 9 3.1.4. Other response codes . . . . . . . . . . . . . . . . 10
4. SUBMISSION Service Extension for Address Query Proxy . . . . 10 4. Mail Submission Service Extension for Address Query Proxy . . 11
4.1. AQPX Command . . . . . . . . . . . . . . . . . . . . . . 10 4.1. AQPX Command . . . . . . . . . . . . . . . . . . . . . . 12
4.2. AQPX responses . . . . . . . . . . . . . . . . . . . . . 11 4.2. AQPX responses . . . . . . . . . . . . . . . . . . . . . 13
5. Address Query Information Data Model . . . . . . . . . . . . 12 5. Address Query Information Data Model . . . . . . . . . . . . 14
6. Trustworthiness Of Address Query Responses . . . . . . . . . 13 6. Trustworthiness Of Address Query Responses . . . . . . . . . 17
7. Enhanced Status Codes for Address Query and Address Query 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
Proxy Extensions . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8.1. Registration for AQRY SMTP service extension . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8.2. Registration for AQPX Submission service extension . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.3. Registration for new Enhanced Status Codes . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.4. Register new SMTP reply codes . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 16 8.5. Create registry for AQRY data model elements . . . . . . 22
Appendix A. Rationale For Design Choices . . . . . . . . . . . . 17 8.6. possibly reserve port number for use in AQRY redirects . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Rationale For Design Choices . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
At least since the introduction of MIME [RFC1321] there has been a At least since the introduction of MIME [RFC1321] there has been a
desire to allow message senders to discover capabilities of email desire to allow message senders to discover capabilities of email
recipients, so that senders could avoid sending message contents to recipients, so that senders could avoid sending message contents to
recipients who were unable to make use of such contents. Similarly, recipients who were unable to make use of such contents. Similarly,
deployment of per-message encryption (e.g. PEM [RFC1113], S/MIME deployment of per-message encryption (e.g. PEM [RFC1113], S/MIME
[RFC5751], and OpenPGP [RFC4880]) has long been hampered for lack of [RFC5751], and OpenPGP [RFC4880]) has long been hampered for lack of
a standard and widely supported means to discover and verify a standard and widely supported means to discover and verify
authenticity of senders' and recipients' public key(s). authenticity of senders' and recipients' public key(s).
The issue surfaced recently as part of the DANE working group The issue surfaced recently as part of the DANE working group
discussion in Dallas, and specifically in an effort to adapt TLSA DNS discussion in Dallas, and specifically in an effort to adapt TLSA DNS
records [RFC6698] for use in discovery of email recipients' public records [RFC6698] for use in discovery of email recipients' public
keys. The problem there was that there's no clean way to map keys. The problem there was that there is no clean way to map
recipient email addresses onto DNS labels, because the interpretation recipient email addresses onto DNS labels, because the interpretation
of a local-part of an email address is entirely left to the SMTP of a local-part of an email address is entirely left to the SMTP
server(s) that accept incoming mail for that address's mail domain, server(s) that accept incoming mail for that address's mail domain,
and different mail domains have configured their SMTP servers to and different mail domains have configured their SMTP servers to
interpret their email addresses in different ways. The "local parts" interpret their email addresses in different ways. The "local parts"
of email addresses may be case-sensitive or case-insensitive, of email addresses may be case-sensitive or case-insensitive,
subaddresses may be allowed, there may be some sort of fuzzy subaddresses may be allowed, there may be some sort of fuzzy
matching, an address may be forwarded elsewhere, and so on. Also, matching, an address may be forwarded elsewhere, and so on. Also,
having public keys for email recipients advertised in DNS would have having public keys for email recipients advertised in DNS would have
facilitated email traffic analysis by an observer watching DNS facilitated email traffic analysis by an observer watching DNS
skipping to change at page 3, line 22 skipping to change at page 3, line 26
Since the knowledge of how to interpret an email address is Since the knowledge of how to interpret an email address is
inherently embedded in the code and configuration of the SMTP servers inherently embedded in the code and configuration of the SMTP servers
that accept incoming mail for that address's email domain, it appears that accept incoming mail for that address's email domain, it appears
that the best way to advertise public keys and other information that the best way to advertise public keys and other information
associated with email addresses is to do so using the same SMTP associated with email addresses is to do so using the same SMTP
servers that accept such incoming mail. That way, the logic that servers that accept such incoming mail. That way, the logic that
maps from address to associated information will be the same logic maps from address to associated information will be the same logic
that maps from recipient address to recipient mailbox (or forwarding that maps from recipient address to recipient mailbox (or forwarding
address). A separate lookup service could be used, but this would address). A separate lookup service could be used, but this would
introduce a high probablility that the service would interpret the introduce a high probability that the service would interpret the
address differently than that mail domain's SMTP servers, if for no address differently than that mail domain's SMTP servers, if for no
other reason than configuration errors. However as a compromise for other reason than configuration errors. However as a compromise for
large mail service providers, and especially those that serve large large mail service providers, and especially those that serve large
numbers of mail domains, the proposed SMTP extension also includes a numbers of mail domains, the proposed SMTP extension also includes a
"redirect" mechanism that can be used to refer a client to a separate "redirect" mechanism that can be used to refer a client to a separate
service which then provides the requested information. Finally, this service which then provides the requested information. Finally, this
document defines an extension to the SUBMISSION service which allows document defines an extension to the Mail Submission service which
that service to perform an address information lookup operation on allows that service to perform an address information lookup
behalf of its authenticated client, which can be useful to circumvent operation on behalf of its authenticated client, which can be useful
the common practice of blocking outbound port 25 traffic. to circumvent the common practice of blocking outbound port 25
traffic.
2. Conventions and Terminology Used In This Document 2. Conventions and Terminology 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].
This specification expresses syntax using the Augmented Backus-Naur This specification expresses syntax using the Augmented Backus-Naur
Form (ABNF) as described in [RFC5234], including the core rules in Form (ABNF) as described in [RFC5234], including the core rules in
Appendix B and rules from [RFC5322]. Appendix B and rules from [RFC5322].
skipping to change at page 4, line 30 skipping to change at page 4, line 32
o This extension does not alter any existing SMTP commands, nor does o This extension does not alter any existing SMTP commands, nor does
this extension change the minimum line length that an this extension change the minimum line length that an
implementation of SMTP including this extension must support. implementation of SMTP including this extension must support.
3.1. AQRY SMTP Command 3.1. AQRY SMTP Command
The AQRY SMTP command is used to query an SMTP server about an The AQRY SMTP command is used to query an SMTP server about an
address containing a domain name for which the server is configured address containing a domain name for which the server is configured
to act as a mail exchanger, i.e. to accept incoming mail for to act as a mail exchanger, i.e. to accept incoming mail for
delivery. A SMTP server which accepts incoming mail for a domain is delivery. A SMTP server which accepts incoming mail for a domain is
in a unique position to interpret email addresses contianing that in a unique position to interpret email addresses containing that
domain, since only such a server can reliably know whether the local domain, since only such a server can reliably know whether the local
part of that email address is case-sensitive (i.e. whether part of that email address is case-sensitive (i.e. whether
Joe@example.com and joe@example.com are distinct users), whether Joe@example.com and joe@example.com are distinct users), whether
subaddressing applies to that domain (e.g. whether subaddressing applies to that domain (e.g. whether
joe+xyz@example.com refers to the same user as joe@example.com), joe+xyz@example.com refers to the same user as joe@example.com),
whether a particular recipient has mail forwarded, and so on. whether a particular recipient has mail forwarded, and so on.
Therefore an SMTP server MUST reject an AQRY command which contains Therefore an SMTP server MUST reject an AQRY command which contains
an address for which the server is not explicitly configured to an address for which the server is not explicitly configured to
accept incoming mail. accept incoming mail.
In addition, to ensure the integrity of the information provided to In addition, to ensure the integrity of the information provided to
the client and to deter both passive and active attacks, any SMTP the client and to deter both passive and active attacks, any SMTP
server supporting ADDRQUERY MUST also support the STARTTLS service server supporting ADDRQUERY MUST also support the STARTTLS service
extension, and MUST reject any AQRY command not appearing in a TLS- extension, and MUST reject any AQRY command not appearing in a TLS-
protected session. Clients using the AQRY command MUST support the protected session. Clients using the AQRY command MUST support the
TLS Server Name Indication (SNI) [RFC6066] extension, and MUST supply TLS Server Name Indication (SNI) [RFC6066] extension, and MUST supply
the host name of the server to which they wish to connect in the the host name of the server to which they wish to connect in the
ServerNameList portion of the extension_data field of the extended ServerNameList portion of the extension_data field of the extended
client hello message. (This requirement also applies to SUBMISSION client hello message. (This requirement also applies to Mail
servers that implement the Address Query Proxy extension.) This host Submission servers that implement the Address Query Proxy extension.)
name will either be the target of the MX record associated with the This host name will either be the target of the MX record associated
address being queried, or the "host" field as obtained from an AQRY with the address being queried, or the "host" field as obtained from
or AQPX redirect response as defined below. Servers supporting the an AQRY or AQPX redirect response as defined below. Servers
Address Query extension SHOULD support SNI and use it to provide an supporting the Address Query extension SHOULD support SNI and use it
appropriate server certificate, if available. to provide an appropriate server certificate, if available.
The syntax of the AQRY command is as follows: The syntax of the AQRY command is as follows:
aqry = "AQRY" SP "<" Mailbox ">" aqry = "AQRY" SP "<" Mailbox ">"
[ "REFERBY=" address-literal ]
[ "RRVS=" date-time ] [ "COOKIE=" Atom ] CRLF [ "RRVS=" date-time ] [ "COOKIE=" Atom ] CRLF
where Mailbox is as defined in [RFC5321], and date-time is as defined where address-literal, Atom, and Mailbox are as defined in [RFC5321]
in [RFC3339], with the added restriction that a "time-secfrac" MUST (or if the SMTP server supports the SMTPUTF8 extension, Mailbox is as
NOT be used. defined in [RFC6531]), and date-time is as defined in [RFC3339], with
the added restriction that a "time-secfrac" MUST NOT be used. (XXX
amend the above to use the right nonterminal ABNF symbol for servers
that support SMTPUTF8. Similarly for AQPX command.)
The AQRY command requests that the SMTP server return public The AQRY command requests that the SMTP server return public
information about the email address ("Mailbox") specified in the information about the email address ("Mailbox") specified in the
command. If the optional RRVS parameter is included, it specifies command. If the optional RRVS parameter is included, it specifies
that the email address must have been valid at least since that date that the email address must have been valid at least since that date
and time. If the server knows that the address has not been valid and time. If the server knows that the address has not been valid
that long, it MUST return either an error, or a redirect to a server that long, it MUST return either an error, or a redirect to a server
that will return an "address not found" error. that will return an "address not found" error.
(Note: Although the RRVS parameter to the AQRY command has the same (Note: Although the RRVS parameter to the AQRY command has the same
syntax as the RRVS parameter to the RCPT command as defined in syntax as the RRVS parameter to the RCPT command as defined in
[RFC7293], the two are separate and have different purposes. An SMTP [RFC7293], the two are separate and have different purposes. An SMTP
server MAY support the Address Query extension even if it does not server MAY support the Address Query extension even if it does not
support the RRVS extension.) support the RRVS extension.)
The COOKIE parameter is used only in redirects, as described below. The COOKIE and REFERBY parameters are used only in redirects, as
described below.
(XXX consider max length of COOKIE parameter and whether this affects
minimum SMTP command line length that the server must support.)
3.1.1. Client Use of AQRY command 3.1.1. Client Use of AQRY command
Clients wishing to query for email address information MUST first Clients wishing to query for email address information MUST first
perform a DNS [RFC1035] lookup with query type of MX, specifying the perform a DNS [RFC1035] lookup with query type of MX, specifying the
domain name that appears in the email address. The selection of SMTP domain name that appears in the email address. The selection of SMTP
servers among those returned from the DNS query follows the same servers among those returned from the DNS query follows the same
algorithm used for selection of SMTP servers to be used for algorithm used for selection of SMTP servers to be used for
forwarding mail [RFC5321]: servers with lower MX precedence values forwarding mail [RFC5321]: servers with lower MX precedence values
are queried before servers with higher MX precedence values. are queried before servers with higher MX precedence values.
Clients MUST NOT send an AQRY command to a server that isn't listed Clients MUST NOT send an AQRY command to a server that isn't listed
in DNS as a mail exchanger for the mail domain of the address to be in DNS as a mail exchanger for the mail domain of the address to be
queried. (Exception: a client MAY send an AQRY command to an queried. Exception: a client MAY send an AQRY command to an
arbitrary SMTP server without first obtaining that from a DNS MX arbitrary SMTP server without first obtaining that from a DNS MX
lookup, if this is done specifically and entirely for the purpose of lookup, if this is done specifically and entirely for the purpose of
fault diagnosis or configuration checking and the results are not fault diagnosis or configuration checking and the results are not
used to encrypt email nor validate a digital signature.) used to encrypt email nor validate a digital signature.
Note: In contrast to DNS lookups for normal mail routing, the
presence of one or more MX records for the mail domain of the address
being queried is REQUIRED. In particular, the AQPX command described
below, when used without a SERVER argument, will not query an SMTP
server if there are no MX records pointing to it, and only A or AAAA
records.
Clients wishing to use AQRY MUST first negotiate use of TLS Clients wishing to use AQRY MUST first negotiate use of TLS
encryption using the STARTTLS command [RFC3207]. If the server does encryption using the STARTTLS command [RFC3207]. If the server does
not advertise STARTTLS, or the TLS negotiation fails, the client MUST not advertise STARTTLS, or the TLS negotiation fails, the client MUST
NOT attempt to use AQRY. Furthermore, the client MUST NOT attempt to NOT attempt to use AQRY. Furthermore, the client MUST NOT attempt to
use AQRY before first establishing the identity of the server using use AQRY before first establishing the identity of the server using
the server's certificate, and in particular, that the server's TLS the server's certificate, and in particular, that the server's TLS
certificate contains a subjectAltName of dNSName type [RFC5280] certificate contains either a DNS-ID (subjectAltName of dNSName type,
matches either the DNS name that is the target of the MX record, or see [RFC5280]) or a CN-ID (CN attribute from subject name, see
the DNS name appearing in the email address for which information is [RFC6125]) that matches either the DNS name that is the target of the
being requested. (Exception: the check of the TLS certificate MAY be MX record, or the DNS name appearing in the email address for which
skipped if the AQRY operation is done specifically and entirely for information is being requested. (Exception: the check of the TLS
the purpose of fault diagnosis or configuration checking, and the certificate MAY be skipped if the AQRY operation is done specifically
results are not used to encrypt email nor validate a digital and entirely for the purpose of fault diagnosis or configuration
signature.) checking, and the results are not used to encrypt email nor validate
a digital signature.)
Note: The above rule does not, by itself, establish that the SMTP
server is an authoritative source of information about the
address(es) to be presented to AQRY, because (for example) an MX
record might have been spoofed (unless signed by DNSSEC and the
signature was appropriately verified), or the DNS name associated
with the MX record might not actually have an arrangement with the
SMTP server. However, if the server certificate fails this test,
there's no point in the client doing the AQRY at all. See Section 6.
In response to an AQRY command, the server MUST return one of: a In response to an AQRY command, the server MUST return one of: a
normal response, a redirect response, or an error response. normal response, a redirect response, or an error response.
A normal response contains information about the email address for A normal response contains information about the email address for
which the request was issued which is specific to that email address, which the request was issued which is specific to that email address,
and/or information about the mail domain name which appears in that and/or information about the mail domain name which appears in that
email address. A normal response MAY also contain information such email address. A normal response MAY also contain information such
as address(es) to which incoming mail will be forwarded. In some as address(es) to which incoming mail will be forwarded. In some
such cases the client will need to perform additional AQRY such cases the client will need to perform additional AQRY
skipping to change at page 9, line 4 skipping to change at page 9, line 30
The client decodes this and obtains the following data structure The client decodes this and obtains the following data structure
(formatted for readability below): (formatted for readability below):
[ [
{ "host": "foo.example.com", "port": 9876, { "host": "foo.example.com", "port": 9876,
"cookie": "lkjseoru" }, "cookie": "lkjseoru" },
{ "host": "10.1.2.3", "cookie": "sfwerv33" }, { "host": "10.1.2.3", "cookie": "sfwerv33" },
{ "host": "2001:DB8:abcd::1:2", "port": 4325, { "host": "2001:DB8:abcd::1:2", "port": 4325,
"cookie": "lkjseoru" } "cookie": "lkjseoru" }
] ]
The client could then obtain the requested information via any of the The client could then obtain the requested information via any of the
following: following:
o Open a connection to foo.example.com, port 9876, negotiate o Open a connection to foo.example.com, port 9876, negotiate
STARTTLS, then issue the command: "AQRY <joe@example.com> STARTTLS, then issue the command: "AQRY <joe@example.com>
COOKIE=lkjseoru", COOKIE=lkjseoru",
o Open a connection to 10.1.2.3, port 25, negotiate STARTTLS, then o Open a connection to 10.1.2.3, port 25, negotiate STARTTLS, then
issue the command: "AQRY <joe@example.com> COOKIE=sfwerv33", OR issue the command: "AQRY <joe@example.com> COOKIE=sfwerv33", OR
o Open a connection to 2001:DB8:abcd::1:2, port 4325, negotiate o Open a connection to 2001:DB8:abcd::1:2, port 4325, negotiate
STARTTLS, then issue the command "AQRY <joe@example.com> STARTTLS, then issue the command "AQRY <joe@example.com>
COOKIE=lkjseoru" . COOKIE=lkjseoru" .
In each of the above instances, the client will supply the "host" In each of the above instances, the client will supply the "host"
parameter from the object as the TLS Server Name Indication (SNI) parameter from the object as the TLS Server Name Indication (SNI)
HostName. Any RRVS parameter appearing in the original AQRY command HostName. Any RRVS parameter appearing in the original AQRY command
is also supplied when issuing the AQRY command to the redirect is also supplied when issuing the AQRY command to the redirect
servers. servers. In addition the AQRY REFERBY parameter is supplied with its
value set to the Internet Protocol (v4 or v6) address of the SMTP
server from which the redirect was obtained.
Since the SMTP servers returned in a referral response are not Since the SMTP servers returned in a referral response are not
expected to be able to process incoming mail, they are not required expected to be able to process incoming mail, they are not required
to implement the full SMTP protocol. They need only implement the to implement the full SMTP protocol. They need only implement the
following commands: EHLO (advertising STARTTLS and ADDRQUERY), following commands: EHLO (advertising STARTTLS and ADDRQUERY),
STARTTLS, AQRY, and QUIT. STARTTLS, AQRY, and QUIT. Such a server SHOULD also implement the
PIPELINING extension. [RFC2920]
3.1.4. Other response codes 3.1.4. Other response codes
In addition to reply codes defined in [RFC5321], the following reply In addition to reply codes defined in [RFC5321], the following reply
codes SHOULD be used to indicate the error conditions described codes SHOULD be used to indicate the error conditions described
below: below. In each case below the enhanced status code [RFC5248] that
appears immediately following the 3-digit SMTP reply code is
suggested for use by server implementations supporting the SMTP
ENHANCEDSTATUSCODES extension [RFC2034]. However, the appropriate
status code may depend to some degree on the nature of the SMTP
server implementation or configuration, and there may be cases in
which a different enhanced status code is appropriate. (The SMTP
reply code and enhanced status code serve distinct purposes: The
reply code is intended for use by SMTP clients, and in particular
signals transitions in the SMTP client's state machine. The enhanced
status code is intended for use in Delivery Status Notifications
[RFC3464] and serves as an indication of the likely nature of a
problem with the mail system or network. The relationship between
the two is loose rather than strict.)
411 database lookup temporary failure IANA NOTE: Some of these codes need to be assigned; these are marked
with IANA- followed by some number. See Section 8. (RFC Editor:
please remove this paragraph on publication.)
411 4.4.3 database lookup temporary failure
This failure occurs whenever the SMTP server must consult some This failure occurs whenever the SMTP server must consult some
external database or other service in order to provide the external database or other service in order to provide the
requested information, and that service fails to respond within a requested information, and that service fails to respond within a
reasonable time. The client may reasonably retry the command reasonable time. The client may reasonably retry the command
after some interval. [[XXX specify timeout for AQRY]] after some interval. [[XXX specify timeout for AQRY]]
511 no information available for this address 511 5.4.IANA-1 no information available for this address
The address appears to be valid but there is no information The address appears to be valid but there is no information
available that is associated with it. available that is associated with either the address or the mail
domain. This reply code is intended to reflect the case where
there is not actually an error detected on the server, but rather,
a simple absence of information associated with that address and/
or mail domain. If there is some sort of error detected on the
server, say while trying to obtain the requested information from
a separate database, a different reply code and enhanced status
code would be reported.
513 server not configured to handle AQRY for this domain Note: Strictly speaking, this is not an error condition, and would
not normally be assigned a 5xx reply code or 5.y.z enhanced status
code, since there is no requirement that information be available
for every address or mail domain. However, if the client has been
instructed (for example) to not deliver mail without first
encrypting it with the recipient's public key, this is the reply
code that the server should return and (absent some better error-
detection code in the client) the enhanced status code included
with this reply would be reported to the sender as the error which
caused failure of the message to be sent.
513 5.3.IANA-2 service not supported for this domain
The server is configured to accept incoming mail for the domain The server is configured to accept incoming mail for the domain
name appearing in the address, but the server is not configured to name appearing in the address, but the server is not configured to
perform queries for addresses in that domain. perform queries for addresses in that domain.
550 no such address 550 5.1.1 no such address
The address does not exist. The address does not exist. Note: Depending on the specific
nature of the error, there are several enhanced status codes that
could reasonably be used with the 550 reply code in response to
AQRY, including 5.1.1, 5.5.4, 5.6.7, and others. [[XXX should
probably explain when it's appropriate to use other SMTP reply
codes than those listed in this document, either that or list a
few more valid responses.]]
551 server does not accept incoming mail for this domain 557 5.3.IANA-3 server does not accept incoming mail for this domain
The server is not configured to accept incoming mail for the The server is not configured to accept incoming mail for the
domain name appearing in the address. domain name appearing in the address.
555 command not supported for this recipient 523 5.7.IANA-4 TLS required but not negotiated
The address may be valid but the AQRY command is not supported for This reply code is returned whenever a client attempts an AQRY
this recipient.
559 TLS required but not negotiated
This reply code is returned whenver a client attempts an AQRY
command in a SMTP session that is not protected by TLS. command in a SMTP session that is not protected by TLS.
4. SUBMISSION Service Extension for Address Query Proxy 4. Mail Submission Service Extension for Address Query Proxy
This section defines a service extension to the Mail Submission This section defines a service extension to the Mail Submission
Protocol [RFC6409] which can be used by an authenticated, authorized Protocol [RFC6409] which can be used by an authenticated, authorized
client to query an SMTP server on port 25 for information about an client to query an SMTP server on port 25 for information about an
email address. This is intended only as a workaround for port 25 email address. This is intended only as a workaround for port 25
blocking, so the extension is minimally tailored for that purpose. blocking, so the extension is minimally tailored for that purpose.
o The Name of this extension is "Address Query Proxy". o The Name of this extension is "Address Query Proxy".
o Servers implementing this extension advertise an additional EHLO o Servers implementing this extension advertise an additional EHLO
skipping to change at page 10, line 52 skipping to change at page 12, line 21
The AQPX command is used to query an Submission server for The AQPX command is used to query an Submission server for
information about an email address. The client user MUST have information about an email address. The client user MUST have
already been authenticated and verified to be authorized to use that already been authenticated and verified to be authorized to use that
Submission server. Use of this command by a mail client (such as a Submission server. Use of this command by a mail client (such as a
Mail User Agent) is OPTIONAL; this specification does not prohibit a Mail User Agent) is OPTIONAL; this specification does not prohibit a
client directly contacting an SMTP server. However, it is expected client directly contacting an SMTP server. However, it is expected
that clients will often need a service as a workaround for the common that clients will often need a service as a workaround for the common
practice of blocking outbound traffic on TCP port 25. practice of blocking outbound traffic on TCP port 25.
The AQRY command requires a TLS-protected session, either by using a
server port that automatically establishes TLS on connect, or by
using a cleartext port and the STARTTLS command. Clients MUST NOT
attempt to use the AQRY command if the session is not protected with
TLS; and servers MUST refuse an AQRY command that appears in a
session not protected with TLS.
When this command is received, the Submission server will then: When this command is received, the Submission server will then:
o verify that the user is authenticated via a TLS-protected session o verify that the user is authenticated via a TLS-protected session
o consult the SMTP server specified in the AQPX command, o consult the SMTP server specified in the AQPX command,
o negotiate a TLS session using STARTTLS, o negotiate a TLS session using STARTTLS,
o verify that the server's certificate is valid and has an o verify that the server's certificate is valid and has an
appropriate subjectAltName for the address, and if so, appropriate subjectAltName for the address, and if so,
skipping to change at page 11, line 24 skipping to change at page 12, line 49
o issue an AQRY command to that server, and o issue an AQRY command to that server, and
o return the response from the AQRY command. o return the response from the AQRY command.
If some error occurs in the process of performing the above, the If some error occurs in the process of performing the above, the
Submission server will return an appropriate response code. Submission server will return an appropriate response code.
The syntax of the AQPX command is as follows: The syntax of the AQPX command is as follows:
aqpx = "AQPX" SP "<" Mailbox ">" aqpx = "AQPX" SP "<" Mailbox ">"
"SERVER=" ( Domain / address-literal ) [ "SERVER=" ( Domain
[ RRVS=date-time ] [ COOKIE=cookie ] CRLF / IPv4-address-literal
/ IPv6-address-literal) ]
[ "RRVS=" date-time ] [ "COOKIE=" Atom ] CRLF
The SERVER parameter specifies an SMTP server to consult. Since this where IPv4-address-literal, IPv6-address-literal, Atom, Domain, and
may be any server included in either a response to a DNS MX query, or Mailbox are as defined in [RFC5321] (or if the Submission server
a server returned in a redirect from a previous query to an SMTP supports the SMTPUTF8 extension, Domain and Mailbox are as defined in
server, the SUBMISSION server SHOULD NOT restrict the servers to [RFC6531]), and date-time is as defined in [RFC3339] with the added
which a client may issue a query. There is no provision for restriction that a "time-secfrac" MUST NOT be used.
The optional SERVER parameter specifies an SMTP server to consult.
Since this may be any server included in either a response to a DNS
MX query, or a server returned in a redirect from a previous query to
an SMTP server, the Submission server SHOULD NOT restrict the servers
to which a client may issue a query. There is no provision for
specifying the port at which the SMTP server is to be contacted; the specifying the port at which the SMTP server is to be contacted; the
client is assumed to be able to directly contact servers on ports client is assumed to be able to directly contact servers on ports
other than 25. The RRVS and COOKIE parameters are passed to the AQRY other than 25. If no SERVER parameter is supplied, the Submission
command issued to the SMTP server. server will perform an MX lookup of the domain portion of the
address, and attempt to issue the AQRY command to one or more servers
(if any are found) in order of increasing precedence until it either
receives a result that is not a temporary failure; that result is
returned to the Submission client. Regardless of whether a SERVER
parameter is specified, Submission servers SHOULD implement a
reasonable timeout for obtaining the information necessary to respond
to the AQPX command. If the timeout expires, the server should
return a 431 error (see below).
The RRVS and COOKIE parameters are passed to the AQRY command issued
to the SMTP server.
4.2. AQPX responses 4.2. AQPX responses
Since this is a proxy service that is intended to return a response Since this is a proxy service that is intended to return a response
from a remote SMTP server, any valid response to the SMTP AQRY from a remote SMTP server, any valid response to the SMTP AQRY
command (including a normal response, redirect response, or error command (including a normal response, redirect response, or error
response) is also a valid response to a Submission service AQPX response) is also a valid response to a Submission service AQPX
command. command.
The submission service SHOULD NOT follow redirects returned by an The submission service SHOULD NOT follow redirects returned by an
SMTP server, and MUST return the SMTP server's response intact and SMTP server, and MUST return the SMTP server's response intact and
without modification. without modification.
In addition, the following AQPX-specific response codes are In addition, the following AQPX-specific response codes are
permitted: permitted:
o 431 connection or query to SMTP server timed out o 431 4.4.2 connection or query to remote SMTP server timed out
o 541 invalid remote server certificate received from <smtp-server-
name>
o 542 server certificate for <smtp-server-name> does not match o 541 5.7.IANA-5 invalid remote server certificate
<domain>
o 542 5.7.IANA-6 server certificate for <smtp-server-name> does not
match <domain>
o 43x 4.x.y DNS query timed out
o 5xx 5.x.y No MX records found
5. Address Query Information Data Model 5. Address Query Information Data Model
Note: This is preliminary and is expected to need considerable work, Note: This section is preliminary and is expected to require
and probably a separate document. considerable work, and to be moved to a separate document.
XXX consider using JSON Web Signature (JWS) as an optional means of
authenticating returned information.
The response to the AQRY command is a single JSON object. This JSON The response to the AQRY command is a single JSON object. This JSON
object contains zero or more members each of which is itself an object contains zero or more members, each of which is itself an
object. The members of the outer object are named either for a object. The members of the top-level object either supply
domain (which does not contain an "@") or an email address (which information about a mail domain, or a specific email address. Mail
contains an "@"). In either case the domain or email address are in domain objects are named using the DNS name of their mail domain
pure ASCII format, as would be used in a SMTP MAIL command without (which does not contain an "@"), while email address objects are
any domain or address internationalization extensions. named for their email address (which does contain an "@"). In either
case the domain or email address used to name the second-level
objects are in the same format as would be presented to a SMTP MAIL
command. (i.e. If the SMTP server supports the SMTPUTF8 extension
[RFC6531], the address MAY be in UTF-8; otherwise the address MUST be
in ASCII).
A domain object potentially contains two objects: one named Both mail domain objects and email address objects are "flat", that
"transmit" which contains attributes describing the domain's default is to say, the members of these objects are either strings, numbers,
behavior when sending messages, the other named "receive" which booleans, or arrays whose members consist exclusively of one or more
contains attributes describing the domain's default behavior when of these. For ease of use in some programming languages, the names
receiving messages. An address object also contains two object: one of the elements of both mail domain and email address objects MUST
named "sender" which contains attributes describing that address's begin with an ASCII letter ("a"-"z" or "A"-"Z") and MUST consist only
behavior when sending messages, and one named "recipient" which of letters, digits, and underscore ("_").
contains attributes describing that address's behavior when receiving
messages. The separation of the transmit/receive and sender/
recipient roles allow for separate keys and policies to be specified
for each. In contrast to the per-address set of attributes, the
domain set of attributes provides the capability for the mail domain
to supply attributes independently of any recipient, including the
ability of the mail domain to sign messages originated by a
recipient, and the ability of the mail domain to receive encrypted
messages on behalf of a recipient whose mail user agent cannot
decrypt mail, and decrypt those messages prior to the recipient's
mail user agent obtaining them.
Examples of attributes within these objects include: The requirement for a flat structure is to discourage creation of
complex data models to represent mail domain and address information.
(Note in draft: this is subject to change, but it seems to one of the
authors that one result of the ability to define very complex
structures to represent information is that there is a resulting
tendency to model information using more complexity than is useful or
helpful. Having a relatively simple data model for representation of
such information may also make it easier to store and manipulate such
data in existing SMTP implementations that are implemented in a
variety of programming langauges, and in existing databases that are
used to store address validity and forwarding information.
domain transmit The objects included in the AQRY response are expected to provide
"signing_policy", "signing_key_list", "encryption_policy" information about the domain and/or email address supplied in the
AQRY command. However, multiple domain and/or email address objects
MAY be included if the information is relevant and potentially useful
to the client, and the server is authoritative for such information.
For instance, if joe@a.example.com has his mail forwarded to
bob@b.example.com, the response to AQRY of joe@a.example.com MAY
include domain objects for both "a.example.com" and "b.example.com",
and email address objects for both "joe@a.example.com" and
"bob@b.example.com". However, for this information to be useful to
the client, the server's TLS certificate SHOULD include DNS-ID
attributes matching both "a.example.com" and "b.example.com" (whether
or not wildcard objects are used), and the returned information for
"joe@a.example.com" SHOULD reveal that that address is being
forwarded to "bob@b.example.com". (Note: Encryption of mail to be
forwarded is tricky to get right for various reasons, including that
a recipient may not wish to publicly reveal his forwarding
address(es), and also that a sender may not wish his encrypted mail
to be encrypted for, and forwarded to, one or more different persons
or addresses than the originally-specified recipient.)
domain receive Examples of attributes that might appear within mail domain objects
"accept_encryption", "accept_signature", "encryption_key_list", might include:
"alias"
address sender transmit_signing_policy
"signing_policy", "signing_key_list", "encryption_policy" A string describing the policy with which messages originated by
addresses at this email domain are signed by the domain's mail
submission service, if not signed by the sender of the message.
e.g. "always", "when-able" (only when the recipient advertises
support for a signature algorithm that the sending domain
supports), "only-by-sender" (messages are only signed when
presented to the submission service already signed by the sender's
MUA), "on-sender-request" (the submission service will sign a
message if requested to do so by the sender's MUA), "never". This
information could be used by a recipient to determine whether a
particular received message should have been signed. (XXX However
since this policy can vary over time, this doesn't help when
looking at an old message.)
address recipient transmit_signing_keys
"accept_encryption", "accept_signature", "encryption_key_list", An array of [ keytype, key ] pairs, where keytype is a string, and
"forwarding_address_list" key is a representation of the public key used to sign outgoing
messages.
Each key would be an array consisting of a string key type identifier transmit_encryption_policy
consisting of a message type and a key type for that message (e.g. Describes the policy by which outgoing messages are encrypted to
"openpgp-rsa"), followed by the key or certificate itself in the be read by recipients. One of: "always", "when-able", "only-by-
format normally used with that message type. The accept_* attributes sender", "on-sender-request", "never". This information could be
would be arrays of strings, each string indicating an encryption or used by a recipient to determine whether a particular message
signature format accepted by the domain or recipient. should have been encrypted. (But see the note above about time
sensitivity.)
transmit_encryption_passthrough
Either true or false depending on whether the submission service
will permit already-encrypted messages to be submitted.
receive_accept_encryption
A list of encryption formats/algorithms which the domain itself
can decrypt on behalf of its recipients, if the message is
encrypted using the domain's public key.
receive_encryption_passthrough
Either true or false depending on whether received encrypted
messages that were encrypted for the recipient's key, rather than
the mail domain's key, will be accepted and be passed to the
recipient's message store in encrypted form.
receive_encryption_forwarding_passthrough
Similar to the above, but describes whether encrypted messages may
be forwarded in encrypted form to the recipient's forwarding
address(es).
Examples of attributes that might appear within mail address objects
include:
sender_signing_policy
Describes the conditions in which the sender signs outgoing mail.
sender_signing_key_list
A set of [format, key] pairs, where format is a string describing
the format and signature algorithm, and key is the public key in
an appropriate format for that signature format. There may be
multiple keys with the same format string.
sender_encryption_policy
Describes the conditions in which the sender encrypts outgoing
mail.
recipient_accept_encryption
Describes the encrypted message formats accepted by the recipient.
recipient_decryption_key_list
A set of [ format, key ] pairs listing the message formats and
public keys for which the recipient is able to decrypt mail.
recipient_accept_signature
A list of signed message formats that the recipient can
potentially verify.
recipient_forwarding_addresses
A list of forwarding addresses that the recipient wishes to
publicly disclose.
6. Trustworthiness Of Address Query Responses 6. Trustworthiness Of Address Query Responses
As described above, the JSON object returned in response to AQRY may As described above, the JSON object returned in a normal AQRY
itself contain multiple member objects, each for a separate email response may itself contain multiple member objects, each providing
address or mail domain. The trustworthiness of each member MUST be information about a separate email address or mail domain. The
evaluated separately. A member object of an AQRY response MUST NOT trustworthiness of each member MUST be evaluated separately.
be considered trustworthy for any purpose, unless the TLS server
certificate used to authenticate the session in which the information
was obtained contained a subjectAltName extension specifying a
dNSName matching either the domain used to name the section, or the
domain portion of the email address used to name the section.
A Submission server implementing the AQPX extension server MUST A member object of a normal AQRY response MUST NOT be considered
evaluate the trustworthiness of each named object in the response and trustworthy for any purpose, unless the TLS server certificate used
only return those sections which are verified to be trustworthy to authenticate the session in which the information was obtained
according to the above rule. contained a DNS-ID identifier (subjectAltName of dNSName type
[RFC5280]) or a CN-ID (CN attribute from subject name, [RFC6125])
specifying a dNSName matching either the domain used to name the
section, or the domain portion of the email address used to name the
section.
7. Enhanced Status Codes for Address Query and Address Query Proxy A redirect AQRY response that does not meet the above criteria (i.e
Extensions neither any DNS-ID nor the CN-ID from the server's certificate
matches the domain name of the address presented to AQRY) MAY be used
to identify redirect servers. However, the above certificate checks
MUST be applied when consulting redirect servers and determining the
trustworthiness of their results. In other words, while it's
acceptable for the mail exchangers for a mail domain that are listed
in DNS to not have certificates that match that mail domain, it's not
acceptable for the redirect AQRY servers for that mail domain to have
have certificates that match that mail domain.
(This section needs to be written.) A Submission server implementing the AQPX extension MUST evaluate the
trustworthiness of each named object in the response and only return
those sections which are verified to be trustworthy according to the
above rule.
8. Security Considerations A Submission client using the AQPX extension MUST follow the
certificate checking rules in [I-D.ietf-uta-email-tls-certs].
7. Security Considerations
o This service relies on the SMTP server's TLS server certificate to o This service relies on the SMTP server's TLS server certificate to
authenticate per-domain and per-address information, including authenticate per-domain and per-address information, including
potentially public keys for use with encryption and digital potentially public keys for use with encryption and digital
signatures. While it appears to have the advantage of being signatures. While it appears to have the advantage of being
deployable, as most service providers will already be familiar deployable, as most service providers will already be familiar
with TLS and X.509 certficicate management, the Address Query with TLS and X.509 certificate management, the Address Query
service may invest more trust in such servers and their key service may invest more trust in such servers and their key
management practices than was designed for. management practices than was designed for.
o The Address Query Proxy extension to the Submission service o The Address Query Proxy extension to the Submission service
inherently requires the client and user to trust the Submission inherently requires the client and user to trust the Submission
server to do correct validation and correct name matching of SMTP server to do correct validation and correct name matching of SMTP
servers' certificates, as there is no good way to transfer the servers' certificates, as there is no good way to transfer the
integrity and authenticity assurances provided by the TLS protocol integrity and authenticity assurances provided by the TLS protocol
to the Submission server from the remote SMTP server, to the to the Submission server from the remote SMTP server, to the
Submission client. Submission client.
skipping to change at page 15, line 30 skipping to change at page 19, line 30
which require exposure to received messages in cleartext to be which require exposure to received messages in cleartext to be
useful. Another such barrier is the legal or other requirement useful. Another such barrier is the legal or other requirement
that many organizations have for archival of email communications. that many organizations have for archival of email communications.
Finally, many kinds of personal computer are notoriously insecure, Finally, many kinds of personal computer are notoriously insecure,
so a user's messages and credentials might actually be better so a user's messages and credentials might actually be better
protected on a well-managed server than on his or her own PC. By protected on a well-managed server than on his or her own PC. By
permitting flexibility in how email encryption is done it is hoped permitting flexibility in how email encryption is done it is hoped
that encryption may be more widely deployed and that it will that encryption may be more widely deployed and that it will
provide an upgrade path to optimal security for everyone. provide an upgrade path to optimal security for everyone.
9. IANA Considerations 8. IANA Considerations
(this section requires elaboration.) (this section requires elaboration.)
o Register AQRY SMTP service extension 8.1. Registration for AQRY SMTP service extension
o Register AQPX Submission service extension (to be written)
o Register new Enhanced Status Codes 8.2. Registration for AQPX Submission service extension
o Register new SMTP reply codes (if there is not such a registry, (to be written)
there should be)
o create registry for AQRY data model elements 8.3. Registration for new Enhanced Status Codes
o possibly reserve port number for use in AQRY redirects Code: X.4.IANA-1 (XXX replace IANA-1)
10. References Sample Text: no information available for this address
10.1. Normative References
Associated Status Code(s): 511
Description: This code is used in response to an AQRY command when
the server has no information associated with an address. This
condition is distinct from a temporary condition such as the
server being unable to contact a database to obtain such
information.
Reference: (XXX this document)
Submitter: K. Moore, C. Newman
Change controller: IESG
Code: X.3.IANA-2 (XXX replace IANA-2)
Sample Text: service not supported for this domain
Associated Status Code(s): 513
Description: The server is configured to accept incoming mail for
the domain name appearing in the address, but the requested
service is not supported for that domain. Used, for instance, in
response to the AQRY command.
Reference: (XXX this document)
Submitter: K. Moore, C. Newman
Change controller: IESG
Code: X.3.IANA-3 (XXX replace IANA-3)
Sample Text: incoming mail not accepted for this domain
Associated Status Code(s): 557
Description: This server does not accept incoming mail for the
domain in the supplied address. Originally intended for use in
response to AQRY command. Should not be used in response to RCPT
command because there is a long history of RCPT returning other
response codes for this condition.
Reference: (XXX this document)
Submitter: K. Moore, C. Newman
Change controller: IESG
Code: X.4.IANA-4 (XXX replace IANA-4)
Sample Text: TLS required but not negotiated
Associated Status Code(s): 523
Description: The requested service (which was not an authentication
command) is required to be issued within an authenticated TLS
session, but was not issued within such a session.
Reference: (XXX this document)
Submitter: K. Moore, C. Newman
Change controller: IESG
Code: X.4.IANA-5 (XXX replace IANA-5)
Sample Text: invalid remote server certificate
Associated Status Code(s): 541
Description: This code is used when the requested service must
consult with some remote service to fulfill its function, and the
remote server did not provide a valid TLS server certificate that
matched its domain name. Originally used with AQPX Submission
service command.
Reference: (XXX this document)
Submitter: K. Moore, C. Newman
Change controller: IESG
Code: X.4.IANA-6 (XXX replace IANA-6)
Sample Text: service certificate provided by <server-name> does not
match <domain>
Associated Status Code(s): 542
Description: This code is used when the requested service must
consult some remote service to fulfill its function, and the
certificate provided by the remote service was not correct to
establish the authenticity of the requested information.
Reference: (XXX this document)
Submitter: K. Moore, C. Newman
Change controller: IESG
8.4. Register new SMTP reply codes
XXX
8.5. Create registry for AQRY data model elements
XXX
8.6. possibly reserve port number for use in AQRY redirects
XXX
9. References
9.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[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, November 1996. Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<http://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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2920] Freed, N., "SMTP Service Extension for Command
Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920,
September 2000, <http://www.rfc-editor.org/info/rfc2920>.
[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, February 2002. Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
February 2002, <http://www.rfc-editor.org/info/rfc3207>.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Internet: Timestamps", RFC 3339, July 2002. Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5321>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. DOI 10.17487/RFC5322, October 2008,
<http://www.rfc-editor.org/info/rfc5322>.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extension Definitions", RFC 6066, January 2011. Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail",
STD 72, RFC 6409, November 2011. STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011,
<http://www.rfc-editor.org/info/rfc6409>.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <http://www.rfc-editor.org/info/rfc7159>.
10.2. Informative References [I-D.ietf-uta-email-tls-certs]
Melnikov, A., "Updated TLS Server Identity Check Procedure
for Email Related Protocols", draft-ietf-uta-email-tls-
certs-03 (work in progress), June 2015.
9.2. Informative References
[RFC1113] Linn, J., "Privacy enhancement for Internet electronic [RFC1113] Linn, J., "Privacy enhancement for Internet electronic
mail: Part I - message encipherment and authentication mail: Part I - message encipherment and authentication
procedures", RFC 1113, August 1989. procedures", RFC 1113, DOI 10.17487/RFC1113, August 1989,
<http://www.rfc-editor.org/info/rfc1113>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. DOI 10.17487/RFC1321, April 1992,
<http://www.rfc-editor.org/info/rfc1321>.
[RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced
Error Codes", RFC 2034, DOI 10.17487/RFC2034, October
1996, <http://www.rfc-editor.org/info/rfc2034>.
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464,
DOI 10.17487/RFC3464, January 2003,
<http://www.rfc-editor.org/info/rfc3464>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880, November 2007. Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
<http://www.rfc-editor.org/info/rfc4880>.
[RFC5248] Hansen, T. and J. Klensin, "A Registry for SMTP Enhanced
Mail System Status Codes", BCP 138, RFC 5248,
DOI 10.17487/RFC5248, June 2008,
<http://www.rfc-editor.org/info/rfc5248>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized
Email", RFC 6531, DOI 10.17487/RFC6531, February 2012,
<http://www.rfc-editor.org/info/rfc6531>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, August 2012. Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>.
[RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- [RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid-
Since Header Field and SMTP Service Extension", RFC 7293, Since Header Field and SMTP Service Extension", RFC 7293,
July 2014. DOI 10.17487/RFC7293, July 2014,
<http://www.rfc-editor.org/info/rfc7293>.
Appendix A. Rationale For Design Choices Appendix A. Rationale For Design Choices
This section is not normative. This section is not normative.
o As described above, the choice of using an SMTP extension for this o As described above, the choice of using an SMTP extension for this
purpose, and using mail exchangers for the authoritiatve sources purpose, and using mail exchangers for the authoritative sources
of this information, resulted from the observation that only the of this information, resulted from the observation that only the
SMTP servers for incoming mail for a mail domain reliably know how SMTP servers for incoming mail for a mail domain reliably know how
to interpret an email address from that mail domain. to interpret an email address from that mail domain.
o The redirect response was included because many mail service o The redirect response was included because many mail service
providers accept incoming mail for large numbers of mail domains, providers accept incoming mail for large numbers of mail domains,
and that it is infeasible and generally inappropriate for a large and that it is infeasible and generally inappropriate for a large
mail service provider to maintain server certificates that name mail service provider to maintain server certificates that name
each of the mail domains for which it provides service. The each of the mail domains for which it provides service. The
redirect response thus permits referral of a request to a specific redirect response thus permits referral of a request to a specific
skipping to change at page 18, line 12 skipping to change at page 25, line 36
appeared to make client implementations unnecessarily complex, for appeared to make client implementations unnecessarily complex, for
several reasons: differences in error reporting between SMTP and several reasons: differences in error reporting between SMTP and
HTTP required two sets of error codes and different logic on the HTTP required two sets of error codes and different logic on the
client side for each, the existence of HTTP redirects coupled with client side for each, the existence of HTTP redirects coupled with
the need to verify subjectAltName in server certificates appeared the need to verify subjectAltName in server certificates appeared
to make it difficult to reuse ordinary HTTP library routines. So to make it difficult to reuse ordinary HTTP library routines. So
redirects were changed to specify the DNS name or address, and redirects were changed to specify the DNS name or address, and
port, of one or more SMTP servers, thus allowing reuse of the same port, of one or more SMTP servers, thus allowing reuse of the same
code on the client for both kinds of query. code on the client for both kinds of query.
o As indicated above, the SUBMISSION extension was created as a o As indicated above, the Submission extension was created as a
workaround for the common practice of blocking outbound TCP workaround for the common practice of blocking outbound TCP
traffic to a destination port of 25. However, it also seemed traffic to a destination port of 25. However, it also seemed
appropriate for a SUBMISSION server to support this functionality appropriate for a Submission server to support this functionality
based on an anticipated desire for a SUBMISSION server to support based on an anticipated desire for a Submission server to support
additional extensions (not defined in this document) for server- additional extensions (not defined in this document) for server-
side signing and/or encryption of submitted mail. side signing and/or encryption of submitted mail.
o The SUBMISSION AQPX command doesn't support arbitrary ports o The Submission AQPX command doesn't support arbitrary ports
because it seemed like too much of an opportunity for clients to because it seemed like too much of an opportunity for clients to
use that facility for malicious purposes, even if the clients do use that facility for malicious purposes, even if the clients do
have to be authenticated. It might be worth considering reserving have to be authenticated. It might be worth considering reserving
a specific port for SMTP AQRY referrals. a specific port for SMTP AQRY referrals.
o The SUBMISSION AQPX command doesn't handle MX lookup, referrals, o The Submission AQPX command doesn't handle MX lookup, referrals,
or retries because of concern over timeout hazards, and because it or retries because of concern over timeout hazards, and because it
seemed better to let clients perform these operations than to seemed better to let clients perform these operations than to
burden servers with them. burden servers with them.
Authors' Addresses Authors' Addresses
Keith Moore Keith Moore
Network Heretics Network Heretics
PO Box 1934 PO Box 1934
Knoxville, TN 37901 Knoxville, TN 37901
 End of changes. 80 change blocks. 
179 lines changed or deleted 552 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/