SMTP and SUBMISSION Service Extensions For Address Query
Network HereticsPO Box 1934KnoxvilleTNUS37901moore@network-heretics.comOracle440 E. Huntington Dr., Suite 400ArcadiaCAUS91006chris.newman@oracle.com
ART
I-DInternet-Draft
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.
At least since the introduction of MIME
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 ,
S/MIME , and OpenPGP )
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 for use in discovery of email
recipients' public 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.
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 .This specification expresses syntax using the Augmented Backus-Naur
Form (ABNF) as described in , including the core
rules in Appendix B and rules from .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 breaks between those lines are for editorial
clarity only and are not part of the actual protocol exchange.
This section defines a service extension to the Simple Message
Transfer Protocol (SMTP) which can be
used by a client to
query the server for information about an email address for which the
server accepts incoming mail.
The Name of this extension is "Address Query".Servers implementing this extension advertise an additional EHLO
keyword of "ADDRQUERY", which has no associated parameters.This extension introduces one new SMTP command, AQRY, described below.
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.
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) 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 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
(or if the SMTP server supports the
SMTPUTF8 extension, Mailbox is as defined in ),
and date-time is as defined in , 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
,
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.)
Clients wishing to query for email address information MUST first
perform a DNS 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 : servers with
lower 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
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 .
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
) or a CN-ID
(CN attribute from subject name, see ) 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 .
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 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.
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
subsequently encoded in BASE64 format as defined in
. 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 .
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 .
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.
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:
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
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:
DNS name, IPv4 address, or IPv6 address
of an SMTP server.Optional port number to be used to
contact the SMTP server.
Port 25 is assumed if this element is not supplied.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 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:
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):The client could then obtain the requested information via any
of the following:
Open a connection to foo.example.com, port 9876, negotiate STARTTLS,
then issue the command: "AQRY <joe@example.com> COOKIE=lkjseoru", Open a connection to 10.1.2.3, port 25, negotiate STARTTLS,
then issue the command: "AQRY <joe@example.com> COOKIE=sfwerv33", OROpen a connection to 2001:DB8:abcd::1:2, port 4325, negotiate STARTTLS,
then issue the command "AQRY <joe@example.com> 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.
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.
In addition to reply codes defined in ,
the following reply codes SHOULD be used to indicate the
error conditions described below. In each case below the enhanced
status code that appears immediately
following the 3-digit SMTP reply code
is suggested for use by server implementations supporting the SMTP
ENHANCEDSTATUSCODES extension . 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
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 .
(RFC Editor: please remove this paragraph on publication.)
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]]
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.
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.
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.
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.]]
The server is not configured to accept incoming mail for the
domain name appearing in the address.
This reply code is returned whenever a client attempts an AQRY
command in a SMTP session that is not protected by TLS.
This section defines a service extension to the Mail Submission
Protocol 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.
The Name of this extension is "Address Query Proxy".Servers implementing this extension advertise an additional EHLO
keyword of "ADDRQUERYPROXY", which has no associated parameters.This extension introduces one new Submission command, AQPX,
described below.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.
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:
verify that the user is authenticated via a TLS-protected sessionconsult the SMTP server specified in the AQPX command, negotiate a TLS session using STARTTLS, verify that the server's certificate is valid and has an appropriate
subjectAltName for the address, and if so,issue an AQRY command to that server, andreturn 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
where IPv4-address-literal, IPv6-address-literal,
Atom, Domain, and Mailbox are as defined in
(or if the Submission server supports the
SMTPUTF8 extension, Domain and Mailbox are as defined in
), and date-time is as defined in
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.
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:
431 4.4.2 connection or query to remote SMTP server timed out541 5.7.IANA-5 invalid remote server certificate542 5.7.IANA-6 server certificate for <smtp-server-name> does not
match <domain>43x 4.x.y DNS query timed out5xx 5.x.y No MX records found
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 , 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
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:
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.)
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.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.)Either true or
false depending on whether the submission service will permit
already-encrypted messages to be submitted.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.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.
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:
Describes the conditions
in which the sender signs outgoing mail.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.Describes the
conditions in which the sender encrypts outgoing mail.Describes the
encrypted message formats accepted by the recipient.A set of
[ format, key ] pairs listing the message formats and public keys
for which the recipient is able to decrypt mail.A list of
signed message formats that the recipient can potentially verify.A list of
forwarding addresses that the recipient wishes to publicly disclose.
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 ) or a
CN-ID (CN attribute from subject name, )
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
.
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.
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.
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.
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.
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).
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.
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.
(this section requires elaboration.)(to be written)(to be written)X.4.IANA-1 (XXX replace IANA-1)
no information available for this address
511
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.(XXX this document)K. Moore, C. NewmanIESGX.3.IANA-2 (XXX replace IANA-2)service not supported for this domain513
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.
(XXX this document)K. Moore, C. NewmanIESGX.3.IANA-3 (XXX replace IANA-3)
incoming mail not accepted for this domain
557
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.
(XXX this document)K. Moore, C. NewmanIESGX.4.IANA-4 (XXX replace IANA-4)TLS required but not negotiated523
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.
(XXX this document)K. Moore, C. NewmanIESGX.4.IANA-5 (XXX replace IANA-5)
invalid remote server certificate
541
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.
(XXX this document)K. Moore, C. NewmanIESGX.4.IANA-6 (XXX replace IANA-6)
service certificate provided by <server-name> does not match
<domain>
542
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.
(XXX this document)K. Moore, C. NewmanIESGXXXXXXXXXThis section is not normative.As described above, the choice of using an SMTP extension for
this purpose, and using mail exchangers for the authoritative
sources 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.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.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.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.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.The Submission AQPX command doesn't handle MX lookup,
referrals, or retries because of concern over timeout hazards,
and because it seemed better to let clients perform these
operations than to burden servers with them.