Network Working Group S. Atkins
Internet-Draft Word to the Wise
Intended status: Standards Track J. Falk
Expires: August 3, 2008 Return Path
J. Levine, Ed.
Taughannock Networks
W. Venema
IBM T. J. Watson Research
January 31, 2008
DKIM Author Signing Practices (ASP)
draft-levine-asp-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
Atkins, et al. Expires August 3, 2008 [Page 1]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
contents of messages by either Mail Transport Agents (MTAs) or Mail
User Agents (MUAs). The primary DKIM protocol is described in
[RFC4871]. This document describes the records that authors can use
to advertise their practices for signing their outgoing mail, and how
other hosts can access those records.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Language and Terminology . . . . . . . . . . . . . . . . . . . 3
2.1. Terms Imported from DKIM Signatures Specification . . . . 3
2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 4
2.3. Author Address . . . . . . . . . . . . . . . . . . . . . . 4
2.4. Author Domain . . . . . . . . . . . . . . . . . . . . . . 4
2.5. Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 4
2.6. Alleged Authors . . . . . . . . . . . . . . . . . . . . . 4
2.7. Author Signing Practices . . . . . . . . . . . . . . . . . 4
2.8. Author Signature . . . . . . . . . . . . . . . . . . . . . 4
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. ASP Usage . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. ASP Results . . . . . . . . . . . . . . . . . . . . . . . 5
4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 6
4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 6
4.2. Publication of ASP Records . . . . . . . . . . . . . . . . 6
4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . . . 7
4.4. Author Signing Practices Lookup Procedure . . . . . . . . 8
5. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Single Location Domains . . . . . . . . . . . . . . . . . 9
5.2. Bulk Mailing Domains . . . . . . . . . . . . . . . . . . . 10
5.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 10
5.4. Third Party Senders . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. References - Normative . . . . . . . . . . . . . . . . . . 11
6.2. References - Informative . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Atkins, et al. Expires August 3, 2008 [Page 2]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
1. Introduction
Much of this document is adapted from [I-D.ietf-dkim-ssp-01] by
Allman et al. The features described here are approximately a subset
of the ones described in that document.
DomainKeys Identified Mail (DKIM) defines a mechanism by which email
messages can be cryptographically signed, permitting a signing domain
to claim responsibility for the introduction of a message into the
mail stream. 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.
However, the legacy of the Internet is such that not all messages
will be signed, and the absence of a signature on a message is not an
a priori indication of forgery. In fact, during early phases of
deployment it is very likely that most messages will remain unsigned.
However, some domains might decide to sign all of their outgoing
mail, for example, to protect their brand name. It is highly
desirable for such domains to be able to advertise that fact to other
hosts. This is the topic of Author Signing Practices (ASP).
In the absence of a valid DKIM signature, hosts implementing this
specification can inquire what Author Signing Practices that domain
advertises. This inquiry is called an Author Signing Practices
check.
The detailed requirements for Author Signing Practices are given in
[I-D.ietf-dkim-ssp-requirements]. This document refers extensively
to [RFC4871] and assumes the reader is familiar with it.
Requirements Notation: The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in [RFC2119]
2. Language and Terminology
2.1. Terms Imported from DKIM Signatures Specification
Some terminology used herein is derived directly from [RFC4871]. In
several cases, references in that document to Sender have been
changed to Author here, to emphasize the relationship to the Author
address(es) on the From: header line described in [RFC2822].
Briefly,
Atkins, et al. Expires August 3, 2008 [Page 3]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
o A "Signer" is the agent that signs a message. In many cases it
will correspond closely with the original author of the message or
an agent working on the author's behalf.
o A "Selector" specifies which of the keys published by a signing
domain is to be queried. It is essentially a way of subdividing
the address space to allow a single sending domain to publish
multiple keys.
2.2. Valid Signature
A "Valid Signature" is any signature on a message which correctly
verifies using the procedure described in section 6.1 of [RFC4871].
2.3. Author Address
An "Author Address" is an email address in the From header field of a
message [RFC2822]. If the From header field contains multiple
addresses, the message has multiple Author Addresses.
2.4. Author Domain
An "Author Domain" is everything to the right of the "@" in an Author
Address (excluding the "@" itself).
2.5. Alleged Signer
An "Alleged Signer" is the identity of the signer claimed in a DKIM-
Signature header field in a message received; it is "alleged" because
it has not yet been verified.
2.6. Alleged Authors
An "Alleged Author" is an Author Address of a message; it is
"alleged" because it has not yet been verified.
2.7. Author Signing Practices
"Author Signing Practices" (or just "practices") consist of a
machine-readable record published by the domain of an Alleged Author
which includes statements about the domain's practices with respect
to mail it sends with its domain in the From: line.
2.8. Author Signature
An "Author Signature" is any Valid Signature where the signing domain
(listed in the "i=" tag if present, otherwise its default value,
consisting of the value of the "d=" tag) matches the domain of an
Atkins, et al. Expires August 3, 2008 [Page 4]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
Author Address.
3. Operation Overview
A host typically looks up Author Signing Practices based on the
Author Address(es).
Hosts can look up the Author Signing Practices of the domain(s)
specified by the Author Address(es) as described in Section 4.4.
3.1. ASP Usage
Depending on the Author Domain(s) and the signatures in a message, a
recipient gets varying amounts of useful information from an ASP
lookup.
o If a message has no Valid Signature, the ASP result is directly
relevant to the message.
o If a message has a Valid Signature from an Author Domain, ASP
provides no benefit relative to that domain since the message is
already known to be compliant with any possible ASP for that
domain.
o If a message has a Valid Signature from a domain other than an
Author Domain, the receiver can use both the Signature and the ASP
result in its evaluation of the message.
3.2. ASP Results
An Author Signing Practices lookup produces one of four possible
results:
o Messages from this domain might or might not have an author
signature. This is the default if the domain exists but no record
is found.
o All messages from this domain are signed.
o All messages from this domain are signed and discardable.
o The domain does not exist.
Atkins, et al. Expires August 3, 2008 [Page 5]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
4. Detailed Description
4.1. DNS Representation
Author Signing Practices records are published using the DNS TXT
resource record type.
NON-NORMATIVE DISCUSSION [to be removed before publication]: There
has been considerable discussion on the DKIM WG mailing list
regarding the relative advantages of TXT and a new resource record
(RR) type. Read the archive for details.
The RDATA for ASP resource records is textual in format, with
specific syntax and semantics relating to their role in describing
Author Signing Practices. The "Tag=Value List" syntax described in
section 3.2 of [RFC4871] is used. Records not in compliance with
that syntax or the syntax of individual tags described in Section 4.3
MUST be ignored (considered equivalent to a NODATA result) for
purposes of ASP, although they MAY cause the logging of warning
messages via an appropriate system logging mechanism. If the RDATA
contains multiple character strings, the strings are logically
concatenated with no delimeters between the strings.
ASP records for a domain are published at a location in the domain's
DNS hierarchy prefixed by _asp._domainkey.; e.g., the ASP record for
example.com would be a TXT record that is published at
_asp._domainkey.example.com. A domain MUST NOT publish more than one
ASP record; the semantics of an ASP lookup that returns multiple ASP
records for a single domain are undefined. (Note that example.com
and mail.example.com are different domains.)
4.2. Publication of ASP Records
Author Signing Practices are intended to apply to all mail sent from
a domain, and to the greatest extent possible, to all subdomains of
that domain. There are several cases that need to be considered in
that regard:
o The domain itself
o Subdomains which might or might not be used for email
o Host names which might or might not be used for email
o Other named resource records in the domain
o Multi-level examples of the above, e.g., a.b.example.com
Atkins, et al. Expires August 3, 2008 [Page 6]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
o Non-existent cases, i.e., a subdomain or hostname that does not
actually exist within the domain
A domain publishing Author Signing Practices may want to do so for
both itself and all of its "descendants" (child domains and hosts, at
all lower levels). Domains wishing to do so publish ASP records as
follows:
o Publish an ASP record for the domain itself.
o Publish an ASP record for any existing subdomain.
Note that since the lookup algorithm described below references the
immediate parent of the alleged originating domain, it is not
necessary to publish ASP records for every single-level label within
the domain. This has been done to relieve domain administrators of
the burden of publishing an ASP record for every other record in the
domain, which would be otherwise needed.
Wildcards within a domain, including but not limited to wildcard MX
records, pose a particular problem. While referencing the immediate
parent domain allows the discovery of an ASP record corresponding to
an unintended immediate-child subdomain, wildcard records apply at
multiple levels. For example, if there is a wildcard MX record for
example.com, the domain foo.bar.example.com can receive mail through
the named mail exchanger. Conversely, the existence of the record
makes it impossible to tell whether foo.bar.example.com is a
legitimate name since a query for that name will not return an
NXDOMAIN error. For that reason, ASP coverage for subdomains of
domains containing a wildcard record is incomplete.
NON-NORMATIVE NOTE [to be removed before publication]: Complete ASP
coverage of domains containing (or where any parent contains)
wildcards generally cannot be guaranteed.
4.3. Record Syntax
ASP records follow the "tag=value" syntax described in section 3.2 of
[RFC4871]. The ASP record syntax is a tag-list as defined in that
section, including the restriction on duplicate tags, the use of
white space, and case sensitivity.
Tags used in ASP records are as follows. Unrecognized tags MUST be
ignored. In the ABNF below, the ALPHA and DIGIT tokens are imported
from [RFC4234].
Atkins, et al. Expires August 3, 2008 [Page 7]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
dkim= Outbound signing practices for the domain (plain-text;
REQUIRED). Possible values are as follows:
unknown The domain might sign some or all email.
all All mail from the domain is signed with an Author Signature.
discardable All mail from the domain is signed with an Author
Signature. Furthermore, if a message arrives without a valid
Author Signature due to modification in transit, submission via
a path without access to a signing key, or other reason, the
domain encourages the recipient(s) to discard it.
ABNF:
asp-dkim-tag = "dkim=" ("unknown" / "all" / "discardable")
t= Flags, represented as a colon-separated list of names (plain-text;
OPTIONAL, default is that no flags are set). Flag values are:
s The signing practices apply only to the named domain, and not
to subdomains.
ABNF:
asp-t-tag = %x75 "=" asp-t-tag-flag
0*( ":" asp-t-tag-flag )
asp-t-tag-flag = "s" / hyphenated-word
; for future extension
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-")
(ALPHA / DIGIT) ]
Unrecognized flags MUST be ignored.
4.4. Author Signing Practices Lookup Procedure
To look up the Author Signing Practices of a domain, ASP Checkers
doing an ASP lookup MUST produce a result that is semantically
equivalent to applying the following steps in the order listed below.
In practice, several of these steps can be performed in parallel in
order to improve performance. However, implementations SHOULD avoid
doing unnecessary DNS lookups. For the purposes of this section a
"valid ASP record" is one that is both syntactically and semantically
correct; in particular, it must match the ABNF for a "tag-list" and
must include a defined "dkim=" tag.
1. The host makes a DNS query for a TXT record corresponding to the
domain prefixed by "_asp._domainkey.". If the result of this
Atkins, et al. Expires August 3, 2008 [Page 8]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
query is a NOERROR response with an answer which contains a
syntactically-valid ASP record, the Author Signing Practices are
described by the contents of the record and the algorithm
terminates.
2. The host MUST query DNS for an MX record corresponding to the
domain (with no prefix). This query is made only to check the
existence of the domain name and MAY be done in parallel with the
query made in step 1. If the result of this query is an NXDOMAIN
error, the domain does not exist and the algorithm terminates.
NON-NORMATIVE DISCUSSION [to be removed before publication]: Any
resource record type could be used for this query since the
existence of a resource record of any type will prevent an
NXDOMAIN error. The choice of MX for this purpose is because
this record type is thought to be the most common for likely
domains, and will therefore result in a result which can be more
readily cached than a negative result.
3. The host MUST query DNS for a TXT record for the immediate parent
domain, prefixed with "_asp._domainkey." If the result of this
query is a NOERROR response with one or more answers that are
syntactically-valid ASP responses, and the responses do not
contain a "s" flag, the Author Signing Practices are described by
the contents of the record(s).
If any of the queries involved in the Author Signing Practices Check
result in a SERVFAIL error response, the host MAY either queue the
message or return an SMTP error indicating a temporary failure.
5. Usage Examples
These examples are intended to illustrate typical uses of ASP. They
are not intended to be exhaustive, nor to apply to every domain or
mail system's individual situation.
5.1. Single Location Domains
A common mail system configuration handles all of a domain's users'
incoming and outgoing mail through a single MTA or cluster of MTAs.
In that case, the MTA(s) can be configured to sign outgoing mail with
an Author Signature.
In this situation it might be appropriate to publish an ASP record
for the domain containing "all", depending on whether the users also
send mail through other MTAs that do not apply an Author Signature.
Such MTAs could include MTAs at hotels or hotspot networks used by
Atkins, et al. Expires August 3, 2008 [Page 9]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
travelling users, or web sites that provide "mail an article"
features.
Domain managers are advised to consider the ways that mail processing
can modify messages in ways that will invalidate an existing DKIM
signature, such as mailing lists, courtesy forwarders, and other
paths that could add or modify headers, or modify the message body.
In that case, if the modifications invalidate the DKIM signature,
recipient MTAs will consider the mail not to have an Author
Signature, even though the signature was present when the mail was
originally sent.
5.2. Bulk Mailing Domains
Another common configuration uses a domain solely for bulk or
broadcast mail, with no individual human users, again typically
sending all the mail through a single MTA or cluster of MTAs that can
apply an Author Signature. In this case, the domain's management can
be confident that all of its outgoing mail will be sent through the
signing MTA. Lacking individual users, the domain is unlikely to
participate in mailing lists, but could still send mail through other
paths that might invalidate signatures.
Domain owners often use specialist mailing providers to send their
bulk mail. In that case, the mailing provider needs access to a
suitable signing key in order to apply an Author Signature. One
possible route would be for the domain owner to generate the key and
give it to the mailing provider. Another would be for the domain to
delegate a subdomain to the mailing provider, for example,
bigbank.example might delegate email.bigbank.example to such a
provider. In that case, the provider can generate the keys and DKIM
DNS records itself and use the subdomain in the Author address in the
mail.
5.3. Bulk Mailing Domains with Discardable Mail
In some cases, a domain might sign all its outgoing mail with an
Author Signature, but prefers that recipient systems discard mail
without a valid Author Signature to avoid confusion from mail sent
from sources that do not apply an Author Signature. (This latter
kind of mail is sometimes loosely called "forgeries".) In that case,
it may be appropriate to publish an ASP record containing
"discardable". Note that a domain SHOULD NOT publish a "discardable"
record if it wishes to maximize the likelihood that mail from the
domain is delivered, since it could cause some fraction of the mail
the domain sends to be discarded.
As a special case, if a domain sends no mail at all, it can safely
Atkins, et al. Expires August 3, 2008 [Page 10]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
publish a "discardable" ASP record, since any mail with an author
address in the domain is a forgery.
5.4. Third Party Senders
Another common use case is for a third party to enter into an
agreement whereby that third party will send bulk or other mail on
behalf of a designated author domain, using that domain in the
RFC2822 From: or other headers. Due to the many and varied
complexities of such agreements, third party signing is not addressed
in this specification. The authors anticipate that as mail systems
gain experience with DKIM, it will become possible to codify best
practices of this and other usages of DKIM.
6. References
6.1. References - Normative
[I-D.ietf-dkim-ssp-requirements]
Thomas, M., "Requirements for a DKIM Signing Practices
Protocol", April 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
6.2. References - Informative
[I-D.ietf-dkim-ssp-01]
Allman, E., Delany, M., and J. Fenton, "DKIM Sender
Signing Practices", September 2007.
Appendix A. Acknowledgements
This document adapted large sections from a previous draft by Eric
Allman, Jim Fenton, et al. It greatly benefited from comments by Jon
Callas, Dave Crocker, Arvel Hathcock, Ellen Siegel, and Michael
Atkins, et al. Expires August 3, 2008 [Page 11]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
Thomas.
Authors' Addresses
Steve Atkins
Word to the Wise
PO Box 7086
San Carlos, CA 94070-7086
US
Phone: +1 650 678 3453
Email: steve-asp@wordtothewise.com
URI: http://wordtothewise.com/
J. D. Falk
Return Path
100 Superior Plaza Way
Superior, CO 80027
Phone: +1 303 642 4100
Email: ietf@cybernothing.org
John Levine (editor)
Taughannock Networks
PO Box 727
Trumansburg, NY 14886
Phone: +1 831 480 2300
Email: standards@taugh.com
URI: http://www.taugh.com
Wietse Venema
IBM T. J. Watson Research
19 Skyline Drive
Hawthorne, NY 10532
Email: wietse@watson.ibm.com
Atkins, et al. Expires August 3, 2008 [Page 12]
Internet-Draft DKIM Author Signing Practices (ASP) January 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Atkins, et al. Expires August 3, 2008 [Page 13]