Network Working Group K. Moore Internet-Draft Network Heretics Updates: 5231, 6409 (if approved) C. Newman Intended status: Standards Track Oracle Expires: January 20, 2016 July 19, 2015 SMTP and SUBMISSION Service Extensions For Address Query draft-moore-email-addrquery-01.txt Abstract This document defines several mechanisms which can be used by a 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 domain, to obtain information associated with an email address based in that domain. Among other purposes, these mechanisms are intended to facilitate discovery of senders' and/or recipients' public keys for use in automatic verification of whole-message digital signatures and automatic whole-message encryption of email sent to recipients. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 20, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Moore & Newman Expires January 20, 2016 [Page 1] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology Used In This Document . . . . . . 3 3. SMTP Service Extension for Address Query . . . . . . . . . . 4 3.1. AQRY SMTP Command . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Client Use of AQRY command . . . . . . . . . . . . . 5 3.1.2. Normal AQRY Response . . . . . . . . . . . . . . . . 7 3.1.3. Redirect AQRY Response . . . . . . . . . . . . . . . 8 3.1.4. Other response codes . . . . . . . . . . . . . . . . 10 4. Mail Submission Service Extension for Address Query Proxy . . 11 4.1. AQPX Command . . . . . . . . . . . . . . . . . . . . . . 12 4.2. AQPX responses . . . . . . . . . . . . . . . . . . . . . 13 5. Address Query Information Data Model . . . . . . . . . . . . 14 6. Trustworthiness Of Address Query Responses . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8.1. Registration for AQRY SMTP service extension . . . . . . 19 8.2. Registration for AQPX Submission service extension . . . 19 8.3. Registration for new Enhanced Status Codes . . . . . . . 19 8.4. Register new SMTP reply codes . . . . . . . . . . . . . . 22 8.5. Create registry for AQRY data model elements . . . . . . 22 8.6. possibly reserve port number for use in AQRY redirects . 22 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 At least since the introduction of MIME [RFC1321] there has been a desire to allow message senders to discover capabilities of email recipients, so that senders could avoid sending message contents to recipients who were unable to make use of such contents. Similarly, deployment of per-message encryption (e.g. PEM [RFC1113], S/MIME [RFC5751], and OpenPGP [RFC4880]) has long been hampered for lack of a standard and widely supported means to discover and verify authenticity of senders' and recipients' public key(s). The issue surfaced recently as part of the DANE working group discussion in Dallas, and specifically in an effort to adapt TLSA DNS records [RFC6698] for use in discovery of email recipients' public Moore & Newman Expires January 20, 2016 [Page 2] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 keys. The problem there was that there is no clean way to map recipient email addresses onto DNS labels, because the interpretation 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, and different mail domains have configured their SMTP servers to interpret their email addresses in different ways. The "local parts" of email addresses may be case-sensitive or case-insensitive, subaddresses may be allowed, there may be some sort of fuzzy matching, an address may be forwarded elsewhere, and so on. Also, having public keys for email recipients advertised in DNS would have facilitated email traffic analysis by an observer watching DNS queries and responses in cleartext. Since the knowledge of how to interpret an email address is inherently embedded in the code and configuration of the SMTP servers that accept incoming mail for that address's email domain, it appears that the best way to advertise public keys and other information associated with email addresses is to do so using the same SMTP servers that accept such incoming mail. That way, the logic that maps from address to associated information will be the same logic that maps from recipient address to recipient mailbox (or forwarding address). A separate lookup service could be used, but this would introduce a high probability that the service would interpret the address differently than that mail domain's SMTP servers, if for no other reason than configuration errors. However as a compromise for large mail service providers, and especially those that serve large numbers of mail domains, the proposed SMTP extension also includes a "redirect" mechanism that can be used to refer a client to a separate service which then provides the requested information. Finally, this document defines an extension to the Mail Submission service which allows that service to perform an address information lookup operation on behalf of its authenticated client, which can be useful to circumvent the common practice of blocking outbound port 25 traffic. 2. Conventions and Terminology Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This specification expresses syntax using the Augmented Backus-Naur Form (ABNF) as described in [RFC5234], including the core rules in Appendix B and rules from [RFC5322]. In examples illustrating protocol interactions, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then the line Moore & Newman Expires January 20, 2016 [Page 3] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. 3. SMTP Service Extension for Address Query This section defines a service extension to the Simple Message Transfer Protocol (SMTP) [RFC5321] which can be used by a client to query the server for information about an email address for which the server accepts incoming mail. o The Name of this extension is "Address Query". o Servers implementing this extension advertise an additional EHLO keyword of "ADDRQUERY", which has no associated parameters. o This extension introduces one new SMTP command, AQRY, described below. o This extension does not alter any existing SMTP commands, nor does this extension change the minimum line length that an implementation of SMTP including this extension must support. 3.1. AQRY SMTP Command The AQRY SMTP command is used to query an SMTP server about an address containing a domain name for which the server is configured 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 in a unique position to interpret email addresses containing that domain, since only such a server can reliably know whether the local part of that email address is case-sensitive (i.e. whether Joe@example.com and joe@example.com are distinct users), whether subaddressing applies to that domain (e.g. whether joe+xyz@example.com refers to the same user as joe@example.com), whether a particular recipient has mail forwarded, and so on. Therefore an SMTP server MUST reject an AQRY command which contains an address for which the server is not explicitly configured to accept incoming mail. In addition, to ensure the integrity of the information provided to the client and to deter both passive and active attacks, any SMTP server supporting ADDRQUERY MUST also support the STARTTLS service extension, and MUST reject any AQRY command not appearing in a TLS- protected session. Clients using the AQRY command MUST support the TLS Server Name Indication (SNI) [RFC6066] extension, and MUST supply the host name of the server to which they wish to connect in the ServerNameList portion of the extension_data field of the extended client hello message. (This requirement also applies to Mail Moore & Newman Expires January 20, 2016 [Page 4] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 Submission servers that implement the Address Query Proxy extension.) This host name will either be the target of the MX record associated with the address being queried, or the "host" field as obtained from an AQRY or AQPX redirect response as defined below. Servers supporting the Address Query extension SHOULD support SNI and use it to provide an appropriate server certificate, if available. The syntax of the AQRY command is as follows: aqry = "AQRY" SP "<" Mailbox ">" [ "REFERBY=" address-literal ] [ "RRVS=" date-time ] [ "COOKIE=" Atom ] CRLF where address-literal, Atom, and Mailbox are as defined in [RFC5321] (or if the SMTP server supports the SMTPUTF8 extension, Mailbox is as 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 information about the email address ("Mailbox") specified in the command. If the optional RRVS parameter is included, it specifies 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 that long, it MUST return either an error, or a redirect to a server that will return an "address not found" error. (Note: Although the RRVS parameter to the AQRY command has the same syntax as the RRVS parameter to the RCPT command as defined in [RFC7293], the two are separate and have different purposes. An SMTP server MAY support the Address Query extension even if it does not support the RRVS extension.) 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 Clients wishing to query for email address information MUST first perform a DNS [RFC1035] lookup with query type of MX, specifying the domain name that appears in the email address. The selection of SMTP servers among those returned from the DNS query follows the same algorithm used for selection of SMTP servers to be used for forwarding mail [RFC5321]: servers with lower MX precedence values are queried before servers with higher MX precedence values. Moore & Newman Expires January 20, 2016 [Page 5] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 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 queried. Exception: a client MAY send an AQRY command to an arbitrary SMTP server without first obtaining that from a DNS MX lookup, if this is done specifically and entirely for the purpose of fault diagnosis or configuration checking and the results are not 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 encryption using the STARTTLS command [RFC3207]. If the server does not advertise STARTTLS, or the TLS negotiation fails, the client MUST NOT attempt to use AQRY. Furthermore, the client MUST NOT attempt to use AQRY before first establishing the identity of the server using the server's certificate, and in particular, that the server's TLS certificate contains either a DNS-ID (subjectAltName of dNSName type, see [RFC5280]) or a CN-ID (CN attribute from subject name, see [RFC6125]) that matches either the DNS name that is the target of the MX record, or the DNS name appearing in the email address for which information is being requested. (Exception: the check of the TLS certificate MAY be skipped if the AQRY operation is done specifically and entirely for the purpose of fault diagnosis or configuration 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 normal response, a redirect response, or an error response. A normal response contains information about the email address for which the request was issued which is specific to that email address, and/or information about the mail domain name which appears in that email address. A normal response MAY also contain information such as address(es) to which incoming mail will be forwarded. In some Moore & Newman Expires January 20, 2016 [Page 6] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 such cases the client will need to perform additional AQRY operations, perhaps of other SMTP servers serving other domains, in order to learn information about the addresses that would eventually receive mail sent to the originally queried address. A redirect response does not contain information about the requested email address, but does contain one or more URLs which may then be queried to learn about that address and/or its mail domain. 3.1.2. Normal AQRY Response The normal (non-redirect, non-error) response to a valid AQRY command consists of multiple lines. Each line but the last line of the response begins with "212-". The remainder of each line beginning with "212-" consists of JSON text [RFC7159] subsequently encoded in BASE64 format as defined in [RFC2045]. BASE64 is used to avoid the need for the server to produce JSON text which conforms to SMTP line- length restrictions. A normal response is not an indication that the address supplied in the AQRY command is valid. An implementation that does not wish to disclose whether recipients are valid MAY return "fake" information in response to AQRY requests for nonexistent recipients. However the implementation MUST NOT return "fake" information for valid recipients. The data structure encoded in the JSON object is further described in section Section 5. The last line of the response is of the form: "212" SP "." CRLF To produce the normal response to an AQRY command, the server first produces or obtains the requested information in JSON format. The server then encodes the entire JSON object using the BASE64 algorithm, such that each line of the BASE64 output does not exceed 76 characters, not including the CRLF character sequence that terminates each line. The server then prepends "212-" to the beginning of each line of the BASE64 output. Finally, the server appends a single line consisting of "212 ." to the output. Per normal SMTP convention, each line of the reply MUST be terminated by CRLF. Note: If a address is configured to forward mail to one or more other addresses, this can affect the contents of the JSON object or result in an error. See Section 5. Moore & Newman Expires January 20, 2016 [Page 7] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 To recover the JSON from the AQRY reply text, the client first collects the text and ensures that the terminating "212 ." line is present. The terminating line is then discarded, and the "212-" prefix is removed from each of the preceding lines. The resulting text is then fed to the BASE64 decoder to produce a JSON object. The resulting JSON object may then be interpreted. 3.1.3. Redirect AQRY Response In the case where the SMTP server is configured to accept incoming mail for the address presented in the AQRY command, but either of the following two conditions apply: (a) in the currently active TLS session, the SMTP server did not present a server certificate with a subjectAltName with dNSName type that matches the domain name portion of the email address presented in the AQRY command; OR (b) the SMTP server is configured to return a redirect for other reasons, e.g. to shed load from the SMTP server to another server which is better equipped to service that kind of query; the SMTP server MAY return a multi-line redirect response with a response code of 213. Similar in presentation format to the normal response, the redirect response consists of BASE64-encoded JSON, with each line of the BASE64 text preceded by "213-" and the last line of the response consisting entirely of "213 ." followed by CRLF. However, the data structure represented in JSON for a redirect response is different than that of a normal response. The data structure encoded in a redirect response consists of an array of objects describing SMTP servers to which the query can be referred. Each such object may contain the following elements: host DNS name, IPv4 address, or IPv6 address of an SMTP server. port Optional port number to be used to contact the SMTP server. Port 25 is assumed if this element is not supplied. cookie Optional cookie to be passed in the COOKIE parameter to the AQRY command when querying the server. This parameter may be used for any purpose by mutual agreement between the server issuing the redirect response, and the server to which the redirect response refers. For example: it may be used to encode an encrypted database record identifier of the named recipient; or it may be used to encode an encrypted timestamp at which the referral was Moore & Newman Expires January 20, 2016 [Page 8] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 issued by the server, so that the referred-to server can refuse to return a response if that timestamp is missing or not recent. There is no significance to the order in which the list items, or the elements of any of the objects in the list, appear in the JSON. Example: A client issues a query for information about joe@example.com, and the server returns a redirect response: C: AQRY S: 213-W3siaG9zdCI6ICJmb28uZXhhbXBsZS5jb20iLCAiY29va2llIjogImxranNl S: 213-b3J1IiwgInBvcnQiOiA5ODc2fSwgeyJob3N0IjogIjEwLjEuMi4zIiwgImNv S: 213-b2tpZSI6ICJzZndlcnYzMyJ9LCB7Imhvc3QiOiAiMjAwMTpEQjg6YWJjZDo6 S: 213-MToyIiwgImNvb2tpZSI6ICJsa2pzZW9ydSIsICJwb3J0IjogNDMyNX1d S: 213 . The client decodes this and obtains the following data structure (formatted for readability below): [ { "host": "foo.example.com", "port": 9876, "cookie": "lkjseoru" }, { "host": "10.1.2.3", "cookie": "sfwerv33" }, { "host": "2001:DB8:abcd::1:2", "port": 4325, "cookie": "lkjseoru" } ] The client could then obtain the requested information via any of the following: o Open a connection to foo.example.com, port 9876, negotiate STARTTLS, then issue the command: "AQRY COOKIE=lkjseoru", o Open a connection to 10.1.2.3, port 25, negotiate STARTTLS, then issue the command: "AQRY COOKIE=sfwerv33", OR o Open a connection to 2001:DB8:abcd::1:2, port 4325, negotiate STARTTLS, then issue the command "AQRY COOKIE=lkjseoru" . In each of the above instances, the client will supply the "host" parameter from the object as the TLS Server Name Indication (SNI) HostName. Any RRVS parameter appearing in the original AQRY command is also supplied when issuing the AQRY command to the redirect 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. Moore & Newman Expires January 20, 2016 [Page 9] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 Since the SMTP servers returned in a referral response are not expected to be able to process incoming mail, they are not required to implement the full SMTP protocol. They need only implement the following commands: EHLO (advertising STARTTLS and ADDRQUERY), STARTTLS, AQRY, and QUIT. Such a server SHOULD also implement the PIPELINING extension. [RFC2920] 3.1.4. Other response codes In addition to reply codes defined in [RFC5321], the following reply codes SHOULD be used to indicate the error conditions described 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.) 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 external database or other service in order to provide the requested information, and that service fails to respond within a reasonable time. The client may reasonably retry the command after some interval. [[XXX specify timeout for AQRY]] 511 5.4.IANA-1 no information available for this address The address appears to be valid but there is no information 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. Moore & Newman Expires January 20, 2016 [Page 10] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 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 name appearing in the address, but the server is not configured to perform queries for addresses in that domain. 550 5.1.1 no such address 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.]] 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 domain name appearing in the address. 523 5.7.IANA-4 TLS required but not negotiated This reply code is returned whenever a client attempts an AQRY command in a SMTP session that is not protected by TLS. 4. Mail Submission Service Extension for Address Query Proxy This section defines a service extension to the Mail Submission Protocol [RFC6409] which can be used by an authenticated, authorized 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 blocking, so the extension is minimally tailored for that purpose. o The Name of this extension is "Address Query Proxy". o Servers implementing this extension advertise an additional EHLO keyword of "ADDRQUERYPROXY", which has no associated parameters. o This extension introduces one new Submission command, AQPX, described below. Moore & Newman Expires January 20, 2016 [Page 11] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 o This extension does not alter any existing Submission service commands, nor does this extension change the minimum line length that an implementation of the Submission protocol including this extension must support. 4.1. AQPX Command The AQPX command is used to query an Submission server for information about an email address. The client user MUST have already been authenticated and verified to be authorized to use that Submission server. Use of this command by a mail client (such as a Mail User Agent) is OPTIONAL; this specification does not prohibit a client directly contacting an SMTP server. However, it is expected that clients will often need a service as a workaround for the common 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: o verify that the user is authenticated via a TLS-protected session o consult the SMTP server specified in the AQPX command, o negotiate a TLS session using STARTTLS, o verify that the server's certificate is valid and has an appropriate subjectAltName for the address, and if so, o issue an AQRY command to that server, and o return the response from the AQRY command. If some error occurs in the process of performing the above, the Submission server will return an appropriate response code. The syntax of the AQPX command is as follows: aqpx = "AQPX" SP "<" Mailbox ">" [ "SERVER=" ( Domain / IPv4-address-literal / IPv6-address-literal) ] [ "RRVS=" date-time ] [ "COOKIE=" Atom ] CRLF Moore & Newman Expires January 20, 2016 [Page 12] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 where IPv4-address-literal, IPv6-address-literal, Atom, Domain, and Mailbox are as defined in [RFC5321] (or if the Submission server supports the SMTPUTF8 extension, Domain and Mailbox are as defined in [RFC6531]), and date-time is as defined in [RFC3339] with the added 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 client is assumed to be able to directly contact servers on ports other than 25. If no SERVER parameter is supplied, the Submission 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 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 command (including a normal response, redirect response, or error response) is also a valid response to a Submission service AQPX command. The submission service SHOULD NOT follow redirects returned by an SMTP server, and MUST return the SMTP server's response intact and without modification. In addition, the following AQPX-specific response codes are permitted: o 431 4.4.2 connection or query to remote SMTP server timed out o 541 5.7.IANA-5 invalid remote server certificate o 542 5.7.IANA-6 server certificate for does not match Moore & Newman Expires January 20, 2016 [Page 13] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 o 43x 4.x.y DNS query timed out o 5xx 5.x.y No MX records found 5. Address Query Information Data Model Note: This section is preliminary and is expected to require 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 object contains zero or more members, each of which is itself an object. The members of the top-level object either supply information about a mail domain, or a specific email address. Mail domain objects are named using the DNS name of their mail domain (which does not contain an "@"), while email address objects are 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). Both mail domain objects and email address objects are "flat", that is to say, the members of these objects are either strings, numbers, booleans, or arrays whose members consist exclusively of one or more of these. For ease of use in some programming languages, the names of the elements of both mail domain and email address objects MUST begin with an ASCII letter ("a"-"z" or "A"-"Z") and MUST consist only of letters, digits, and underscore ("_"). 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. The objects included in the AQRY response are expected to provide information about the domain and/or email address supplied in the AQRY command. However, multiple domain and/or email address objects Moore & Newman Expires January 20, 2016 [Page 14] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 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.) Examples of attributes that might appear within mail domain objects might include: transmit_signing_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.) transmit_signing_keys An array of [ keytype, key ] pairs, where keytype is a string, and key is a representation of the public key used to sign outgoing messages. transmit_encryption_policy Describes the policy by which outgoing messages are encrypted to be read by recipients. One of: "always", "when-able", "only-by- sender", "on-sender-request", "never". This information could be used by a recipient to determine whether a particular message should have been encrypted. (But see the note above about time sensitivity.) Moore & Newman Expires January 20, 2016 [Page 15] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 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 Moore & Newman Expires January 20, 2016 [Page 16] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 A list of forwarding addresses that the recipient wishes to publicly disclose. 6. Trustworthiness Of Address Query Responses As described above, the JSON object returned in a normal AQRY response may itself contain multiple member objects, each providing information about a separate email address or mail domain. The trustworthiness of each member MUST be evaluated separately. A member object of a normal AQRY response MUST NOT be considered trustworthy for any purpose, unless the TLS server certificate used to authenticate the session in which the information was obtained 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. A redirect AQRY response that does not meet the above criteria (i.e 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. 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. 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 authenticate per-domain and per-address information, including potentially public keys for use with encryption and digital signatures. While it appears to have the advantage of being deployable, as most service providers will already be familiar with TLS and X.509 certificate management, the Address Query service may invest more trust in such servers and their key management practices than was designed for. Moore & Newman Expires January 20, 2016 [Page 17] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 o The Address Query Proxy extension to the Submission service inherently requires the client and user to trust the Submission server to do correct validation and correct name matching of SMTP servers' certificates, as there is no good way to transfer the integrity and authenticity assurances provided by the TLS protocol to the Submission server from the remote SMTP server, to the Submission client. o With AQRY as it's currently specified, a mail service provider supporting multiple client domains will either need to manage multiple certificates and private keys (one or more for each client domain), or refer queries to a separate server, managed by the client, for each client. A client may prefer to not expose its private key to a mail service provider. However this choice MAY be made on a per-client basis. o Especially since the Address Query SMTP service extension does not require authentication, and since it may potentially provide arbitrary information about an email address or mail domain, attackers may attempt to use it to "mine" or "harvest" information about arbitrary mail addresses and their users. It is recommended that only the minimum information necessary for the desired level of mail operation be exposed through this service. In addition, servers MAY return "fake" information for nonexistent recipients in order to discourage probing of arbitrary addresses. Servers MAY also implement rate limiting of AQRY command processing, though this may not be effective against distributed information gathering networks. o As compared to most uses of SMTP and Submission protocols which primarily transmit data from client to server, this extension is specifically designed to transmit potentially-significant amounts of data from the server to the client. As such, client implementations MUST NOT fail or corrupt internal data when receiving large amounts of data in an SMTP response, nor when processing the returned data (whether or not correctly formatted). o There is some potential for the AQPX Submission service extension to be used as a means of traffic laundering when attacking other services. However this potential is believed to be minimal (except for data harvesting attack described above) as this service only communicates with other hosts on TCP port 25 and is limited to a very specific SMTP command sequence. Submission servers MUST require authentication before accepting AQPX commands, SHOULD implement rate limiting of such commands or other mechanism to prevent single clients from overusing the service, and SHOULD log at least the number of AQPX queries on a per-user basis. Moore & Newman Expires January 20, 2016 [Page 18] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 o The proposed data model anticipates this service being useful for any of several modes of per-message encryption. In addition to end-to-end encryption (in which encryption is done by the sender's MUA and decryption is done by the recipient's MUA), it is also possible for encryption to be done by the sender's Submission agent, or for the decryption to be done by the recipient's SMTP server or delivery agent or message store (if the sender's MUA or Submission agent encrypt the message for the recipient domain's encryption key). While end-to-end encryption is in some sense the ideal situation, as it theoretically minimizes the potential for exposure of messages, there are several "real world" barriers to its universal adoption. One such barrier is that the majority of mail users today use webmail services in which end-to-end is a fairly meaningless concept. Another such barrier is the widespread use of spam filters and message filtering firewalls which require exposure to received messages in cleartext to be useful. Another such barrier is the legal or other requirement that many organizations have for archival of email communications. Finally, many kinds of personal computer are notoriously insecure, 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 permitting flexibility in how email encryption is done it is hoped that encryption may be more widely deployed and that it will provide an upgrade path to optimal security for everyone. 8. IANA Considerations (this section requires elaboration.) 8.1. Registration for AQRY SMTP service extension (to be written) 8.2. Registration for AQPX Submission service extension (to be written) 8.3. Registration for new Enhanced Status Codes Code: X.4.IANA-1 (XXX replace IANA-1) Sample Text: no information available for this address 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 Moore & Newman Expires January 20, 2016 [Page 19] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 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 Moore & Newman Expires January 20, 2016 [Page 20] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 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 does not match 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 Moore & Newman Expires January 20, 2016 [Page 21] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 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 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2920] Freed, N., "SMTP Service Extension for Command Pipelining", STD 60, RFC 2920, DOI 10.17487/RFC2920, September 2000, . [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, February 2002, . [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . Moore & Newman Expires January 20, 2016 [Page 22] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, . [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, . [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, . [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, . [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 mail: Part I - message encipherment and authentication procedures", RFC 1113, DOI 10.17487/RFC1113, August 1989, . Moore & Newman Expires January 20, 2016 [Page 23] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, . [RFC2034] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, DOI 10.17487/RFC2034, October 1996, . [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, DOI 10.17487/RFC3464, January 2003, . [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, DOI 10.17487/RFC4880, November 2007, . [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, . [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, . [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized Email", RFC 6531, DOI 10.17487/RFC6531, February 2012, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC7293] Mills, W. and M. Kucherawy, "The Require-Recipient-Valid- Since Header Field and SMTP Service Extension", RFC 7293, DOI 10.17487/RFC7293, July 2014, . Appendix A. Rationale For Design Choices This section is not normative. o As described above, the choice of using an SMTP extension for this purpose, and using mail exchangers for the authoritative sources Moore & Newman Expires January 20, 2016 [Page 24] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 of this information, resulted from the observation that only the SMTP servers for incoming mail for a mail domain reliably know how to interpret an email address from that mail domain. o The redirect response was included because many mail service providers accept incoming mail for large numbers of mail domains, and that it is infeasible and generally inappropriate for a large mail service provider to maintain server certificates that name each of the mail domains for which it provides service. The redirect response thus permits referral of a request to a specific server for each mail domain. The redirect response also may be useful in the case where the listed MX servers for a mail domain do not handle incoming mail directly, but rather forward it to or through one or more internal servers (e.g. firewalls, spam filters) before the message reaches the server responsible for address interpretation and delivery. Finally, the redirect response may be useful in allowing a heavily-loaded server to devote its resources to mail delivery by referring queries about email address information elsewhere. o Originally the redirect response contained https URLs, and the queries to other servers were to use http/1 or http/2. This appeared to make client implementations unnecessarily complex, for several reasons: differences in error reporting between SMTP and HTTP required two sets of error codes and different logic on the client side for each, the existence of HTTP redirects coupled with the need to verify subjectAltName in server certificates appeared to make it difficult to reuse ordinary HTTP library routines. So redirects were changed to specify the DNS name or address, and port, of one or more SMTP servers, thus allowing reuse of the same code on the client for both kinds of query. o As indicated above, the Submission extension was created as a workaround for the common practice of blocking outbound TCP traffic to a destination port of 25. However, it also seemed appropriate for a Submission server to support this functionality based on an anticipated desire for a Submission server to support additional extensions (not defined in this document) for server- side signing and/or encryption of submitted mail. o The Submission AQPX command doesn't support arbitrary ports because it seemed like too much of an opportunity for clients to use that facility for malicious purposes, even if the clients do have to be authenticated. It might be worth considering reserving a specific port for SMTP AQRY referrals. o The Submission AQPX command doesn't handle MX lookup, referrals, or retries because of concern over timeout hazards, and because it Moore & Newman Expires January 20, 2016 [Page 25] Internet-Draft SMTP/SUBMISSION Email Address Query July 2015 seemed better to let clients perform these operations than to burden servers with them. Authors' Addresses Keith Moore Network Heretics PO Box 1934 Knoxville, TN 37901 US Email: moore@network-heretics.com Chris Newman Oracle 440 E. Huntington Dr., Suite 400 Arcadia, CA 91006 US Email: chris.newman@oracle.com Moore & Newman Expires January 20, 2016 [Page 26]