One document matched: draft-ietf-dane-smtp-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2033.xml">
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3207 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3207.xml">
<!ENTITY rfc3461 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3461.xml">
<!ENTITY rfc3464 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3464.xml">
<!ENTITY rfc3848 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3848.xml">
<!ENTITY rfc4033 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY rfc4035 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY rfc4409 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4409.xml">
<!ENTITY rfc4954 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4954.xml">
<!ENTITY rfc5068 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5068.xml">
<!ENTITY rfc5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc5246 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5280 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY rfc5321 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5321.xml">
<!ENTITY rfc5322 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml">
<!ENTITY rfc5598 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5598.xml">
<!ENTITY rfc5890 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5890.xml">
<!ENTITY rfc6066 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml">
<!ENTITY rfc6125 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6125.xml">
<!ENTITY rfc6186 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6186.xml">
<!ENTITY rfc6698 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6698.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- autobreaks="yes" -->
<?rfc comments="yes" ?> <?rfc inline="yes" ?>
<?rfc compact="yes" ?> <?rfc subcompact="no" ?>
<!-- editing="no" -->
<?rfc iprnotified="no" ?>
<!-- linkmailto="yes" -->
<!-- private="" --> <!-- header="" --> <!-- footer="" -->
<!-- slides="no" --> <!-- background="" -->
<!-- sortrefs="no" --> <?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?> <!-- tocompact="yes" --> <!-- tocdepth="3" --> <!-- tocindent="yes" -->
<!-- topblock="no" -->
<!-- $Cambridge: hermes/doc/qsmtp/draft-fanf-dane-smtp.xml,v 1.41 2013/01/25 14:30:11 fanf2 Exp $ -->
<rfc ipr="trust200902"
category="std"
docName="draft-ietf-dane-smtp-00">
<!-- === -->
<front>
<title abbrev="SMTP with TLSA">
Secure SMTP with TLS, DNSSEC and TLSA records.
</title>
<author initials="T." surname="Finch" fullname="Tony Finch">
<organization abbrev="University of Cambridge">
University of Cambridge Computing Service
</organization>
<address>
<postal>
<street>New Museums Site</street>
<street>Pembroke Street</street>
<city>Cambridge</city>
<code>CB2 3QH</code>
<country>ENGLAND</country>
</postal>
<phone>+44 797 040 1426</phone>
<email>dot@dotat.at</email>
<uri>http://dotat.at/</uri>
</address>
</author>
<date month="January" year="2013"/>
<area>Security</area>
<workgroup>DNS-Based Authentication of Named Entities (DANE)</workgroup>
<abstract>
<t>SMTP has a STARTTLS extension, but (especially in the case of
inter-domain mail transfer) it only provides very limited security
because it does not specify how to authenticate the server's
certificate. This memo specifies how TLSA records in the DNS can
be used for proper SMTP server authentication.</t>
</abstract>
</front>
<middle>
<!-- === -->
<section anchor="intro" title="Introduction">
<t>The specification for SMTP over TLS <xref target="RFC3207"/>
does not describe how to authenticate a server: which identity
relating to the connection ought to be authenticated by the
server's certificate. In practice, most certificates presented by
publicly-referenced SMTP servers either cannot be validated with
respect to a well-known certification authority, or do not verify
any identity expected by the client.</t>
<t>As a result, inter-domain SMTP clients cannot require working
server authentication if they want to successfully send mail using
TLS. Therefore TLS currently provides only a limited amount of
additional security for inter-domain SMTP. Its encryption protects
against on-path passive eavesdropping; but it does not protect
against an active attack, since the client has no way to detect
when an attacker is spoofing the server.</t>
<t>This memo describes how to fix this
using DNSSEC <xref target="RFC4033"/>
and TLSA records <xref target="RFC6698"/>
with owner names of the form "_25._tcp.hostname".</t>
<t>We use DNSSEC to secure the association between a mail domain
and its SMTP server host names, and between the host names and
their certificates. Connections to servers are authenticated by
their TLS certificates.</t>
<t>As well as its normal function of providing an association
between a domain name and a certificate, we are also using the
existance of a TLSA record to signal to the client that it can
expect the server to offer TLS with a valid certificate.</t>
<t>The security situation is better for intra-domain SMTP, because
in this case the client and server can be configured with prior
knowledge of how to authenticate each other. This specification
can also be used for authenticating servers in intra-domain
SMTP.</t>
<t>This memo does not cover message submission
<xref target="RFC4409"/> <xref target="RFC5068"/> <xref target="RFC6186"/>,
nor does it cover LMTP <xref target="RFC2033"/>,
since they use the DNS in a different way than MTA-to-MTA SMTP.</t>
<t>The protocol described in this memo adds new security checks
that can cause email delivery to be delayed when a security
failure is detected. We specify that clients treat a problems as a
"temporary failure", causing the message to be queued for a later
delivery attempt, in the hope that the attack (or configuration
error) will have been dealt with.</t>
<section title="Questions for reviewers">
<t>Is the Transmitted: header useful enough to include in this
spec? Should it be dropped, or perhaps moved to another
document?</t>
<t>Is the "dane" MTA-name-type for use in delivery status
notifications a good idea? Is it likely to cause interoperability
problems?</t>
<t>Is the description of DNSSEC validation over-done? Can it be
trimmed down so it relies more on the core DNSSEC specs?</t>
</section>
</section>
<!-- === -->
<section title="Terminology">
<t><list style="hanging">
<t hangText="ADMD:">
An ADministrative Management Domain, as described in the Internet
Mail Architecture <xref target="RFC5598"/>.
</t>
<t hangText="Inter-domain SMTP:">
SMTP between different ADMDs across the public Internet, where a
client MTA sends mail to a publicly-referenced SMTP server MTA.
</t>
<t hangText="Intra-domain SMTP:">
SMTP between MTAs within an ADMD.
</t>
<t hangText="Mail domain:">
The part of an email address after the "@"; also the owner name
of a (possibly implicit) MX record.
</t>
<t hangText="MX resolution:">
The algorithm for resolving a mail domain into a set of SMTP
server hosts, described in <xref target="RFC5321"/> section 5.
</t>
<t hangText="Publicly-referenced SMTP server:">
An SMTP server which runs on port 25 of an Internet host located
using MX resolution. (This term is from
<xref target="RFC3207"/>.)
</t>
<t hangText="SMTP server host name:">
The target of a (possibly implicit) MX record.
</t>
</list></t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
memo are to be interpreted as described in <xref target="RFC2119"/>.</t>
</section>
<!-- === -->
<section anchor="details" title="Inter-domain SMTP with TLSA">
<t>In the following we describe some additions to the usual MX
resolution algorithm described in <xref target="RFC5321"/> section
5. If there is any conflict between this memo and the other
specifications cited in this section, that is an error in this
memo.</t>
<section title="MX lookup checks">
<t>The client SHALL look up the MX RRset for the mail domain. There
are three succesful results that yield a list of SMTP server host
names:
<list style="symbols">
<t>A list of one or more MX records;</t>
<t>An implicit MX record, in lieu of an empty list of MX records;</t>
<t>A CNAME or DNAME pointing to a successful result.</t>
</list>
</t>
<t>If the lookup is not successful, the client SHALL proceed as
described in <xref target="RFC5321"/> section 5.</t>
<t>If any of the responses is "bogus" according to DNSSEC
validation (<xref target="RFC4033"/> section 5) the client MUST
treat this as a temporary error.</t>
<t>For this protocol to take effect, all of these DNS RRsets MUST
be "secure" according to DNSSSEC validation. In the case of an
implicit MX record, there MUST be a secure denial of existence of
an MX RRset for the mail domain. In the case of a (chain of)
CNAME or DNAME RRs, the whole chain MUST be secure as well as
the ultimate target.</t>
<t>If they are not all secure, this protocol has not been fully
deployed. The client SHOULD fall back to insecure delivery (which
might be over unauthenticated TLS).</t>
<t>(If the client is using a non-validating security-aware stub
resolver (see <xref target="RFC4033"/> section 7), it can rely on
its recursive name server to perform these checks and set the AD
bit according to the result - see <xref target="RFC4035"/>
section 3.2.3.)</t>
<t>The client now has an authentic list of SMTP server host names
and priority values. It processes this list as described in
<xref target="RFC5321"/> section 5 (sorting the host names etc.)
without regard to the presence or absence of DNSSEC or TLSA
records.</t>
</section>
<section anchor="nomx" title="SMTP server checks">
<t>This sub-section applies to each SMTP server host name
individually.</t>
<t>When connecting to a server, the client SHALL look up the
server's TLSA RRset as described in
<xref target="RFC6698"/> section 3. That is, the
TLSA RRset owner name SHALL be "_25._tcp.hostname" where
"hostname" is the SMTP server host name. The response can be one
of the following (as listed in
<xref target="RFC6698"/> section 4.1):
<list style="symbols">
<t>A secure answer containing one or more TLSA records, in which
case the client SHALL proceed as descrbed below.</t>
<t>A bogus answer or other failure, which the client MUST treat
as a temporary error.</t>
<t>If there is no TLSA record or its DNSSEC validation state is
insecure or indeterminate, this protocol has not been fully
deployed. The client SHOULD deliver to this server insecurely
(which might be over unauthenticated TLS, as described in the
introduction).</t>
</list>
</t>
<t>The client now has one or more TLSA records for the server it is
connecting to.</t>
<t>The client MUST ensure that the server offers the STARTTLS
service extension <xref target="RFC3207"/> in its response to the
client's EHLO command (<xref target="RFC5321"/> section 4.1.1.1).</t>
<t>The client SHALL then issue the STARTTLS command which MUST be
successful. It then proceeds with TLS negotiation
<xref target="RFC5246"/>. If the client uses the Server Name
Indication TLS extension (<xref target="RFC6066"/> section 3) it
MUST use the SMTP server host name as the value for the
ServerName field.</t>
<t>The client SHALL validate the server's certificate as described
in <xref target="RFC6698"/> section 2.1. (This might or might not
include PKIX certificate validation
<xref target="RFC5280"/>.)</t>
<t>The client SHALL verify that the server host name matches the
identity asserted by the server's certificate as described in
<xref target="RFC6125"/> section 6. Following that specification,
the client's list of reference identifiers SHOULD include the
SMTP server host name with type DNS-ID, and MAY include a second
copy of the host name with type CN-ID.</t>
<t>If any of these checks fail, the client MUST disconnect from the
server and treat this as a temporary failure.</t>
<t>If all the checks pass, the client can then proceed to deliver
mail securely.</t>
</section>
</section>
<!-- === -->
<section title="Intra-domain SMTP with TLSA">
<t>Mail transmission within an ADMD can be based on MX records
(such as when delivering incoming mail to its destination host) or
on statically configured host names (such as when routing outgoing
mail via a border relay).</t>
<t>When routing internal mail using MX records,
<xref target="details"/> applies the same as for inter-domain
SMTP.</t>
<t>When routing mail using host names, the MX lookup step is
skipped and only <xref target="nomx"/> applies.</t>
</section>
<!-- === -->
<section title="The Transmitted: header field">
<t>The client MAY wish to insert a Transmitted: header field at the
start of the message header just before transmitting the message.
This records the result of the checks specified in the previous
section. (See <xref target="security"/> for some comments on its
utility or lack thereof.) It is a client-side counterpart to the
Received: header field (<xref target="RFC5321"/> section 4.4) and
has very similar syntax. It SHOULD be treated as a trace
field.</t>
<t>The syntax of the Transmitted: header field is described using
ABNF <xref target="RFC5234"/>. Non-terminal syntax rules not
defined in this memo are defined in <xref target="RFC5321"/>, or
<xref target="RFC5322"/>, or <xref target="RFC5234"/>.</t>
<t><figure>
<artwork><![CDATA[
Transmitted-line = "Transmitted:" FWS To-domain By-domain
Opt-info [CFWS] ";" date-time CRLF
To-domain = "TO" FWS Extended-Domain
]]></artwork>
</figure></t>
<t>A <Transmitted-line> SHALL include:
<list style="symbols">
<t>A <To-domain> clause describing the SMTP server. The
<Domain> part of a <To-domain> SHALL be the same as
the SMTP server host name.</t>
<t>A <By-domain> clause identifying the SMTP client that
added the header. (If the client also acts as a server this is
the same <By-domain> clause it would include in any
Received: header fields it adds.) This clause helps with
recovery if the original order of a message header's fields has
been lost.</t>
<t>Various <Opt-info> clauses, which MUST include a
<With> clause. The <Protocol> part of this clause is
used to indicate whether the client successfully authenticated
the server, using one of the types specified in
<xref target="with"/>.</t>
<t>And a <date-time> to further help with disordering in
case a message is transmitted by the same client more than
once.</t>
</list></t>
</section>
<!-- === -->
<section title="IANA Considerations">
<section anchor="with" title=""with" protocol types">
<t>The "with" protocol type registry includes a number of keywords
that indicate the use of SMTP with or without TLS and/or AUTH
<xref target="RFC3848"/>. When these types appear in a
Transmitted: header field "with" clause they indicate that the
client did not authenticate the server as described in
<xref target="details"/>.</t>
<t><list style="symbols">
<t>The new keyword "ESMTPT" indicates the use of ESMTP
<xref target="RFC5321"/> with STARTTLS <xref target="RFC3207"/>
when the client successfully authenticated the server.</t>
<t>The new keyword "ESMTPTA" indicates the use of ESMTP
<xref target="RFC5321"/> with STARTTLS <xref target="RFC3207"/>
and AUTH <xref target="RFC4954"/> when the client successfully
authenticated the server.</t>
</list></t>
<t>These new keywords are not for use in Received: header fields
since the server cannot tell whether or not the client
authenticated it.</t>
<t>There are no keywords corresponding to a client trying and
failing to authenticate the server, since in this case no message
transmission occurs.</t>
</section>
<section title="Permanent message header field registration">
<t><list style="hanging">
<t hangText="Header field name:"> Transmitted: </t>
<t hangText="Applicable protocol:"> mail </t>
<t hangText="Status:"> standard </t>
<t hangText="Change controller:"> IETF </t>
<t hangText="Specification document"> this memo </t>
</list></t>
</section>
<section title=""dane" MTA-name-type">
<t>Delivery status notifications <xref target="RFC3464"/> can
include a Remote-MTA field recording an SMTP server host name.
When this has been authenticated according to
<xref target="details"/> the reporting MTA MAY use an
MTA-type-name of "dane".</t>
<t><list style="letters">
<t>MTA-type-name: "dane"</t>
<t>Syntax: same as the "dns" MTA-type-name <xref target="RFC3461"/></t>
<t>Translation into US-ASCII: none needed</t>
</list></t>
</section>
</section>
<!-- === -->
<section anchor="security" title="Security considerations">
<section title="Fallback to insecure SMTP">
<t>This memo provides only conditional security. It allows a
server to publish in the DNS the details of how it can be
authenticated. Clients that implement this protocol can use it to
provide a strong guarantee that they are sending mail to the
correct place. If either of these is missing, mail delivery will
be insecure.</t>
<t>There is no secure way for a server to tell if a client has
authenticated it using this protocol. This is a general
limitation of TLS. The Transmitted: header field records this
information for tracing and debugging and measuring deployment,
not for security purposes.</t>
<t>We do not specify that clients check that all of a mail
domain's SMTP server host names are consistent in whether they
have or do not have TLSA records. This is so that partial or
incremental deployment does not break mail delivery. Different
levels of deployment are likely if a domain has a third-party
backup MX, for example.</t>
<t>The MX sorting rules are unchanged; in particular they have not
been altered in order to prioritize secure servers over insecure
servers. If a site wants to be secure it needs to deploy this
protocol completely; a partial deployment is not secure and we
make no special effort to support it.</t>
</section>
<section title="A mail domain trusts its SMTP servers">
<t>By signing their zone with DNSSEC, a mail domain owner
implicitly instructs SMTP clients to check their SMTP server TLSA
records. This implies another point in the trust relationship
between mail domain owner and smtp server operator. Most of the
setup requirements for this protocol fall on the SMTP server
operator: installing a TLS certificate with the correct name, and
publishing a TLSA record under that name. If these are not correct
then mail delivery from TLSA-aware clients might be delayed.</t>
</section>
<section title="Temporary failures and denial of service">
<t>Many provisioning failures in SMTP cause "permanent" failures,
that is the immediate and final rejection of the message. This
includes missing DNS records, an SMTP server that is not
configured to accept mail for the recipient domain, and so
forth.</t>
<t>In this protocol, provisioning an incorrect TLS certificate
triggers a temporary error. This is because we want to minimise
the damage that occurs when an on-path attacker intercepts the TCP
connection between an SMTP client and server. An attacker can
cause delays, but is not able to trigger immediate delivery
failures.</t>
</section>
<section title="Certificate subject name matching">
<t>Section 4 of the TLSA specification <xref target="RFC6698"/>
leaves the details of checking names in certificates to higher
level application protocols, though it suggests the use of
<xref target="RFC6125"/>.</t>
<t>Name checking might appear to be unnecessary, since DNSSEC
provides a secure binding between the server name and the TLSA
record, which in turn authenticates the certificate. However this
latter step can be indirect, via a chain of certificates. A
usage=0 TLSA record only authenticates the CA that issued the
certificate, and third parties can obtain certificates from the
same CA.</t>
<t>So this specification says that SMTP clients check that the
server's certificate matches the server host name, to ensure that
the certificate was issued by the CA to the server that the client
is connecting to. The client always performs this check regardless
of the TLSA usage, because the implementation is simpler and so
that this specification is less likely to need updating when new
TLSA usages are added.</t>
</section>
<section title="Deliberate omissions">
<t>We do not specify that clients check the DNSSEC state of the
SMTP server address records. This is not necessary since the
certificate checks ensure that the client has connected to the
correct server. (The address records will normally have the same
security state as the TLSA records, but they can differ if there
are CNAME or DNAME indirections.)</t>
<t>This memo does not specify any changes to SMTP client
authentication. Inter-domain SMTP client authentication remains
extremely weak. Intra-domain SMTP can be configured as strong as
necessary (using SMTP AUTH or TLS client certificates, for
instance) but that is out of scope for this memo.</t>
</section>
</section>
<!-- === -->
<section title="Internationalization Considerations">
<t>If any of the DNS queries are for an internationalized domain
name, then they need to use the A-label form
<xref target="RFC5890"/>.</t>
</section>
<!-- === -->
<section title="Acknowledgements">
<t>Thanks to Mark Andrews for arguing that authenticating the SMTP
server host name is the right thing, and that we ought to rely on
DNSSEC to secure the MX lookup. Thanks to James Cloos, Ned Freed,
Olafur Gudmundsson, Paul Hoffman, Phil Pennock, Hector Santos,
Jonas Schneider, and Alessandro Vesely for helpful
suggestions.</t>
</section>
<!-- === -->
</middle>
<back>
<!-- === -->
<references title="Normative References">
&rfc2119; <!-- MUSTard MAYonnaise -->
&rfc3207; <!-- SMTP STARTTLS extension -->
&rfc3461; <!-- SMTP DSN extension -->
&rfc3464; <!-- DSN messages -->
&rfc3848; <!-- "with" protocols -->
&rfc4033; <!-- DNSSEC overview -->
&rfc4035; <!-- DNSSEC protocol -->
&rfc4954; <!-- SMTP AUTH extension -->
&rfc5234; <!-- ABNF -->
&rfc5246; <!-- TLS -->
&rfc5280; <!-- PKIX -->
&rfc5321; <!-- ESMTP -->
&rfc5322; <!-- Message format -->
&rfc5890; <!-- IDNA -->
&rfc6066; <!-- TLS extensions -->
&rfc6125; <!-- certificate verification -->
&rfc6698; <!-- DANE TLSA -->
</references>
<references title="Informative References">
&rfc2033; <!-- LMTP -->
&rfc4409; <!-- Mesasge submission -->
&rfc5068; <!-- Message submission ops -->
&rfc5598; <!-- Internet Mail Architecture -->
&rfc6186; <!-- SRV for mail clients -->
</references>
<!-- === -->
<section title="Example">
<t>In the following, most of the DNS resource data is elided for
simplicity.</t>
<t><figure>
<artwork><![CDATA[
; mail domain
example.com. MX 1 mx.example.net.
example.com. RRSIG MX ...
; SMTP server host name
mx.example.net. A 192.0.2.1
mx.example.net. AAAA 2001:db8:212:8::e:1
; TLSA resource record
_25._tcp.mx.example.net. TLSA ...
_25._tcp.mx.example.net. RRSIG TLSA ...
]]></artwork>
</figure></t>
<t>Mail for addresses at example.com is delivered by SMTP to
mx.example.net. Connections to mx.example.net port 25 that use
STARTTLS will get a server certificate that authenticates the name
mx.example.net.</t>
</section>
<!-- === -->
<section title="Rationale - choice of certificate identity">
<t>There are a number of reasons for the certificate to
authenticate the SMTP server host name rather than the mail
domain.</t>
<t>SMTP allows a client to transfer mail to recipients at multiple
domains in the same connection. If the certificate identifies the
host name then it does not need to list all the possible mail
domains.</t>
<t>It is not in general feasible for the server to select a mail
domain certificate based on the recipient domains when the
connection is established (using Server Name Indication,
<xref target="RFC6066"/> section 3), because an SMTP client might
not know all of the recipients when it establishes the
connection.</t>
<t>Outgoing SMTP relays and message submission servers handle mail
for any domain, so in those cases the only sensible option is for
the certificate to contain the host name. It is more consistent
for incoming MX server certificates to match.</t>
<t>It is common for SMTP servers to act in multiple roles, as
outgoing relays or as incoming MX servers, depending on the client
identity. It is simpler if the server can present the same
certificate regardless of the role in which it is to act.</t>
<t>Sometimes the server does not know its role until the client has
authenticated, which usually occurs after TLS has been
established.</t>
<t>This protocol does not provide an option for directly
authenticating the mail domain because that would add complexity
without providing any benefit, and security protocols are best
kept simple. As described above, there are real-world cases where
authenticating the mail domain cannot be made to work, so there
are complicated criteria for when mail domain TLSA records might
be used and when they cannot. This is all avoided by
authenticating the SMTP server host name.</t>
<t>Finally, this protocol only affects the logic in the SMTP client
and requires no additional SMTP server functionality, such as
support for the TLS Server Name Indication extension.</t>
</section>
<!-- === -->
<section title="Change log">
<section title="Changes in version -00">
<t>Change doc name from draft-fanf-dane-smtp to draft-ietf-dane-smtp.</t>
<t>Update DANE citation to published RFC.</t>
<t>Be clearer about the PKIX certificate validation vs.
certificate subject name matching.</t>
<t>Minor clarifications suggested by Phill Hallam-Baker and James Cloos.</t>
</section>
<section title="Changes in version fanf-04">
<t>Add some questions for reviewers</t>
<t>Add a note about stub resolvers and the AD bit.</t>
<t>Internationalization considerations.</t>
</section>
<section title="Changes in version fanf-03">
<t>Clarify how to use SNI with this protocol.</t>
<t>Clarify lack of changes to MX sorting rules.</t>
<t>Mention DNAME as well as CNAME.</t>
<t>An example.</t>
</section>
<section title="Changes in version fanf-02">
<t>Clarify the wording that describes how a client determines that
this protocol is in effect.</t>
<t>Divide the security considerations into sub-sections, and add a
subsection on denial of service.</t>
<t>Clarify intro, mentioning TLSA owner name format.</t>
<t>Extend the scope to cover MTA-to-MTA mail within an ADMD as
well as between ADMDs.</t>
</section>
<section title="Changes in version fanf-01">
<t>More about why not to authenticate mail domains in the rationale.</t>
<t>Change DNS-ID requirement from MUST to SHOULD to follow RFC 6125.</t>
<t>Acknowledgments section.</t>
<t>Transmitted: header trace field. Not sure if this is a good
idea; feedback wanted.</t>
<t>"dane" MTA-name-type for use in DSNs. Even less sure if this is
a good idea.</t>
</section>
</section>
<!-- === -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:39 |