One document matched: draft-ietf-dkim-overview-05.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY ar PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kucherawy-sender-auth-header.xml'>
<!ENTITY rfc2440bis PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-openpgp-rfc2440bis.xml'>
<!ENTITY rfc2821 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2821.xml'>
<!ENTITY rfc2822 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2822.xml'>
<!ENTITY pem PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0989.xml'>
<!ENTITY moss PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1848.xml'>
<!ENTITY pgp1 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1991.xml'>
<!ENTITY rfc2440 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2440.xml'>
<!ENTITY rfc3156 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3156.xml'>
<!ENTITY syslog PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3164.xml'>
<!ENTITY rfc3851 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3851.xml'>
<!ENTITY dkimta PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4686.xml'>
<!ENTITY dkimbase PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4871.xml'>
<!ENTITY dk PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4870.xml'>
]>
<!-- 3 levels is messy --> <?rfc tocdepth="2" ?>
<!-- may be omitted for very short documents --> <?rfc toc="yes"?>
<!-- strict ID-nits compliance --> <?rfc strict="no"?>
<!-- these two save paper: start new paragraphs from the same page etc. -->
<?rfc compact="yes"?> <?rfc subcompact="no"?>
<!-- use symbolic cross references instead of [1], and sort them -->
<?rfc symrefs="yes"?> <?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<!-- other categories: bcp, exp, historic, std -->
<rfc category="info" ipr="full3978">
<front>
<title abbrev="DKIM Service Overview">DomainKeys Identified Mail (DKIM)
Overview</title>
<!-- add 'role="editor"' below for the editors if the requiring designation -->
<author fullname="Tony Hansen" initials="T." surname="Hansen">
<organization>AT&T Laboratories</organization>
<address>
<postal>
<street>200 Laurel Ave.</street>
<city>Middletown</city>
<region>NJ</region>
<code>07748</code>
<country>USA</country>
</postal>
<email>tony+dkimov@maillennium.att.com </email>
</address>
</author>
<author fullname="Dave Crocker" initials="D." surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Dr.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<author fullname="Phillip Hallam-Baker" initials="P."
surname="Hallam-Baker">
<organization>VeriSign Inc.</organization>
<address>
<email>pbaker@verisign.com</email>
</address>
</author>
<date year="2007" />
<!-- month="May" is no longer necessary -->
<area>Security</area>
<!-- WG name at the upperleft corner of the doc, IETF fine for individual submissions -->
<workgroup>DomainKeys Identified Mail</workgroup>
<keyword>Email</keyword>
<keyword>Electronic Mail</keyword>
<keyword>Internet Mail</keyword>
<keyword>Message Verification</keyword>
<abstract>
<t> DomainKeys Identified Mail (DKIM) associates a "responsible"
identity with a message and provides a means of verifying that the
association is legitimate. <xref target="RFC4871" />
DKIM defines a domain-level authentication framework for email
using public-key cryptography and key server technology. This
permits verifying the source or intermediary for a message, as
well as the contents of messages. The ultimate goal of this
framework is to permit a signing domain to assert responsibility
for a message, thus proving and protecting the identity associated
with the message and the integrity of the messages itself, while
retaining the functionality of Internet email as it is known
today. Such protection of email identity may assist in the global
control of "spam" and "phishing". This document provides an
overview of DKIM, describes how it can fit into a messaging
service, describes how it relates to other IETF message signature
technologies, and includes implementation and migration
considerations. </t>
</abstract>
</front>
<middle>
<section title="DKIM Framework">
<section title="Introduction">
<t> DomainKeys Identified Mail (DKIM) associates a "responsible"
identity with a message and provides a means of verifying that
the association is legitimate. <xref target="RFC4871" />
DKIM accomplishes this by defining a domain-level
authentication framework for email using public-key
cryptography and key server technology. This permits verifying
the source or intermediary for a message, as well as the
contents of messages. DKIM will also provide a mechanism that
permits potential email signers to publish information about
their email signing practices; this will permit email receivers
to make additional assessments of unsigned messages.</t>
<t>The ultimate goal of this framework is to permit a domain to
assert responsibility for a message, thus proving and
protecting the identity associated with the message and the
integrity of the messages itself, while retaining the
functionality of Internet email as it is known today. Such
protection of email identity, may assist in the global control
of "spam" and "phishing". </t>
<t> This document provides a description of DKIM's architecture,
functionality, deployment and use. It is intended for those who
are adopting, developing, or deploying DKIM. It also will be
helpful for those who are considering extending DKIM, either
into other areas of use or to support additional features. This
Overview does not provide information on threats to DKIM or
email, or details on the protocol specifics, which can be found
in <xref target="RFC4871" /> and <xref
target="RFC4686" />, respectively. The document assumes a
background in basic network security technology and services. </t>
<t> It must be stressed that neither this document nor DKIM
attempt to provide solutions to the world's problems with spam,
phish, virii, worms, joe jobs, etc. DKIM provides one basic
tool, in what needs to be a large arsenal, for improving the
safety of Internet mail. However, by itself, DKIM is not
sufficient to that task and this overview does not pursue the
issues of integrating DKIM into these larger efforts. Rather,
it is a basic introduction to the technology and its
deployment. </t>
<section title="The DKIM Value Proposition">
<t>The nature and origins of a message are often falsely
stated. As a foundation for distinguishing legitimate mail,
DKIM provides a means of associating a verifiable identity
with a message. Given the presence of that identity, a
receiver can make decisions about further handling of the
message, based upon assessments of that identity.</t>
<t>Receivers who successfully verify a signature can use
information about the signer as part of a program to limit
spam, spoofing, phishing, or other undesirable behavior.
DKIM does not, itself, prescribe any specific actions by the
recipient; rather it is an enabling technology for services
that do. </t>
<t>These services will typically: <list style="numbers">
<t>Verify an identity</t>
<t>Determine whether the identity is known or unknown</t>
<t>Determine whether a known identity is trusted</t>
</list>
</t>
<t>An attack is made against an organization or against
customers of an organization. The name of the organization
is linked to particular Internet domain names. One point of
leverage used by attackers is either to spoof a legitimate
domain name, or to use a "cousin" name that is similar to
one that is legitimate, but is not controlled by the target
organization. A DKIM-based accreditation service can enforce
a basic separation between domains used by such known
organizations and domains used by others.</t>
<t>DKIM signatures can be created by a direct handler of a
message, either as its originator or as an intermediary. It
can also be created by an independent service, providing
assistance to a handler of the message. Whoever does the
signing chooses the domain name to be used as the basis for
later assessments. Hence, reputation associated with that
domain name is the basis for evaluating whether to trust the
message for delivery. The owner of the domain name being
used for a DKIM signature is declaring that they are
accountable for the message. </t>
<t>DKIM is intended to be a value-added feature for email. Mail
that is not signed by email is handled in the same way as it
now is; it continues to be evaluated by established analysis
and filtering techniques. Over time, widespread DKIM
adoption could permit degraded handling of messages that are
not signed. However early benefits do not require this
more-stringent enforcement.</t>
<t>It is important to be clear about the narrow scope of DKIM's
capabilities. It is an enabling technology, intended for use
in the larger context of determining message legitimacy.
This larger context is complex, so that it is easy to assume
that a component like DKIM, which actually provides only a
limited service, instead satisfies the broader set of
requirements. A DKIM signature : <list
style="symbols">
<t>Does not offer any assertions about the behaviors of the
identity doing the signing. </t>
<t>Does not prescribe any specific actions for receivers to take
upon successful (or unsuccessful) signature
verification. </t>
<t>Does not provide protection after signature verification. </t>
<t>Does not protect against re-sending (replay of) a message that
already has a verified signature; therefore a transit
intermediary or a recipient can re-post the message in
such a way that the signature would remain verifiable,
although the new recipient(s) would not have been
specified by the originator. </t>
</list>
</t>
</section>
<section title="Prior Work">
<t>Historical email assessment based on identity has been based
on the IP Address of a system that sent the message. The
Address is obtained via underlying Internet information
mechanisms and is therefore trusted to be accurate. Besides
having some known security weaknesses, the use of Addresses
present a number of functional and operational problems.
Consequently there is an industry desire to use a more
stable value that has had better correspondence with
organizational boundaries.
Domain Names are viewed as satisfying this need.</t>
<t> There have been four previous efforts at standardizing an
Internet email signature scheme: <list style="symbols">
<t>Privacy Enhanced Mail (PEM) was first published in
1987. <xref target="RFC0989" />
</t>
<t>PEM eventually transformed into MIME Object Security
Services in 1995. <xref target="RFC1848" />
Today, these two are only of historical interest.</t>
<t> Pretty Good Privacy (PGP) was developed by Phil
Zimmermann and first released in 1991.
<xref target="RFC1991" />
A later version was standardized as OpenPGP.
<xref target="RFC2440" />
<xref target="RFC3156" />
<xref target="I-D.ietf-openpgp-rfc2440bis" />
</t>
<t>RSA Security independently developed Secure MIME
(S/MIME) to transport a PKCS #7 data object.
<xref target="RFC3851" /></t>
</list> Development of S/MIME and OpenPGP have continued.
While both have achieved a significant user base, neither
have achieved ubiquity in deployment or use, and their goals
differ from those of DKIM. </t>
<t> To the extent that other message-signing services might
have been adapted to do the job that DKIM is designed to
perform, it was felt that re-purposing any of those would be
more problematic than creating a separate service. That
said, DKIM uses security algorithm components that have a
long history, including use within some of those other
messaging security services. </t>
<t> DKIM has a distinctive approach for distributing and
vouching for keys. It uses a key-centric Public Key
Infrastructure (PKI) rather than the more typical approaches
based on a certificate in the styles of Kohnfelder (X.509)
or Zimmermann (web of trust). For DKIM, the owner of a key
asserts its validity, rather than relying on the key having a
broader semantic implication of the assertion, such as a
quality assessment of the key's owner. DKIM treats quality
assessment as an independent, value-added service, beyond
the initial work of deploying a verifying signature service. </t>
<t> Further, DKIM's PKI is supported by adding additional information
records to the existing Domain Name Service (DNS) <xref
target="RFC1034" />, rather than requiring deployment of
a new query infrastructure. This approach has significant
operational advantages. First, it avoids the considerable
barrier of creating a new infrastructure; hence it leverages
a global base of administrative experience and highly
reliable distributed operation. Second, the technical aspect
of the DNS is already known to be efficient. Any new
service would have to undergo a period of gradual
maturation, with potentially problematic early-stage
behaviors. By (re-)using the DNS, DKIM avoids these growing
pains. </t>
</section>
<section title="Internet Mail Background">
<t>Internet Mail has a simple split between the user world, in
the form of Mail User Agents (MUA), and the transmission
world, in the form of the Mail Handling Service (MHS)
composed of Mail Transfer Agents (MTA). The MHS is
responsible for accepting a message from one User and
delivering it to one or more other users, creating a virtual
MUA-to-MUA exchange environment. The first MTA is called the
Mail Submission Agent (MSA) and the final MTA is called the
Mail Delivery Agent (MDA).</t>
<t>Modern Internet Mail service is marked by many independent
operators, many different components for providing users
with service and many other components for performing
message transfer. Consequently, it is necessary to
distinguish administrative boundaries that surround sets of
functional components.</t>
<section anchor="Administrative" title="Administrative Actors">
<t>Operation of Internet Mail services is apportioned to
different providers (or operators). Each can be composed
of an independent ADministrative Management Domain
(ADMD). An ADMD operates with an independent set of
policies and interacts with other ADMDs according to
differing types and amounts of trust. Examples include:
an end-user operating their desktop client that connects
to an independent email service, a department operating a
submission agent or a local Relay, an organization's IT
group that operates enterprise Relays, and an ISP
operating a public shared email service. </t>
<t>Each of these can be configured into many combinations of
administrative and operational relationships, with each
ADMD potentially having a complex arrangement of
functional components. <xref target="ADMD" /> depicts the
relationships among ADMDs. Perhaps the most salient
aspect of an ADMD is the differential trust that
determines its policies for activities within the ADMD,
versus those involving interactions with other ADMDs. </t>
<t>Basic components of ADMD distinction include: <list>
<t>
<list style="hanging">
<t hangText="Edge: ">Independent transfer
services, in networks at the edge of the
Internet Mail service.</t>
<t hangText="User: ">End-user services. These
might be subsumed under an Edge service, such
as is common for web-based email access.</t>
<t hangText="Transit: ">These are Mail Service
Providers (MSP) offering value-added
capabilities for Edge ADMDs, such as
aggregation and filtering.</t>
</list>
</t>
</list>
</t>
<figure anchor="ADMD"
title="ADministrative Management Domains (ADMD) Example">
<preamble>Note that Transit services are quite different
from packet-level transit operation. Whereas
end-to-end packet transfers usually go through
intermediate routers, email exchange across the open
Internet is often directly between the Edge ADMDs, at
the email level. </preamble>
<?rfc needLines="15" ?>
<artwork
name="ADministrative Management Domain (ADMD) Example"><![CDATA[
+-------+ +-------+ +-------+
| ADMD1 | | ADMD3 | | ADMD4 |
| ----- | | ----- | | ----- |
| | +---------------------->| | | |
| User | | |-Edge--+--->|-User |
| | | | +--->| | | |
| V | | | +-------+ +-------+
| Edge--+---+ |
| | | +---------+ |
+-------+ | | ADMD2 | |
| | ----- | |
| | | |
+--->|-Transit-+---+
| |
+---------+]]></artwork>
</figure>
<t>The distinction between Transit network and Edge network
transfer services is primarily significant because it
highlights the need for concern over interaction and
protection between independent administrations. The
interactions between functional components within an ADMD
are subject to the policies of that domain. </t>
<t>Common ADMD examples are: <list>
<t>
<list style="hanging">
<t hangText="Enterprise Service Providers: ">
Operators of an organization's internal data
and/or mail services.</t>
<t hangText="Internet Service Providers: ">
Operators of underlying data communication
services that, in turn, are used by one or
more Relays and Users. It is not necessarily
their job to perform email functions, but
they can, instead, provide an environment in
which those functions can be performed.</t>
<t hangText="Mail Service Providers: ">
Operators of email services, such as for
end-users, or mailing lists.</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="Conventions">
<!-- -->
<t>In this document, references to structured fields of a
message use a two-part dotted notation. The first part cites
the document that contains the specification for the field
and the second is the name of the field. Hence
<RFC2822.From> is the From field in an email
content header <xref target="RFC2822" /> and
<RFC2821.MailFrom> is the address in the SMTP
"Mail From" command. <xref target="RFC2821" />
</t>
<t> This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org. </t>
</section>
</section>
<section title="Goals">
<t>DKIM seeks to add authentication to the existing email transfer
infrastructure. This motivates functional goals about
authentication and operational goals about integration with the
existing email service.</t>
<section title="Functional">
<t>
<list style="hanging">
<t hangText="Use Domain-level granularity for assurance. ">
OpenPGP and S/MIME apply the end-to-end principle in
terms of individual originators and recipients,
notably using full email addresses. DKIM seeks
accountability at the more coarse grain of an
organization or, perhaps, a department. A deployed
construct that enables this granularity is the domain
name, to which the signing key record is bound.
Further DKIM signing and/or validating may be
implemented anywhere along the transit path, rather
than only in the end systems.</t>
<t hangText="Allow delegation of signing to independent parties. ">
Different parties have different roles in the
process of email exchange. Some of these parties are
easily visible to end users and others are primarily
visible to operators of the service. DKIM needs to
support signing by any of these different parties and
needs to permit them to sign with any domain name that
they deem appropriate. As an example an organization
that creates email content often delegates portions of
its processing or transmission to an outsourced group.
DKIM must support this mode of activity, in a manner
that is not visible to end users. </t>
<t hangText="Distinguish the core authentication mechanism from its derivative uses. ">
An authenticated identity may be subject to a
variety of processing policies, either ad hoc or
standardized. The only semantics inherent to a DKIM
signature is that the signer is asserting (some)
responsibility for the message. All other mechanisms
and meanings are independent of this core service. One
such mechanism might assert a relationship between the
signing identity and the author (<RFC2822.From>) domain
identity. Another might specify how to treat an unsigned
message with that <RFC2822.From> domain. </t>
<t hangText="Retain ability to have anonymous email. ">
The ability to send a message that does not identify
its author is considered to be a valuable quality of
the current email system that needs to be retained.
DKIM is compatible with this goal since it permits an
email system operator to be authenticated, rather than
the content author. Knowing that a mail definitely
came from example.com does not threaten the anonymity
of the user, if it is still possible to obtain
effectively anonymous accounts at example.com and
other mail providers. </t>
</list>
</t>
</section>
<section title="Operational">
<t>
<list style="hanging">
<t hangText="Make signature transparent to non-supporting recipients. ">
S/MIME and OpenPGP both modify the message body. Hence,
their presence is potentially visible to email
recipients and their user software must be able to
process the associated constructs. In order to
facilitate incremental adoption, DKIM is designed to
be transparent to recipients that do not support it.</t>
<t hangText="Treat verification failure the same as no signature unsigned. ">
OpenPGP and S/MIME were both designed for strong
cryptographic protection. This included treating
verification failure as message failure. As a sub-goal
to the requirement for transparency, a DKIM signature
verifier is to treat messages with signatures that
fail as if they were unsigned. Hence the message will
revert to normal handling, through the receiver's
existing filtering mechanisms.</t>
<t
hangText="Permit incremental adoption for incremental
benefit. "
> DKIM can immediately provide benefits between any
two organizations that exchange email and implement
DKIM. In the usual manner of "network effects", the
benefits of DKIM increase dramatically as its adoption
increases.</t>
<t>Although it is envisioned that this mechanism will
call upon independent services to aid in the
assessment of DKIM results, they are not essential in
order to obtain an initial benefit. For example DKIM
allows (possibly large) pair-wise sets of email
providers and spam filtering companies to distinguish
mail that is associated with a known organization,
from mail that might deceptively purport to have the
affiliation. This in turn allows the development of
'whitelist' schemes whereby authenticated mail from a
known source with good reputation is allowed to bypass
some spam filters. In effect the email receiver is
using their set of known relationships to generate
their own accreditation/reputation data. This works
particularly well for traffic between large sending
providers and large receiving providers. However it
also works well for any operator, public or private,
that has mail traffic dominated by exchanges among a
stable set of organizations. </t>
<t hangText="Minimize the amount of required
infrastructure. ">
A new service, or an enhancement to an existing
service, requires adoption by some number of systems,
before it can be useful. The greater the number of
required adopters, the higher the adoption barrier.
This becomes particularly serious when adoption is
required by intermediary -- that is, infrastructure --
service providers. In order to allow early adopters to
gain early benefit, DKIM seeks to make no changes to
the core Internet Mail service and, instead, to allow
a useful benefit for any signer/verifier pair of
participants exchanging mail. </t>
<t>Similarly, DKIM's reliance on the Domain Name Service
greatly reduces the amount of new administrative
infrastructure that must be deployed over the open
Internet.</t>
<t hangText="Permit wide range of deployment choices. ">
It should be possible to implement DKIM at a variety
of places within an organization's email service. This
permits the organization to choose how much or how
little they want DKIM to be part of their service,
rather than part of a more localized operation. </t>
</list>
</t>
</section>
</section>
<section title="Function">
<t>DKIM has a very constrained set of capabilities, primarily
targeting email while it is in transit, from an originator to a
set of recipients. It creates the ability to associate
verifiable information with a message, especially a responsible
identity. When a message is not signed, DKIM permits the
identity of the sender to be used for obtaining information
about their signing practices. </t>
<section title="The Basic Signing Service">
<t>With the DKIM signature mechanism, a signer associates a
domain name with an address, performs digital signing on the
message, and records signature information in a DKIM header
field. A verifier obtains the domain name from the DKIM
header field, queries for a public key associated with the
name, and verifies the signature.</t>
<t>DKIM permits any domain name to be use for signing, and
supports extensible choices for various algorithms. As is
typical for Internet standards, there is a core set of
algorithms required to be supported by all implementations.
This ensures an initial ability to interoperate.</t>
<t>DKIM permits restricting the use of a signature key to
particular types of services, such as only for email. This
is helpful when delegating signing authority, such as to a
particular department or to a third-party outsourcing
service.</t>
<t>With DKIM the signer MUST explicitly list the headers that
are signed. By choosing the minimal set of headers needed
the signature is likely to be considerably more robust
against the handling vagaries of intermediary MTAs.</t>
</section>
<section title="Characteristics of a DKIM signature">
<!-- -->
<t>A DKIM signature covers the message body and selected header
fields. The signer computes a hash of the selected header
fields and another hash of the body. The signer then uses a
private key to cryptographically encode this information,
along with other signing parameters. Signature information
is placed into a new <xref target="RFC2822" /> header field
of the message. </t>
</section>
<section title="The Selector construct">
<!-- -->
<t>A signature is associated with a domain name, as specified
in the "d=" DKIM parameter. That domain name is the complete
identity used for making assessments about the signer.
However this name is not sufficient for making a query to
obtain the key needed to verify the signature. </t>
<t>A single domain can use multiple signing keys and/or
multiple signers. To support this, DKIM identifies a
particular signature as a combination of the domain name and
an added field, called the "selector". Both of these are
coded into the DKIM-Signature header field. </t>
<t> It must be stressed that the selector is not part of the
domain name that is used for making assessments. Rather, the
selector is strictly reserved for use in administering keys
that are associated with the domain name. If the selector
becomes part of a name assessment mechanism, then there is
no remaining mechanism for making a transition from an old,
or compromised, key to a new one. </t>
<t>Signers do have the need for supporting multiple assessments
about their organization, such as to distinguish one type of
message from another, or one portion of the organization
from another. To permit assessments that are
independent, an organization should use different
sub-domains in the "d=" parameter, such as
"transaction.example.com" versus "newsletter.example.com",
or productA.example.com versus productB.example.com.</t>
</section>
<section title="Verification">
<!-- -->
<t>After a message has been signed, any agent in the message
transit path can choose to verify the signature, to
determine that the signing identity took responsibility for
the message. Message recipients can verify the signature by
querying the signer's domain directly to retrieve the
appropriate public key, and thereby confirm that the message
was attested to by a party in possession of the private key
for the signing domain. Typically, verification will be done
by an agent in the ADMD of the message recipient. </t>
</section>
</section>
<section title="Service Architecture">
<!-- 6 -->
<figure anchor="DKIMSvc" title="DKIM Service Architecture">
<preamble>The DKIM service is divided into components that can
be performed using different, external services, such as for
key retrieval. However the basic DKIM signing specification
defines an initial set of these services, in order to ensure
a basic level of interoperability.</preamble>
<?rfc needLines="43" ?>
<artwork name="DKIM Service Architecture"><![CDATA[
|
|- RFC2822 Message
V
+------------------------------+
| ORIGINATING OR RELAYING ADMD |
| |
+..>| Sign Message |
. +--------------+---------------+
. |
.private |
+---+---+ | +-----------+
| Key | | | Sender |
| Store | [Internet] | Practices |
+---+---+ | +-----+-----+
.public | .
. V .
. +------------------------------+ .
. | RELAYING OR DELIVERING ADMD | .
. | | .
. | Message Signed? | .
. +-------+----------------+-----+ .
. |yes |no .
. V V .
. +-----------+ +-----------+ .
+.....>| Verify | +..>| Check |<..+
| Signature | | | Practices |
+---+-----+-+ | +---+-------+
| | | |
| +---+ |
|pass fail |
V |
+--------+ |
+.......>| Assess | |
. | Signer | |
. +---+----+ |
. assessment| |
. +------+ +------+
. | |
+-+----------+ V V
| Reputation | +-----------+
+-----+------+ | Message |
| Filtering |
| Engine |
+-----------+]]>></artwork>
</figure>
<t>As shown in the Figure, basic message processing is divided
between signing the message, verifying the signature or
determining whether a signature was required, and then making
further decisions based upon the results. Signing may be
performed by a component of the ADMD that creates the message,
and/or within any ADMD, along the relay path. The signer uses
the appropriate private key.</t>
<t>Verification may be performed by any functional component along
the relay and delivery path. Verifiers retrieve the public key
based upon the parameters stored in the message. The figure
shows the verified identity as being used to assess an
associated reputation, but it could be applied for other tasks,
such as management tracking of mail. </t>
<t>Note that a failed signature causes the message to be treated
in the same manner as one that is unsigned. Unsigned messages
prompt a query for any published "sender practices"
information, as an aid in determining whether the sender
information has been used without authorization.</t>
<t> For signature verification and for the assessment of unsigned
messages, the results of these processes are treated as
additional input to the receiver's filtering engine. The engine
determines message disposition, such as whether to deliver
it.</t>
</section>
</section>
<section title="Deployment and Operation of DKIM Base">
<section title="Development">
<!-- 7 - Dave -->
<section title="Coding Criteria for Cryptographic Applications">
<t>Correct implementation of a cryptographic algorithm is a
necessary but not a sufficient condition for the coding of
cryptographic applications. Coding of cryptographic
libraries requires close attention to security
considerations that are unique to cryptographic
applications.</t>
<t>In addition to the usual security coding considerations,
such as avoiding buffer or integer overflow and underflow,
implementers should pay close attention to management of
cryptographic private keys and session keys, ensuring that
these are correctly initialized and disposed of.</t>
<t>Operating system mechanisms that permit the confidentiality
of private keys to be protected against other processes
SHOULD be used when available. In particular, great care
MUST be taken when releasing memory pages to the operating
system to ensure that private key information is not
disclosed to other processes.</t>
<t>On multiple processor and dual core architectures, certain
implementations of public key algorithms such as RSA may be
vulnerable to a timing analysis attack.</t>
<t>Support for cryptographic hardware providing key management
capabilities is strongly encouraged. In addition to offering
performance benefits, many cryptographic hardware devices
provide robust and verifiable management of private keys.</t>
<t>Fortunately appropriately designed and coded cryptographic
libraries are available for most operating system platforms
under license terms compatible with commercial, open source
and free software license terms. Use of standard
cryptographic libraries is strongly encouraged. These have
been extensively tested, reduce development time and support
a wide range of cryptographic hardware.</t>
</section>
<section title="Signer">
<!-- - Dave -->
<t>Signer implementations SHOULD provide a convenient means of
generating DNS key records corresponding to the signer
configuration. Support for automatic insertion of key
records into the DNS is also highly desirable. If supported
however, such mechanism(s) MUST be properly authenticated.</t>
<t>A means of verifying that the signer configuration is
compatible with the signature policy is also highly
desirable.</t>
<t>Disclosure of a private signature key component to a third
party allows that third party to impersonate the sender.
The protection of private signature key data is therefore a
critical concern. Signers SHOULD support use of
cryptographic hardware providing key management features. </t>
<t>The import and export of private keys, and the ability to
generate a Certificate Signing Request (CSR) for certificate
registration are highly desirable.</t>
</section>
</section>
<section title="Email Infrastructure Agents">
<!-- - Dave -->
<t>It is expected that the most common venue for a DKIM
implementation will be within the infrastructure of an
organization's email service, such as a department or a
boundary MTA.<list>
<t>
<list style="hanging">
<t hangText="Outbound: "> An MSA or Outbound MTA
should allow for the automatic verification of the MTA
configuration such that the MTA can generate an
operator alert if it determines that it is (1) an
edge MTA, and (2) configured to send email messages
that do not comply with the published DKIM sending
policy.</t>
<t>An outbound MTA should be aware that users may
employ MUAs that add their own signatures and be
prepared to take steps necessary to ensure that the
message sent is in compliance with the advertised
email sending policy.</t>
<t hangText="Inbound: "> An inbound MTA or an MDA
that does not support DKIM should avoid modifying
messages in ways that prevent verification by other
MTAs, or MUAs to which the message may be
forwarded.</t>
<t>An inbound MTA or an MDA may incorporate an indication
of the verification
results into the message, such as using an
Authentication-Results header. <xref
target="I-D.kucherawy-sender-auth-header" /></t>
<t hangText="Intermediaries: "> An email intermediary
is both an inbound and outbound MTA. Each of the
requirements outlined in the sections relating to
MTAs apply. If the intermediary modifies a message
in a way that breaks the signature, the
intermediary <list style="symbols">
<t> SHOULD deploy abuse filtering measures on
the inbound mail, and </t>
<t> MAY remove all signatures that will be
broken</t>
</list></t>
<t>In addition the intermediary MAY: <list style="symbols">
<t>Verify the message signature prior to modification.</t>
<t>Incorporate an indication of the verification
results into the message, such as using an
Authentication-Results header. <xref
target="I-D.kucherawy-sender-auth-header" /></t>
<t>Sign the modified message including the
verification results (e.g., the
Authentication-Results header).</t>
</list>
</t>
</list>
</t>
</list></t>
</section>
<section title="Filtering">
<!-- - Dave -->
<t>Developers of filtering schemes designed to accept DKIM
authentication results as input should be aware that their
implementations will be subject to counter-attack by email
abusers. The efficacy of a filtering scheme cannot therefore be
determined by reference to static test vectors alone;
resistance to counter attack must also be considered.</t>
<t>Naive learning algorithms that only consider the presence or
absence of a verified DKIM signature, without considering
more information about the message,
are vulnerable to an
attack in which a spammer or other malefactor signs all their
mail, thus creating a large negative value for presence of a
DKIM signature in the hope of discouraging widespread use.</t>
<t>If heuristic algorithms are employed, they should be trained on
feature sets that sufficiently reveal the internal structure of
the DKIM responses. In particular the algorithm should consider
the domains purporting to claim responsibility for the
signature, rather than the existence of a signature or not.</t>
<t>Unless a scheme can correlate the DKIM signature with
accreditation or reputation data, the presence of a DKIM
signature SHOULD be ignored.</t>
</section>
<section title="DNS Server">
<!-- - Dave -->
<t> At a minimum, a DNS server that handles queries for DKIM key
records must allow the server administrators to add free-form TXT
records. It would, of course, be better for provide them with a
structured form, to support the DKIM-specific fields.</t>
</section>
<section title="Deployment">
<!-- 8 - Tony -->
<t>This section describes the basic steps for introducing DKIM
into an organization's email service operation. The
considerations are divided between the generating DKIM
signatures (Signing) and the processing of messages that
contain a DKIM signature (Verifying).</t>
<section title="Key Management">
<t>
<list style="hanging">
<t hangText="Selectors"> Selectors are assigned according
to the administrative needs of the signing domain,
such as for rolling over to a new key or for
delegating of the right to authenticate a portion of
the namespace to a trusted third party. <list>
<t>
<list style="hanging">
<t hangText="Examples include: ">
jun2005.eng._domainkey.example.com </t>
<t>widget.promotion._domainkey.example.com</t>
</list>
<list style="hanging">
<t hangText="NOTE: ">It is intended that
assessments of DKIM identities be based on
the domain name, and not include the
selector. This permits the selector to be
used only for key administration, rather
than having an effect on reputation
assessment.</t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Signing">
<!-- - Tony -->
<t>Creating messages that have DKIM signatures requires
a modification to only two portions of the email service:
<list style="symbols">
<t>Addition of relevant DNS information.</t>
<t>Addition of the signature by a trusted module within
the organization's email handling service.</t>
</list>
</t>
<t>The signing module uses the appropriate private key to
create a signature. The means by which the signing module
obtains the private key is not specified by DKIM. Given that DKIM
is intended for use during email transit, rather than for
long-term storage, it is expected that keys will be changed
regularly. Clearly this means that key information should
not be hard-coded into software. </t>
<section title="DNS Records">
<!-- - Tony -->
<t>A receiver attempting to verify a DKIM signature must
obtain the public key that is associated with the
signature for that message. The DKIM-Signature header in
the message will specify the basic domain name doing the
signing and the selector to be used for the specific
public key. Hence, the relevant
<selector>._domainkey.<domain-name>
DNS record needs to contain a DKIM-related resource
record (RR) that provides the public key information. </t>
<t>The administrator of the zone containing the relevant
domain name adds this information. Initial DKIM DNS
information is contained within TXT RRs. DNS
administrative software varies considerably in its
abilities to add new types of DNS records. </t>
</section>
<section title="Signing Module">
<!-- - Tony -->
<t>The module doing signing can be placed anywhere within an
organization's trusted Administrative Management Domain
(ADMD); common choices are expected to be
department-level posting and delivering agents, as well
as boundary MTAs to the open Internet. (Note that it is
entirely acceptable for MUAs to perform signing and
verification.) Hence the choice among the modules depends
upon software development and administrative overhead
tradeoffs. One perspective that helps resolve this choice
is the difference between the flexibility of use by
systems at (or close to) the MUA, versus the centralized
control that is more easily obtained by implementing the
mechanism "deeper" into the organization's email
infrastructure, such as at its boundary MTA.</t>
</section>
<section title="Signing Policies and Practices">
<!-- - Tony -->
<t>Every organization (ADMD) will have its own policies and
practices for deciding when to sign messages and with
what domain name and key (selector). Examples include
signing all mail, signing mail from particular email
addresses, or signing mail from particular sub-domains.
Given this variability, and the likelihood that signing
practices will change over time, it will be useful to
have these decisions represented in some sort of
configuration information, rather than being more deeply
coded into the signing software.</t>
</section>
</section>
<section title="Verifying">
<section title="Verifier">
<!-- - Dave -->
<t>Verifiers SHOULD treat the result of the verification
step as an input to the message evaluation process rather
than as providing a final decision. The knowledge that a
message is authentically sent by a domain does not say
much about the legitimacy of the message, unless the
characteristics of the domain claiming responsibility are
known.</t>
<t>In particular, verifiers SHOULD NOT automatically assume
that an email message that does not contain a signature,
or that contains a signature that does not verify, is
forged. Verifiers should treat a signature that fails to
verify the same as if no signature were present.</t>
</section>
<t>Verification is performed within an ADMD that wishes to make
assessments based upon the DKIM signature's domain name. Any
component within the ADMD that handles messages, whether in
transit or being delivered, can do the verifying and
subsequent assessments. Verification and assessment might
occur within the same software mechanism, such as a Boundary
MTA, or an MDA. Or they may be separated, such as having
verification performed by the Boundary MTA and assessment
performed by the MDA.</t>
<t>As with the signing process, choice of service venues for
verification and assessment -- such as filtering or
presentation to the recipient user -- depend on trade-offs
for flexibility, control, and operational ease. An added
concern is that the linkage between verification and
assessment entails essential trust: the assessment module
MUST have a strong basis for believing that the verification
information is correct.</t>
<section title="DNS Client">
<!-- - Tony -->
<t>The primary means of publishing DKIM key information,
initially, is initially through DNS TXT records. Some DNS
client software might have problems obtaining these
records; as DNS client software improves this will not be
a concern.</t>
</section>
<section title="Boundary Enforcement">
<!-- - Tony -->
<t>In order for an assessment module to trust the
information it receives about verification (e.g.,
Authentication-Results headers), it MUST eliminate
verification information originating from outside the
ADMD in which the assessment mechanism operates. As a
matter of friendly practice, it is equally important to
make sure that verification information generated within
the ADMD not escape outside of it.</t>
<t>In most environments, the easiest way to enforce this is
to place modules in the receiving and sending Boundary
MTA(s) that strip any existing verification
information.</t>
</section>
</section>
<section title="Mail User Agent">
<!-- - Tony -->
<t>DKIM is designed to support deployment and use in email
components other than an MUA. However an MUA MAY also
implement DKIM features directly.<list>
<t>
<list style="hanging">
<t hangText="Outbound: "> If an MUA is configured
to send email directly, rather than relayed
through an outbound MSA, the MUA SHOULD be
considered as if it were an outbound MTA for the
purposes of DKIM. An MUA MAY support signing
even if mail is to be relayed through an
outbound MSA. In this case the signature applied
by the MUA may be in addition to any MSA
signature.</t>
<t hangText="Inbound: "> An MUA MAY rely on a
report of a DKIM signature verification that
took place at some point in the inbound MTA path
(e.g., an Authentication-Results header), or an
MUA MAY perform DKIM signature verification
directly. A verifying MUA SHOULD allow for the
case where mail is modified in the inbound MTA
path.</t>
</list>
</t>
</list></t>
</section>
<section title="Transition strategy">
<!-- - Tony -->
<t> Deployment of a new signature algorithm without a 'flag
day' requires a transition strategy such that signers and
verifiers can phase in support for the new algorithm
independently, and (if necessary) phase out support for the
old algorithm independently. </t>
<t>[Note: this section assumes that a security policy mechanism
exists. It is subject to change.] </t>
<t> DKIM achieves these requirements through two features:
First a signed message may contain multiple signatures
created by the same signer. Secondly the security policy
layer allows the signing algorithms in use to be advertised,
thus preventing a downgrade attack. </t>
<section title="Signer transition strategy">
<!-- - Tony -->
<t> Let the old signing algorithm be A, the new signing
algorithm be B. The sequence of events by which a Signer
may introduce the new signing algorithm B, without
disruption of service to legacy verifiers, is as follows:
<list style="numbers">
<t>Signer signs with algorithm A <list style="letters">
<t>Signer advertises that it signs with
algorithm A</t>
</list>
</t>
<t>Signer signs messages twice, with both algorithm A
and algorithm B <list style="letters">
<t>The signer tests new signing configuration</t>
<t>Signer advertises that it signs with
algorithm A and algorithm B</t>
</list>
</t>
<t>Signer determines that support for Algorithm A is
no longer necessary</t>
<t>Signer determines that support for algorithm A is
to be withdrawn <list style="letters">
<t>Signer removes advertisement for Algorithm A</t>
<t>Signer waits for cached copies of earlier
signature policy to expire</t>
<t>Signer stops signing with Algorithm A</t>
</list>
</t>
</list></t>
</section>
<section title="Verifier transition strategy">
<!-- - Tony -->
<t> The actions of the verifier are independent of the
signer's actions and do not need to be performed in a
particular sequence. The verifier may make a decision to
cease accepting algorithm A without first deploying
support for algorithm B. Similarly a verifier may be
upgraded to support algorithm B without requiring
algorithm A to be withdrawn. The decisions of the
verifier must make are therefore: <list style="symbols">
<t>The verifier MAY change the degree of confidence
associated with any signature at any time,
including determining that a given signature
algorithm provides a limited assurance of
authenticity at a given key strength. <list>
<t>A verifier MAY evaluate signature records in
any order it chooses, including using the
signature algorithm to choose the order.</t>
</list>
</t>
<t>The verifier MAY make a determination that
Algorithm A does not offer a useful level of
security, or that the cost of verifying the
signature is less than the value of doing so. <list>
<t>In this case the verifier would ignore
signatures created using algorithm A and
references to algorithm A in policy records
would be treated as if the algorithm were not
implemented.</t>
</list>
</t>
<t>The verifier MAY decide to add support for
additional signature algorithms at any time. <list>
<t>The verifier MAY add support for algorithm B
at any time.</t>
</list>
</t>
</list>
</t>
</section>
</section>
<section title="Migrating from DomainKeys">
<section title="Signing">
<t>
<list>
<t>
<list style="hanging">
<t hangText="DNS Records: "> DKIM is upwardly
compatible with existing DomainKeys (DK)
<xref target="RFC4870" />
DNS records, so that a DKIM module does
not automatically require additional DNS
administration! However DKIM has enhanced the
DomainKeys DNS key record format by adding
several additional optional parameters. </t>
<t hangText="Boundary MTA: "> The principle use
of DomainKeys is at Boundary MTAs. Because no
operational transition is ever instantaneous,
it is not adviseable for existing DomainKeys
signers to switch to DKIM without continuing
to perform DomainKeys signing. A signer
should add a DKIM signature to a message that
also has a DomainKeys signature, until such
time as DomainKeys receive-side support is
sufficiently reduced. With respect to signing
policies, a reasonable, initial approach is
to use DKIM signatures in the same way as
DomainKeys signatures are already being used.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Verifying">
<!-- - Phil -->
<t>
<list>
<t>
<list style="hanging">
<t hangText="DNS Client: ">DNS queries for the
DKIM key record, use the same Domain Name
naming conventions as were used for DomainKeys, and the
same basic record format. No changes to the
DNS client should be required. </t>
<t hangText="Verifying module: "> See the section on Signing
above.</t>
</list>
</t>
</list>
</t>
</section>
</section>
</section>
<section title="On-going Operations">
<!-- 9 - Phil -->
<t>This section describes the basic steps for operation of email
systems that use DKIM, after the capability has initially been
deployed. The primary considerations are: <list style="symbols">
<t> the upkeep of the selector files, and </t>
<t>the security of the private keys. </t>
</list></t>
<section title="DNS Signature Record Installation Considerations">
<t> Even with use of the DNS, one challenge is that DNS record management is
usually operated by an administrative staff that is different from
those who operate an organization's email service. In order
to ensure that DKIM DNS records are accurate, this imposes a
requirement for careful coordination between the two
operations groups. </t>
<!-- - Phil -->
<t> The key point to remember is that the DNS DKIM selectors
WILL and SHOULD be changed over time. Some reasons for
changing DKIM selectors are well understood, while others are
still theoretical. There are several schemes that may be
used to determine the policies for changing DKIM selectors:
<list style="symbols">
<t>time based</t>
<t>associations with clusters of servers</t>
<t>the use of third party signers</t>
<t>security considerations</t>
</list>
</t>
<section title="Time Basis and Security Considerations">
<!-- - Phil -->
<t> The reason for changing the selector periodically is
usually related to the security exposure of a system.
When the potential exposure of the private keys
associated with the DKIM selector have reached sufficient
levels, the selector should be changed. (It is unclear
currently what kinds of metrics can be used to aid in
deciding when the exposure has reached sufficient levels
to warrant changing the selector.) </t>
<t> For example, <list style="symbols">
<t> Selectors should be changed more frequently on
systems that are widely exposed, than on systems
that are less widely exposed. For example, a
gateway system that has numerous
externally-accessible services running on it, is
more widely exposed than one that ONLY runs a mail
server. </t>
<t> Selectors should be changed more frequently on
operating systems that are under wide attack. </t>
<t> While the use of DKIM information is transient,
keys with sufficient exposure do become stale and
should be changed. </t>
<t>Whenever you make a substantial system change, such
as bringing up a new server, or making a major
operating system change, you should consider
changing the selector. </t>
<t> Whenever there is either suspicion or evidence of
the compromise of the system or the private keys,
you should change the selector. </t>
</list>
</t>
</section>
<section title="Deploying New Selectors">
<!-- - Phil -->
<t> A primary consideration in changing the selector is
remembering to change it. It needs to be a standard part
of the operational staff Methods and Procedures for your
systems. If they are separate, both the mail team and the
DNS team will be involved in deploying new selectors. </t>
<t> When deploying a new selector, it needs to be phased in:
<list style="numbers">
<t>Generate the new public / private key pair and
create a new selector record with the public key in it.</t>
<t>Add the new selector record to your DNS.</t>
<t>Verify that the new selector record can be used to
verify signatures.</t>
<t>Turn on signing with the new private key.</t>
<t>Remove the old private key from your servers.</t>
<t>After a period of time, remove the old selector
from your DNS.</t>
</list> The time an unused selector should be kept in the
DNS system is dependent on the reason it's being changed.
If the private key has definitely been exposed, the
corresponding selector should be removed immediately.
Otherwise, longer periods are allowable. </t>
</section>
<section title="Subdomain Considerations">
<!-- - Phil -->
<t> A Domain Name is the basis for making differential
quality assessments about a DKIM-signed message. It is
reasonable for a single organization to have a variety of
very different activities, which warrant a variety of
very different assessments. A convenient way to
distinguish among such activities is to sign with
different domain names. That is, the organization should
sign with sub-domain names that are used for different
organizational activities. </t>
</section>
<section title="Third party Signature Delegations">
<!-- - Phil -->
<t>Allowing third parties to sign email from your domain
opens your system security to include the security of the
third party's systems. At a minimum, you should not allow
the third parties to use the same selector and private
key as your main mail system. It is recommended that each
third party be given their own private key and selector.
This limits the exposure for any given private key, and
minimizes the impact if any given private key were
exposed. </t>
</section>
</section>
<section title="Private Key Management">
<!-- - Phil -->
<t> The permissions of private key files must be carefully
managed. If key management hardware support is available, it
should be used. Auditing software should be used to
periodically verify that the permissions on the private key
files remain secure. </t>
</section>
<section title="Mailing list manager developers">
<!-- - Phil -->
<t> A mailing list often provides facilities to its
administrator to manipulate parts of the mail messages that
flow through the list. The desired goal is that messages
flowing through the mailing list will be verifiable by the
recipient as being from the list, or failing that, as being
from the individual list members. </t>
<t> In most cases, the list and/or its mail host SHOULD add its
own DKIM signature to list mail. This could be done in the
list management software, in an outgoing MSA or MTA, or
both. List management software often makes modifications to
messages that will break incoming signatures, such as adding
subject tags, adding message headers or footers, and adding,
deleting, or reordering MIME parts. By adding its own
signature after these modifications, the list provides a
verifiable, recognizable signature for list recipients. </t>
<t> In some cases, the modifications made by the mailing list
software are simple enough that
signatures on incoming messages will still be verifiable
after being remailed by the list. It is still preferable
that the list sign its mail so that recipients can
distinguish between mail sent through the list and mail sent
directly to a list member. In the absence of a list
signature, a recipient may still be able to recognize and use the
original signatures of the list members. </t>
<!--
<t>
A mailing list often manipulates header fields or content of
the messages it redistributes. The desired goal is that
messages flowing through the mailing list will be verifiable by
the recipient, which means that either the mailing list (or its
MSA) must sign the message, or the mailing list must not
perform actions on the messages that will break existing DKIM
signatures. To support DKIM verification, a mailing list has
these choices: <list style="symbols">
<t>A mailing list MAY add its own DKIM signature. If it does
this, it must make sure that it adds its signature after
it performs any content transformations to the message,
such as adding a footer to the body, adding a prefix to
the body, modifying the subject header, etc. </t>
<t> If a mailing list does not add its own DKIM signature,
it MUST at least avoid modifying any existing headers
that are listed in an h= parameter of any existing
DKIM-Signature headers, nor may it add any footer content
to the body if there is no l= in any existing
DKIM-Signature headers. </t>
<t>If a mailing list cannot add its own DKIM signature, and
must modify the headers or body in a way that will break
verification of existing DKIM-Signature headers, it
SHOULD remove any existing DKIM-Signature headers. </t>
</list>
</t>
-->
</section>
</section>
<section title="Example Uses">
<!-- 10 - Dave -->
<t> A DKIM signature tells the signature verifier that the owner
of a particular domain name accepts responsibility for the
message. Combining this information with information that
allows the history of the domain name owner to be assessed may
allow processing the message, based on the probability that the
message is likely to be trustworthy, or not, without the need
for heuristic content analysis. </t>
<section title="Protection of Internal Mail">
<!-- - Dave -->
<t>One identity is particularly amenable to easy and accurate
assessment: The organization's own identity. Members of an
organization tend to trust messages that purport to be from
within that organization. However Internet Mail does not
provide a straightforward means of determining whether such
mail is, in fact, from within the organization. DKIM can be
used to remedy this exposure. If the organization signs all
of its mail, then its boundary MTAs can look for mail
purporting to be from the organization but does not
contain a verifiable signature. Such mail can be presumed to
be spurious.</t>
</section>
<section title="Recipient-based Assessments">
<!-- - Dave -->
<t> Recipients of large volumes of email can internally generate
reputation data for email senders. Recipients of
smaller volumes of messages are likely to need to acquire
reputation data from a third party. In either case the use
of reputation data is intrinsically limited to email senders
that have established a prior history of sending messages. </t>
<t> In fact, an email receiving service may be in a position to
establish bilateral agreements with particular senders, such
as business partners or trusted bulk sending services.
Although it is not practical for each recipient to accredit
every sender, the definition of core networks of explicit trust
can be quite useful. </t>
<section title="Third-party Assessments">
<!-- - Dave -->
<t>For scaling efficiency, it is appealing to have Trusted
Third Party assessment services, to allow an email sender
to obtain a single assessment that is then recognized by
every email recipient that recognizes the Trusted Third
Party.</t>
</section>
</section>
<section title="DKIM Support in the Client">
<!-- - Dave -->
<t> The DKIM specification is expected to be used primarily
between Boundary MTAs, or other infrastructure components of
the originating and receiving ADMDs. However there is
nothing in DKIM that is specific to those venues. In
particular, it should be possible to support signing and
verifying in MUAs.</t>
<t> However, it is common for components of an ADMD's email
infrastructure to do violence to a message, such as to render a
DKIM signature invalid. Hence, users of MUAs that support
DKIM signing and/or verifying need a basis for knowing that
their associated email infrastructure will not break a
signature. </t>
<t> DKIM requires that all verifiers treat messages with
signatures that do not verify as if they are unsigned. If
verification in the client is to be acceptable to users, it
is also essential that successful verification of a
signature not result in a less than satisfactory user
experience compared to leaving the message unsigned. </t>
</section>
<section title="Per user signatures">
<!-- - Dave -->
<t> Although DKIM's use of domain names is optimized for a
scope of organization-level signing, it is possible to administer
sub-domains and/or selectors in a way that
supports per-user signing. <list style="hanging">
<t hangText="NOTE: ">As stated earlier, it is important
to distinguish between the use of selectors for
differential administration of keys, versus the use of
sub-domains for differential reputations.</t>
</list> As a constraint on an authorized DKIM signing agent,
their associated key record can specify restrictions on the
email addresses permitted to be signed with that domain and
key. A typical intent of this feature is to allow a company
to delegate the signing authority for bulk marketing
communications without the risk of effectively delegating
the authority to sign messages purporting to come from the
domain-owning organization's CEO. </t>
<t>
<list style="hanging">
<t hangText="NOTE: "> Any scheme that involves
maintenance of a significant number of public keys is
likely to require infrastructure enhancements, to
support that management. For example, a system in
which the end user is required to generate a public
key pair and transmit it to the DNS administrator out
of band is not likely to meet acceptance criteria for
either usability or security. </t>
</list>
</t>
</section>
</section>
</section>
<section title="Acknowledgements">
<t> TBD </t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<!-- references title="Normative References"> </references -->
<references title="Informative References">&dkimbase; &dkimta;
&rfc2822; &dk; &pem; &moss; &pgp1; &rfc2821; &rfc2440;
&rfc3156; &rfc2440bis; &syslog; &rfc3851; &ar;
<reference
anchor="RFC1034">
<front>
<title abbrev="Domain Concepts and Facilities">Domain names -
concepts and facilities</title>
<author fullname="P. Mockapetris" initials="P."
surname="Mockapetris">
<organization>Information Sciences Institute
(ISI)</organization>
</author>
<date day="1" month="November" year="1987" />
</front>
<seriesInfo name="STD" value="13" />
<seriesInfo name="RFC" value="1034" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 03:34:54 |