One document matched: draft-ietf-dkim-overview-09.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
Scanned Overview:
JD Falk
Murray
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY ar PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.kucherawy-sender-auth-header.xml'>
<!ENTITY rfc1034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.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 rfc4406 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4406.xml'>
<!ENTITY rfc4407 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4407.xml'>
<!ENTITY rfc4408 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4408.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'>
<!ENTITY openpgp PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4880.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)
Service 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 month="February" year="2008" />
<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> This document provides an overview of the DomainKeys Identified
Mail (DKIM) service and describes how it can fit into a messaging
service. It also describes how DKIM relates to other IETF message
signature technologies. It is intended for those who are adopting,
developing, or deploying DKIM.
DKIM allows an organization
to take responsibility for transmitting a message, in a way that can be
validated by a recipient.
The organization can be the author's, the
originating sending site, an intermediary, or one of their agents.
An organization may use one or more domain names to accomplish this.
DKIM defines a domain-level digital signature authentication
framework for email, using public-key cryptography and key server
technology <xref target="RFC4871" />. This permits verification of a
message source, an intermediary, or one of their agents, as well as
the integrity of its contents. 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 about messages. Such protection of
email identity can assist in the global control of "spam" and
"phishing". </t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t> This document provides a description of the architecture and
functionality for DomainKeys Identified Mail (DKIM). It is intended
for those who are adopting, developing, or deploying DKIM. It will also
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="RFC4686" /> and <xref target="RFC4871" />, respectively.
The document assumes a background in basic email and network
security technology and services. </t>
<t>DKIM allows an organization to take responsibility for a message, in
a way that can be validated by a recipient. The organization can be
the author's, the originating sending site, an intermediary, or one
of their agents. DKIM defines a domain-level digital signature
authentication framework for email through the use of public-key cryptography
and key server technology. <xref target="RFC4871" /> It permits
verification of the signer of a message, as well as the integrity of its
contents. 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. Such protection of email identity
can assist in the global control of "spam" and "phishing". </t>
<t> Neither this document nor DKIM attempts to provide solutions to the
world's problems with spam, phishing, virii, worms, joe jobs, etc.
DKIM provides one basic tool, in what needs to be a large arsenal,
for improving basic trust in the Internet mail service. 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,
beyond a simple reference within a system diagram. Rather, it is a
basic introduction to the technology and its use. </t>
<section title="DKIM's Scope">
<t>DKIM signatures can be created by a direct handler of a message,
either as its author or as an intermediary. It can also be
created by an independent service that is 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,
the reputation associated with that domain name is an additional 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 accept responsibility for the message and may thus be held
accountable for it.</t>
<t>DKIM is intended as a value-added feature for email. Mail that is not signed
by DKIM is handled in the same way as it was before DKIM was
defined. The message will be evaluated by established analysis
and filtering techniques. (A signing policy may provide
additional information for that analysis and filtering.) Over
time, widespread DKIM adoption could permit more strict handling
of messages that are not signed. However early benefits do not
require this and probably do not warrant this. </t>
<t>DKIM's
capabilities have a narrow scope. It is an enabling technology, intended for use in
the larger context of determining message legitimacy. This larger
context is complex, so it is easy to assume that a component like
DKIM, which actually provides only a limited service, instead
satisfies the broader set of requirements.</t>
<t>By itself, 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 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
author. </t>
</list>
</t>
</section>
<section title="Prior Work">
<t>Historically, email delivery assessment decisions have been based
on an identity that used the IP Address of the system that
directly sent the message (that is, the previous email "hop"),
<xref target="RFC4408"/>
or on the message content (e.g.
<xref target="RFC4406"/> and <xref target="RFC4407"/>).
The IP 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
presents a number of functional and operational problems.
Consequently there is a widespread desire to use an identifier
that has better correspondence to organizational boundaries.
Domain names are viewed as often satisfying this need. </t>
<t> There have been four previous IETF efforts at standardizing an
Internet email signature scheme. Their goals have differed from
those of DKIM.
<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 (MOSS) 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="RFC4880" />
</t>
<t>RSA Security independently developed Secure MIME (S/MIME)
to transport a PKCS #7 data object. <xref target="RFC3851"
/>
</t>
</list>
Development of both S/MIME and OpenPGP has continued.
While each has achieved a significant user base,
neither one has achieved ubiquity in deployment or use. </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) <xref target="Kohnfelder" /> or
Zimmermann (web of trust).
<!-- ???????????????? citation for Zimmermann ???????????????? -->
For DKIM, the
owner of a domain name asserts the validity of a key, 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 provided by adding information records to
the existing Domain Name System (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 global
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.
<!--
????????????????
comment from Jim Fenton:
It might also be worth mentioning the revocation characteristics
of DNS, since it will be necessary for domains to revoke keys
from time to time.
[TLH] Let's skip this for now?
-->
</t>
</section>
<section title="Internet Mail Background">
<t> The basic Internet Email service has evolved extensively over
its several decades of continuous operation. Its modern
architecture comprises a number of specialized components. A
discussion about Mail User Agents (MUA), Mail Handling Services
(MHS), Mail Transfer Agents (MTA), Mail Submission Agents (MSA),
Mail Delivery Agents (MDA), Mail Service Providers (MSP),
Administrative Management Domains (ADMDs), and their
relationships can be found in <xref
target="appendixMailBackground" />. </t>
</section>
<section title="Discussion Venue">
<t>
<list style="hanging">
<t hangText="NOTE TO RFC EDITOR: ">This "Discussion Venue"
section is to be removed prior to publication. </t>
</list>
</t>
<t> This document is being discussed on the DKIM mailing list,
ietf-dkim@mipassoc.org. </t>
</section>
</section>
<section title="The DKIM Value Proposition">
<t>The nature and origins of a message are often falsely stated.
Such misrepresentations may (but not necessarily) be employed in
order to perpetrate abuse.
DKIM provides a foundation for distinguishing legitimate mail,
and thus a means of associating a verifiable identifier with a
message. Given the presence of that identifier, a receiver can
make decisions about further handling of the message, based upon
assessments of the identity that is associated with the
identifier. </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>Determine a verified identity, if possible.</t>
<t>Determine whether a known identity is trusted.</t>
</list> The role of DKIM is to perform the first of these; DKIM
is an enabler for the second. </t>
<section title="Identity Verification">
<t>Consider an attack made against an organization or against customers of
an organization. The name of the organization is linked to
particular Internet domain names (identifiers). One point of
leverage for attackers is either to use a legitimate domain name,
without authorization, or to use a "cousin" name that is similar
to one that is legitimate, but is not controlled by the target
organization. An assessment service that uses DKIM can
differentiate between domains used by known organizations and
domains used by others. As such, DKIM performs the positive step
of identifying messages associated with verifiable identities,
rather than the negative step of identifying messages with
problematic use of identities. Whether a verified identity
belongs to a Good Actor or a Bad Actor becomes a later step of
assessment. </t>
</section>
<section title="Enabling Trust Assessments">
<t>Email receiving services are faced with a basic decision: Should
they deliver a newly-arrived message to the indicated recipient?
That is, does the receiving service trust that the message is
sufficiently "safe" to be viewed? For the modern Internet, most
receiving services have an elaborate engine that formulates this
quality assessment. These engines take a variety of information
as input to the decision, such as from reputation lists and
accreditation services. As the engine processes information, it
raises or lowers its trust assessment for the message. </t>
<t>DKIM provides additional information to this process by declaring
a valid "responsible" identity about which the engine can make
quality assessments. By itself, a valid DKIM signature neither
lowers nor raises the level of trust associated with the message,
but it enables other mechanisms to be used for doing so. </t>
<t>An organization might build upon its use of DKIM by publishing
information about its Signing Practices (SP). This could permit
detecting some messages that purport to be associated with a
domain, but which are not. As such, an SP can cause the trust
assessment to be reduced, or leave it unchanged. </t>
</section>
</section>
<section title="DKIM Goals">
<t>DKIM adds an end-to-end authentication mechanism to the existing
email transfer infrastructure. This motivates functional goals about
the authentication itself and operational goals about its
integration with the rest of the Internet email service. </t>
<section title="Functional Goals">
<section title="Use Domain-level granularity for assurance">
<t>
DKIM seeks accountability at the coarse granularity of
an organization or, perhaps, a department.
An existing Internet service construct that
enables this granularity is the Domain Name <xref
target="RFC1034" />.
DKIM binds the signing key record to the Domain Name.
Further benefits of using domain names include
simplifying key management,
enabling signing by the infrastructure as opposed to the MUA,
and potential privacy issues.
</t>
<t>
Contrast this with OpenPGP and S/MIME, which provide
end-to-end validation in terms of
individual authors, notably using full email addresses.
</t>
</section>
<section title="Implementation Locality">
<t>
Any party, anywhere along the transit path can implement DKIM signing.
Its use is not confined to the end systems or only in a boundary MTA.
</t>
</section>
<section title="Allow delegation of signing to independent parties">
<t> Different parties have different roles in the process of
email exchange. Some are easily visible to end users and
others are primarily visible to operators of the service. DKIM
was designed to support signing by any of these different parties and
to permit them to sign with any domain name that they
deem appropriate (and for which they hold authorized signing keys.) As an
example an organization that creates email content often
delegates portions of its processing or transmission to an
outsourced group. DKIM supports this mode of activity, in a
manner that is not normally visible to end users. </t>
</section>
<section
title="Distinguish the core authentication mechanism from its derivative uses">
<t> An authenticated identity can 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 built on this core service.
One such mechanism might assert a relationship between the
signing identity and the author, as specified in the From:
header field's domain identity<xref target="RFC2822" />.
Another might specify how to treat an unsigned message with
that From: field domain. </t>
</section>
<section title="Retain ability to have anonymous email">
<t>The ability to send a message that does not identify its
author is considered to be a valuable quality of the current
email service that needs to be retained. DKIM is compatible
with this goal since it permits authentication of the email
system operator, rather than the content author. If it is
possible to obtain effectively anonymous accounts at
example.com, knowing that a message definitely came from
example.com does not threaten the anonymity of the user who
authored it. </t>
</section>
</section>
<section title="Operational Goals">
<section
title="Treat verification failure the same as no signature present">
<!--
????????????????
comment from Jim Fenton:
This isn't a goal, in the sense of something we designed DKIM to try
to do. It's a result of the threat model.
-->
<t>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. Thus, DKIM specifies that an
assessing site is not to take a message that has a broken
signature and treat it any differently than if the signature
weren't there.
</t>
<t>
Contrast this with
OpenPGP and S/MIME, which were designed for strong cryptographic
protection. This included treating verification failure as
message failure.
</t>
</section>
<section
title="Make signatures transparent to non-supporting recipients">
<t>
In
order to facilitate incremental adoption, DKIM is designed to
be transparent to recipients that do not support it. A DKIM
signature does not "get in the way" for such recipients.
</t>
<t>
Contrast this with
S/MIME and OpenPGP, which modify the message body. Hence, their
presence is potentially visible to email recipients, whose
user software needs to process the associated constructs.
</t>
</section>
<section title="Permit incremental adoption for incremental benefit">
<t>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 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 anti-abuse filters. </t>
<t>In effect the email receiver is using their set of known
relationships to generate their own 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>Management of email deliverability problems currently represents
a significant pain point for email administrators at every point
on the mail transit path. Administrators who have deployed DKIM
verification have an incentive to evangelize the use of DKIM
signatures to senders who may subsequently complain that their
email is not being delivered.
</t>
</section>
<section title="Minimize the amount of required infrastructure">
<t>A new service, or an enhancement to an existing service,
requires adoption in a critical mass of system components,
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 independent,
intermediary -- that is, infrastructure -- service providers.
In order to allow early adopters to gain early benefit, DKIM
makes no changes to the core Internet Mail service and,
instead, can provide a useful benefit for any individual pair
of signers and verifiers who are exchanging mail. Similarly,
DKIM's reliance on the Domain Name System greatly reduces the
amount of new administrative infrastructure that is needed
across the open Internet. </t>
</section>
<section title="Permit wide range of deployment choices">
<t>DKIM can be deployed 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>
</section>
</section>
</section>
<section title="DKIM Function">
<t>DKIM has a very constrained set of capabilities, primarily targeting
email while it is in transit from an author to a set of recipients.
It creates the ability to associate verifiable information with a
message, especially a responsible identity.
When a message does not have a valid signature associated with the
author, DKIM SP will permit the domain name of the author to be used
for obtaining information about their signing practices. </t>
<section anchor="basicsign" title="The Basic Signing Service">
<t>With the DKIM signature mechanism, a signer chooses a signing
identity based on their domain name, performs digital signing on
the message, and records signature information in a DKIM header
field. A verifier obtains the domain name and the
"selector" 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 used for signing, and supports
extensible choices for various algorithms. As is typical for
Internet standards, there is a core set of algorithms that all
implementations are required to support, in order to guarantee
basic interoperability.
</t>
<t>DKIM permits restricting the use of a signature key (by using s=)
to signing messages for particular types of services, such as only for
email.
This is intended to be helpful when delegating signing
authority, such as to a particular department or to a third-party
outsourcing service.
</t>
<t>With DKIM the signer explicitly lists the headers that are
signed, such as From:, Date: and Subject:. 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 the
DKIM-Signature header field, a new
<xref target="RFC2822" /> header field of the message. </t>
</section>
<section title="The Selector construct">
<!-- -->
<t>The key for a signature is associated with a domain name, as
specified in the d= parameter of the DKIM-Signature header.
That domain name, or the domain name or address in the i= parameter,
provide the complete identity used for making assessments about
the signer.
(The DKIM specification does not give any guidance on how
to do an assessment.)
However this name is not sufficient
for making a DNS query to obtain the key needed to verify the
signature. </t>
<t>A single domain can use multiple signing keys and/or multiple
potential signers. To support this, DKIM identifies a particular
signature as a combination of the domain name and an added field,
called the "selector", specified in separate DKIM-Signature header
field parameters. </t>
<t>
<list style="hanging">
<t hangText="NOTE: ">The semantics of the selector (if any) are strictly
reserved to the signer and should be treated as an opaque string
by all other parties.
If verifiers were to employ the selector as part of a name assessment
mechanism, then there would be no remaining mechanism for making
a transition from an old, or compromised, key to a new one.
</t>
</list>
</t>
<t>Signers often need to support 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, one method is for an
organization to 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 verify the signature to determine that the signing
identity took responsibility for the message. Message recipients
can verify the signature by querying the DNS for 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
Administrative Management Domain (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 are
performed using different, external services, such as for key
retrieval and relaying email.
The basic DKIM signing specification defines
an initial set of these services (using DNS and SMTP),
in order to ensure a basic
level of interoperability.</preamble>
<?rfc needLines="42" ?>
<artwork name="DKIM Service Architecture"><![CDATA[
|
|- RFC2822 Message
V
+--------+ +------------------------------------+
| Private| | ORIGINATING OR RELAYING ADMD (MSA) |
| Key |.>| Sign Message |
| Store | +--------------+---------------------+
+--------+ |
(paired) |
+--------+ | +-----------+
| Public | | | Remote |
| Key | [Internet] | Sender |
| Store | | | Practices |
+----+---+ | +-----+-----+
. V .
. +-----------------------------------+ .
. | RELAYING OR DELIVERING ADMD (MDA) | .
. | Message Signed? | .
. +--------+---------------+----------+ .
. |yes |no .
. V | .
. +------------+ | .
+.....>| Verify +----+ | .
| Signatures | | | .
+-----+------+ | | .
pass| fail| | .
V | | .
+--------+ | | .
+.......>| Assess | | | .
. | Signer | V V .
. +---+----+ +-------+ .
. | / Check \<............+
. +------>/ Signing \
. | / Practices \<..........+
. | +-------+-------+ .
. | | .
. | V .
+---+---------+ | +-----------+ +------+-----+
|Reputation/ | | | Message | | Local Info |
|Accreditation| +------>| Filtering | | on Sender |
|Info | | Engine | | Practices |
+-------------+ +-----------+ +------------+]]>
</artwork>
</figure>
<t>As shown in <xref target="DKIMSvc" />, basic message processing is
divided between the MSA and the MDA.
<list style="hanging">
<t hangText="The MSA"> The MSA signs the message, using private
information from the Key Store. </t>
<t hangText="The MDA"> The MDA verifies the signature or
determines whether a signature was required. Verifying the
signature uses public information from the Key Store. If the
signature passes, reputation information is used to asses the
signer and that information is passed to the message filtering
system. If the signature fails or there is no signature,
information about the related signing practices is retrieved
remotely and/or locally, and that information is passed to the
message filtering system.
</t>
<t hangText="Note:">
<xref target="DKIMSvc" /> does not show the effects on the
message handling
when multiple signatures or non-author signatures are present.
</t>
</list>
</t>
<section title="Administration and Maintenance">
<t> A number of tables and services are used to provide external
information. Each of these introduces administration and
maintenance requirements.
<list style="hanging">
<t hangText="Key Store"> DKIM uses public/private (asymmetric)
key cryptography. The signer users a private key and the
validator uses the corresponding public key. The current
DKIM signing specification provides for querying the Domain
Names Service (DNS), to permit a validator to obtain the
public key. The signing organization therefore must have a
means of adding a key to the DNS, for every
selector/domain-name combination. Further, the signing
organization needs policies for distributing and revising
keys. </t>
<t hangText="Reputation/Accreditation"> If a message contains
a valid signature, then the verifier can evaluate the
associated domain name's reputation. Quality-assessment
information, which is associated with a domain name, comes
in many forms and from many sources. DKIM does not define
assessment services. It's relevance to them is to provide a
validated domain name, upon which assessments can be made. </t>
<t hangText="Signing Practices (SP)"> Separate from
determining the validity of a signature, and separate from
assessing the reputation of the organization that is
associated with the signed identity, there is an the
opportunity to determine any organizational practices
concerning a domain name. Practices can range widely. They
can be published by the owner of the domain or they can be
maintained by the evaluating site.
They can pertain to the
use of the domain name, such as whether it is used for
signing messages, whether all mail having that domain name
in the author From: header field is signed, or whether such
mail is to be discarded in the absence of an appropriate
signature.
The statements of practice are made at the level
of a domain name, and are distinct from assessments made
about particular messages, as occur in a Message Filtering
Engine.
Such assessments of practices can provide useful
input for the Message Filtering Engine's determination of
message handling. As practices are defined, each domain
name owner needs to consider what information to publish.
The nature and degree of checking practices, if any is
performed, is optional to the evaluating site and is
strictly a matter of local policy. </t>
</list>
</t>
</section>
<section title="Signing">
<t>Signing can 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>
</section>
<section title="Verifying">
<t>Verification can 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. </t>
</section>
<section title="Unverified or Unsigned Mail">
<t>Note that a failed signature causes the message to be treated in
the same manner as one that is unsigned. Messages lacking a valid
author signature (a signature associated with the author of the
message as opposed to a signature associated with an
intermediary) can prompt a query for any published "signing
practices" information, as an aid in determining whether the
author information has been used without authorization. </t>
</section>
<section title="Assessing">
<t><xref target="DKIMSvc" /> 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. A popular
use of reputation information is as input to a filtering engine
that decides whether to deliver -- and possibly whether to
specially mark -- a message. Filtering engines have become
complex and sophisticated. Their details are outside of the scope
of DKIM, other than the expectation that the validated identity
produced by DKIM will be added to the varied soup of rules used
by the engines. The rules can cover signed messages and can deal
with unsigned messages from a domain, if the domain has published
information about its practices. </t>
</section>
<section title="DKIM Placement within an ADMD">
<t>It is expected that the most common venue for a DKIM
implementation will be within the infrastructures of the
authoring organization's outbound service and the receiving
organization's inbound service, such as a department or a
boundary MTA. DKIM can be implemented in an author's or recipient
MUA, but this is expected to be less typical, since it has higher
administration and support costs. </t>
<t>A Mediator, such as a mailing list, often can re-post a message
without breaking the DKIM signature. Furthermore it can add its
own signature. This can be added by the Mediator software itself,
or by any outbound component in the Mediator's ADMD. </t>
</section>
</section>
<section title="Security Considerations">
<t> The security considerations of the DKIM protocol are described in
the DKIM base specification <xref target="RFC4871" />. </t>
</section>
<section title="IANA Considerations">
<t> There are no actions for IANA. <list style="hanging">
<t hangText="NOTE TO RFC EDITOR: ">This section may be removed
prior to publication. </t>
</list>
</t>
</section>
<section title="Acknowledgements">
<t> Many people contributed to the development of the DomainKeys
Identified Mail and the efforts of the DKIM Working Group is
gratefully acknowledged. In particular, we would like to thank Jim
Fenton for his extensive feedback diligently provided on every
version of this document. </t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<!-- references title="Normative References"> </references -->
<references title="Informative References">&dkimbase; &dkimta;
&rfc1034; &rfc2822; &dk; &pem; &moss; &pgp1;
&rfc2821; &rfc2440; &rfc3156; &syslog;
&rfc3851; &ar; &rfc4406; &rfc4407; &rfc4408; &openpgp;
<reference anchor="Kohnfelder">
<front>
<title>Towards a Practical Public-key Cryptosystem</title>
<author fullname="Loren M. Kohnfelder" initials="L."
surname="Kohnfelder">
<organization abbrev="MIT"> Massachusetts Institute of
Technology </organization>
</author>
<date month="May" year="1978" />
</front>
</reference>
</references>
<section anchor="appendixMailBackground" title="Internet Mail Background">
<t>Internet Mail is 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, the
author, and delivering it to one or more other users, the
recipients. This creates a virtual MUA-to-MUA exchange environment.
The first component of the MHS is called the Mail Submission Agent
(MSA) and the last is called the Mail Delivery Agent (MDA). </t>
<t> An email Mediator is both an inbound MDA and outbound MSA. It takes
delivery of a message and re-posts it for further distribution,
retaining the original From: header field. A mailing list is a
common example of a Mediator. </t>
<t>The 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, which are
subject to coherent operational policies. </t>
<t>As elaborated on below, every MSA is a candidate for signing using
DKIM, and every MDA is a candidate for doing DKIM verification. </t>
<section anchor="AdminDomain"
title="Administrative Management Domain (ADMD)">
<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 types of ADMDs 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[
+--------+ +--------+ +--------+
| ADMD#1 | | ADMD#3 | | ADMD#4 |
| ------ | | ------ | | ------ |
| | +----------------------->| | | |
| User | | |--Edge--+--->|--User |
| | | | +--->| | | |
| V | | | +--------+ +--------+
| Edge---+---+ |
| | | +----------+ |
+--------+ | | ADMD#2 | |
| | ------ | |
| | | |
+--->|-Transit--+---+
| |
+----------+]]></artwork>
</figure>
<t> In <xref target="ADMD" />, ADMD numbers 1 and 2 are candidates
for doing DKIM signing, and ADMD numbers 2, 3 and 4 are
candidates for doing DKIM verification.
<!-- QUESTION: Dumb one -
can we think of any sort of credible scenario where it would
make sense for ADMD#3 to do signing? /d -->
</t>
<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 a single ADMD are subject to the policies of that domain.
Although any pair of ADMDs can arrange for whatever policies they
wish, Internet Mail is designed to permit inter-operation without
prior arrangement. </t>
<t>Common ADMD examples are:
<list>
<t>
<list>
<t> Enterprise Service Providers:
<list>
<t>Operators of an organization's internal data
and/or mail services. </t>
</list>
</t>
<t>Internet Service Providers:
<list>
<t>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>
</list>
</t>
<t>Mail Service Providers:
<list>
<t>Operators of email services, such as for
end-users, or mailing lists. </t>
</list>
</t>
</list>
</t>
</list>
</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:47:38 |