wdiff draft-ietf-dkim-ssp-01.txt draft-ietf-dkim-ssp-02.txt

DKIM Working Group E. Allman
Internet-Draft Sendmail, Inc.
Intended status: Standards Track M. Delany
Expires: March 20, August 4, 2008 Yahoo! Inc.
J. Fenton
Cisco Systems, Inc.
September 17, 2007
February 1, 2008

DKIM Sender Signing Practices
draft-ietf-dkim-ssp-01
draft-ietf-dkim-ssp-02

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 March 20, August 4, 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
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 senders may authors' domains can use to
advertise
how they sign their practices regarding signing their outgoing mail, and
how verifiers should access other hosts can access, parse and interpret those results. records.

Requirements Language

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].

(Unresolved Issues/To Be Done)

o Need to consider handling of multiple responses to a DNS query for
the SSP record.

o Security Considerations needs a detailed examination.

o IANA Considerations should be formalized (e.g., as in 4871).

o Check over the references.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Language and Terminology . . . . . . . . . . . . . . . . . . . 5 4
2.1. Terms Imported from DKIM Signatures Specification . . . . 5
2.2. Valid Signature Evaluator . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Originator Address SSP Checker . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Originator Domain Valid Signature . . . . . . . . . . . . . . . . . . . . 6 . 5
2.5. Alleged Signer Author . . . . . . . . . . . . . . . . . . . . . . 6 5
2.6. Alleged Originator Author Address . . . . . . . . . . . . . . . . . . . . . . 6
2.7. Sender Signing Practices Author Domain . . . . . . . . . . . . . . . . . . . . . . 6
2.8. Originator Author Signature . . . . . . . . . . . . . . . . . . . . . 6
2.9. Suspicious Sender Signing Practices Record . . . . . . . . . . . . . 6
3. Operational Description . . . . . . . . . . . 6
2.10. Third-Party Signature . . . . . . . . 6
3.1. Publication of SSP Records . . . . . . . . . . 7
2.11. Verifier Acceptable Third-Party Signature . . . . . . 6
3.2. Lookup of SSP Records . . 7
3. Operation Overview . . . . . . . . . . . . . . . . 8
3.3. SSP Record Syntax . . . . . . 7
4. Detailed Description . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . 8
4.1. DNS Representation . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . 8
4.2. Publication of SSP Records . . . . . . . . . . . . . 11
5.1. DNS Attacks . . . 9
4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . 11
5.2. DNS Wildcards . . 10
4.4. Sender Signing Practices Check Procedure . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . 11
6. References . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . 13
6.1. Fraudulent Sender Address . . . . . . . . . . . . . . . . 14 12
6.2. DNS Attacks Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Usage Examples (INFORMATIVE) . . . . . 14
7. References . . . . . . . 13
A.1. Single Location Domains . . . . . . . . . . . . . . . . . 13
A.2. Bulk Mailing Domains . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . 13
A.3. Bulk Mailing Domains with Discardable Mail . . . . . . . . 14
7.2. Informative References
A.4. Third Party Senders . . . . . . . . . . . . . . . . . . 15 . 14
Appendix A. B. Acknowledgements . . . . . . . . . . . . . . . . . . 15 14
Appendix B. C. Change Log . . . . . . . . . . . . . . . . . . . . . 14
C.1. Changes since -ietf-dkim-ssp-01 . . . . . . . . . . . . . 15
B.1.
C.2. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 15
B.2. 16
C.3. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16
B.3.
C.4. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16
B.4.
C.5. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 16 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18 19

1. Introduction

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 signed. Therefore, the absence of a signature on a message is not an a
priori indication of forgery. In fact, during early phases of DKIM
deployment it must be expected that most messages will remain
unsigned. However, Nevertheless, some domains may choose find it highly desirable to
advertise that they sign all of their outgoing mail, for example, mail making the
absence of a valid signature a potential indication of forgery.
Without a mechanism to protect their brand name. It is
highly desirable for such domains do so, the benefits of DKIM are limited to be able to advertise that fact
to verifiers, and that messages claiming to be from them that do not
have
cases in which a valid signature are likely to exists and cannot be forgeries. This is the topic
for sender signing practices.

In the absence of a valid DKIM signature on behalf of the "From"
address [RFC2822], message verifiers implementing this specification
MUST determine whether messages from that sender are expected extended to be
signed, and what
cases in which signatures are acceptable. In particular, whether a
domain signs all outbound email must be made available to the
verifier. Without missing or are invalid. Defining such
a mechanism, mechanism is the benefit purpose of message signing
techniques such as DKIM is limited since unsigned messages will
always need to be considered to be potentially legitimate. This
determination is referred to as a Sender Signing Practices check.

Conceivably, such expressions might be imagined to be extended in the
future to include information about what hashing algorithms a domain
uses, what kind of messages might be sent (e.g., bulk vs. personal
vs. transactional), etc. Such concerns are out of scope of this
standard, because they can be expressed in the key record
("Selector") with which the signature is verified. In contrast, this (SSP).

This specification focuses on information which is relevant in the
absence of a valid an acceptable signature. Expressions of signing practice
which require outside auditing are similarly out of scope for this
specification because they fall under the purview of reputation and
accreditation. Sender Signing Practices can be extended in the
future to include additional information that a receiver might use as
input to a processing decision.

More specifically, this specification defines the SSP Checker, a
module that retrieves the SSP information for a given domain, and the
format of the data returned. An module called the Evaluator combines
information from DKIM signatures, SSP Checker results, and any other
data sources it cares to use in order to make a decision regarding
how the message should be processed. The Evaluator is explicitly out
of scope of this document, and is described herein in order to make
the limits of this specification clear.

The detailed requirements for Sender Signing Practices are given in
[I-D.ietf-dkim-ssp-requirements],
[RFC5016], which the protocol described in this document attempts to
satisfy. This document refers extensively to [RFC4871], which should
be read as a prerequisite to this document.

2. Language and Terminology

2.1. Terms Imported from DKIM Signatures Specification

Some terminology used herein is derived directly from [RFC4871].
Briefly,

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 "Verifier" is "Selectors" describe the agent that verifies a message keys published by checking the
actual signature a signing domain.
Signing domains may have multiple Selectors. Selectors subdivide
the address space to allow a single sending domain to publish
multiple keys.

o A "Verifier" is the agent that verifies a message by checking
actual signature(s) in the message header against the message
itself and using the public key published in the Selector referenced
by a given signature.

2.2. Evaluator

The "Evaluator" is the Alleged Signer. module that makes the ultimate decision on how
an incoming message should be processed at a given site. In some
cases it may be colocated with the Verifier. The Verifier also looks up Evaluator combines
information from the
Sender Signing Practices published by DKIM signature(s) (if any), the domain output of the Originator
Address if
SSP Checker, and any other information it cares to consult in order
to make a processing decision about the message message. The specification
of the Evaluator is not correctly signed by out of scope of this document.

2.3. SSP Checker

The "SSP Checker" module performs the Alleged
Originator.

o A "Selector" specifies which SSP queries on behalf of the keys published by a signing
domain should be queried.
Evaluator. It is essentially a way of subdividing the address space to allow a single sending domain primary module defined by this document. The
input to publish
multiple keys.

2.2. the SSP Checker is an address extracted from the From header
field of the message being evaluated; the output is either the Sender
Signing Practices associated with that domain, or an error code.

2.4. 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. Originator

2.5. Alleged Author

An "Alleged Author" is the Author Address of a message received by an
Evaluator; it is "alleged" because it has not yet been verified.

2.6. Author Address

The "Originator "Author Address" is the an email address in the From header field of
a message [RFC2822], or if and only if [RFC2822]. If the From header field contains multiple
addresses, the first address in the From header
field.

NON-NORMATIVE RATIONALE: The alternative option when there are message has multiple addresses in Author Addresses, which may
potentially cause the From header field Evaluator to perform multiple SSP Checks for a
given message.

2.7. Author Domain

The "Author Domain" is everything to use the value of
the Sender header field. This would be closer to the semantics
indicated in [RFC2822] than using the first address in the From
header field. However, the large number of deployed Mail User
Agents that do not display the Sender header field value argues
against that. Multiple addresses in the From header field are
rare in real life.

Even when there is only one address in the From header field, this
address is chosen as the reference address for SSP lookups because
it represents the author of the message and is more widely
displayed by Mail User Agents as a result. The Sender header
field frequently has other meanings.

2.4. Originator Domain

The "Originator Domain" is everything to the right right of the "@" in the
Originator
Author Address (excluding the "@" itself).

2.5. Alleged Signer

2.8. Author Signature

An "Alleged Signer" "Author Signature" is any Valid Signature where the identity of
the signer claimed in a DKIM-
Signature header field in a user or agent on behalf of which the message received by a Verifier; it is
"alleged" because it has not yet been verified.

2.6. Alleged Originator

An "Alleged Originator" is signed (listed in
the "i=" tag or its default value from the Originator "d=" tag) matches an
Author Address of a message
received by a Verifier; it is "alleged" because it has not yet been
verified.

2.7. in the message.

2.9. Sender Signing Practices Record

A "Sender Signing Practices" (or just "practices") consist Practices Record" consists of a machine-readable
record published by the domain of the an Alleged
Originator Author which includes
information about on whether or not that domain signs all of their email, and whether signatures from third
parties are sanctioned by the Alleged Originator.

2.8. Originator Signature

An "Originator Signature"
related information. That record is any Valid Signature where the signing
address (listed defined in the "i=" tag if present, otherwise its default
value, consisting detail in section
Section 3.3.

3. Operational Description

The use of the null address, representing an unknown user,
followed Sender Signing Practices consists of two parts:

Publication of SSP records by "@", followed author domains wishing to do so

Lookup of SSP records by an SSP Checker under the value direction of an
Evaluator.

3.1. Publication of SSP Records

3.1.1. DNS Representation

Sender Signing Practices Records are published using the "d=" tag) matches the
Originator Address. If the signing address does not include a local-
part, then only DNS "TXT"
resource record type.

*[[DRAFT DISCUSSION, TO BE DELETED BEFORE PUBLICATION*: There has
been considerable discussion on the domains must match; otherwise, DKIM WG mailing list regarding
the two addresses
must be identical.

2.9. Suspicious

Messages that do not contain relative advantages of TXT and a valid Originator Signature new resource record (RR)
type. Many DNS server and which resolver implementations are inconsistent with incapable
of quickly and easily supporting new resource record types. For
this reason, support of TXT records is required whether a Sender Signing Practices check (e.g., are
received new RR
type is defined or not. However, without a Valid Signature and the sender's signing practices
indicate all messages from the domain are signed) are referred "flag day" on which
SSP TXT record support is to as
"Suspicious". The handling of be withdrawn, such messages support is at the discretion of
the Verifier or final recipient. "Suspicious" applies only likely
to the
DKIM evaluation of the message; continue indefinitely. As a Verifier may decide the message
should be accepted on the basis of other information beyond the scope
of result, this document. Conversely, messages not deemed Suspicious may be
rejected specification defines
no new RR type for other reasons.

2.10. Third-Party Signature

A "Third-Party Signature" SSP.

Another alternative proposed by P. Hallam-Baker is the publication
of both a Valid Signature which is not an
Originator Signature.

2.11. Verifier Acceptable Third-Party Signature

A Verifier Acceptable Third-Party Signature is TXT record and, when implementations permit, a Third-Party
Signature that the Verifier is willing new RR,
referred to accept as meaningful for XPTR, which gives the message under consideration. The Verifier may use any criteria
it deems appropriate for making this determination.

3. Operation Overview

Sender Signing Practices checks MUST location from which SSP and
other policy information relating to a give domain can be based on
retrieved. This has the Originator
Address. If the message contains advantage of supporting a valid Originator Signature, no
Sender Signing Practices check need be performed: the Verifier
SHOULD NOT look up variety of
policies in a scalable manner, with better handling of wildcards
and centralized publication of policy records, with caching
advantages. However, the Sender Signing Practices above implementation issues also apply
to XPTR, and an additional lookup is required to retrieve SSP via
the message MUST
NOT be considered Suspicious.

Verifiers checking messages that do not have at least one valid
Originator Signature MUST perform a Sender Signing Practices check on XPTR method. At the domain specified by time of publication of this draft,
consensus on this proposal was unclear.*]]*

The RDATA for SSP resource records is textual in format, with
specific syntax and semantics relating to their role in describing
sender signing practices. SSP records follow the Originator Address as tag-list syntax
described in
Section 4.4.

A Sender Signing Practices check produces one section 3.2 of four possible
results:

1. Some messages from this domain are not signed; [RFC4871], including the message MUST
NOT be considered Suspicious, even in restriction on
duplicate tags, the absence use of a valid
signature. This is the default.

2. All messages from this domain are signed. Messages containing a
Verifier Acceptable Third-Party Signature white space, and case sensitivity.
Records not in overall compliance with that syntax MUST NOT be considered
Suspicious.

NON-NORMATIVE RATIONALE: Third-party signatures, since they
can potentially represent any domain, are considered more
likely to be abused by attackers seeking ignored
(considered equivalent to spoof a specific
address. It may therefore "NODATA" result), although they MAY cause
the logging of warning messages via an appropriate system logging
mechanism. All syntactically valid tags MUST be desirable for verifiers made available to apply
other criteria outside
the scope Evaluator.

3.1.2. Location of this specification in
deciding to accept a given third-party signature. For
example, SSP Records

SSP records for a list of known mailing list domains used by
addresses served by the verifier might be specifically
considered acceptable third-party signers.

3. All valid messages from this domain are signed; published at a location in the domain of domain's
DNS hierarchy prefixed by "_ssp._domainkey"; e.g., the
Alleged Originator requests that only messages with valid
Originator Signatures be considered not Suspicious; Third-Party
Signatures are irrelevant. This practice SSP record for
"example.com" would typically be used
by domains which send only transactional email (i.e., do not use
mailing lists and such a "TXT" record that is published at
"_ssp._domainkey.example.com".

Sender Signing Practices are likely intended to break signatures) and
which wish apply to emphasize security over deliverability all mail sent from
the domain of their
messages. an Alleged Author. In order to ensure that SSP applies
to any hosts within that domain (e.g., www.example.com,
ftp.example.com, etc.) the absence of a valid Originator Signature, SSP lookup algorithm looks up one level in
the
message MUST be considered Suspicious.

4. The domain does not exist; the message MUST tree. For example, mail signed by www.example.com may
optionally be considered
Suspicious.

If covered by the Sender Signing Practices SSP record for the domain does not exist
but the domain does exist, Verifier systems MUST assume that some
messages example.com. This
prevents administrators from this having to include an SSP record for
every name within a given domain.

Normally, a domain are not signed and the message MUST NOT be
considered Suspicious.

4. Detailed Description

4.1. DNS Representation expressing Sender Signing Practices will want to
do so for both itself and all of its "descendents" (child domains at
all lower levels). Domains wishing to do so MUST publish SSP records are published using the DNS TXT
resource record type.

NON-NORMATIVE DISCUSSION: There has been considerable discussion
on the DKIM WG mailing list regarding
for the relative advantages of
TXT domain itself and a new resource record (RR) type. Many DNS server and
resolver implementations are incapable of quickly and easily
supporting new resource record types. For this reason, support of
TXT any subdomains.

Wildcards within a domain publishing SSP records is required whether pose a new RR type particular
problem. This is defined or not.
However, without a "flag day" on which discussed in more detail in Section 5.2.

3.2. Lookup of SSP TXT record support is
to be withdrawn, such support is likely to continue indefinitely.
As a result, this specification defines no new RR type for SSP.

Another alternative proposed by P. Hallam-Baker Records

NON-NORMATIVE NOTE: While the operation of the Evaluator is outside
the publication scope of both a TXT record and, when implementations permit, a new RR,
referred this specification, it is generally not worthwhile for
an Evaluator to as XPTR, which gives the location from which request an SSP and
other policy information relating to a give domain can be
retrieved. This has check when the advantage results of supporting a variety that check
will not affect the disposition of
policies the message. Since the
information provided by SSP is only relevant in a scalable manner, with better handling of wildcards
and centralized publication of policy records, with caching
advantages. However, the above implementation issues also apply absence of valid
Author Signature(s), there is little to XPTR, and be gained by performing an additional lookup is required
SSP check on domains corresponding to retrieve valid Author Signatures. SSP via
checks may also be unnecessary when the XPTR method. At Evaluator has some other
basis for deciding to process the time of publication message "normally", including, but
not limited to, the presence of this draft,
consensus on this proposal was unclear.

The RDATA a DKIM signature that the Evaluator
has some basis to trust sufficiently for this purpose.

3.2.1. SSP resource records is textual in format, with
specific syntax and semantics relating to their role in describing
sender signing practices. Checker Results

A Sender Signing Practices check produces one of four possible
results for use by the Evaluator:

1. The "Tag=Value List" syntax described domain does not exist in
section 3.2 of [RFC4871] DNS.

2. The domain does exist, but no SSP Record is used. Records present.

3. The SSP Record exists, and that value is also returned.

4. The DNS information could not in compliance with be determined due to a transient
error such as "SERVFAIL".

3.2.2. SSP Lookup Algorithm

SSP Checkers doing an SSP lookup MUST produce a result that syntax or is
semantically equivalent to applying the syntax of individual tags described following steps in Section 4.3
MUST the order
listed below. In practice, several of these steps can be ignored (considered equivalent performed
in parallel in order to a NODATA result) for
purposes of message disposition, although they MAY cause improve performance. However,
implementations SHOULD avoid doing unnecessary DNS lookups. For the logging
purposes of warning messages via an appropriate system logging mechanism. this section a "valid SSP records record" is one that is both
syntactically and semantically correct; in particular, it must match
the ABNF for a domain are published at "tag-list" and must include a location in the domain's
DNS hierarchy prefixed by _ssp._domainkey; e.g., the defined "dkim=" tag.

1. _Fetch Named SSP record Record._ The SSP Checker MUST query DNS for
example.com would be a
TXT record that is published at
_ssp._domainkey.example.com.

4.2. Publication of SSP Records

Sender Signing Practices are intended to apply corresponding to all mail sent from the domain of an Alleged Originator, and to Author Domain prefixed by
""_ssp._domainkey."" (note the greatest extent
possible, to all subdomains trailing dot). If the result of that domain. There
this query is a "NOERROR" response with one or more answers which
are several cases valid SSP records, return that need record for interpretation by
the Evaluator; otherwise, continue to be considered in that regard:

o the next step.

2. _Verify Domain Exists._ The domain itself

o Subdomains which may or may not be used for email

o Hostnames which may or may not be used SSP Checker MUST perform a DNS query
for email

o Other named resource records in a record corresponding to the domain

o Multi-level examples Author Domain (with no prefix).
The type of the above, e.g., a.b.example.com

o Non-existent cases, i.e., a subdomain or hostname that does not
actually exist within the domain

Normally, a domain expressing Sender Signing Practices will want to
do so for both itself and all query can be of its "descendents" (child domains and
hosts, at all lower levels). Domains wishing any type, since this step is only
to do so MUST publish
SSP records as follows:

Publish an SSP record for determine if the domain itself

Publish an SSP record for any existing subdomain

Note that since exists in DNS. This query MAY
be done in parallel with the lookup algorithm described below references query made in step 2. If the
immediate parent result
of the alleged originating domain, it this query is not
necessary to publish an "NXDOMAIN" error, the SSP records Checker MUST return
an appropriate error to the Evaluator and terminate the
algorithm.

NON-NORMATIVE DISCUSSION: Any resource record type could be
used for every single-level label within this query since the domain. This has been done to relieve domain administrators existence of
the burden a resource record
of publishing any type will prevent an SSP record "NXDOMAIN" error. "MX" is a
reasonable choice for every other this purpose is because this record in type
is thought to be the
domain, most common for likely domains, and will
therefore result in a result which would can be otherwise required.

Wildcards within a domain, including but not limited to wildcard MX
records, pose more readily cached
than a particular problem. While referencing negative result.

3. _Try Parent Domain._ The SSP Checker MUST query DNS for a TXT
record for the immediate parent domain allows domain, prefixed with
""_ssp._domainkey."" If the discovery result of an SSP record corresponding to
an unintended immediate-child subdomain, wildcard records apply at
multiple levels. For example, if there this query is anything
other than a wildcard MX record for
example.com, "NOERROR" response with a valid SSP record, the domain foo.bar.example.com can receive mail through
algorithm terminates returning a result indicating that no SSP
record was present. If the named mail exchanger. Conversely, SSP "t" tag exists in the existence response
and any of the record
makes flags is "s" (indicating it impossible should not apply to tell whether foo.bar.example.com is a
legitimate name since
subdomain), the SSP Checker MUST also return a query for that name will not "No SSP Record"
result. Otherwise, return an
NXDOMAIN error. For that reason, SSP coverage record for subdomains interpretation by the
Evaluator.

If any of
domains containing the queries involved in the Sender Signing Practices Check
result in a wildcard record is incomplete.

NON-NORMATIVE NOTE: Complete "SERVFAIL" error response, the SSP Checker MUST return
that information to the Evaluator; possible actions include queuing
the message or returning an SMTP error indicating a temporary
failure.

3.3. SSP coverage of domains containing
(or where any parent contains) wildcards generally cannot be
guaranteed.

4.3. Record Syntax

SSP records follow Records MUST match the "tag=value" "tag-list" syntax described defined in section 3.2 of [RFC4871].
The SSP 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 specific tags used in SSP records are as follows. described below.
Unrecognized tags MUST be ignored. In the ABNF below, the FWS token is inherited from
[RFC2822] with the exclusion of obs-FWS. The ALPHA and DIGIT tokens
are imported from [RFC4234].

dkim= Outbound signing practices for the domain (plain-text;
REQUIRED). Possible values are as follows:

unknown The domain may sign some none, some, or all email.

all All mail from the domain is signed; unsigned email MUST be
considered Suspicious. The domain may send messages through
agents that may modify and re-sign messages, so email signed with a Verifier Acceptable Third-Party Signature SHOULD NOT be
considered Suspicious.

strict an Author Signature.

discardable All mail from the domain is signed; messages lacking signed with an Author
Signature. Furthermore, if a message arrives without a valid Originator
Author Signature MUST be considered Suspicious. The due to modification in transit, submission via
a path without access to a signing key, or other reason, the
domain does not expect encourages the recipient(s) to send messages through agents that may
modify and re-sign messages. discard it.

NON-NORMATIVE RATIONALE: Strict DISCUSSION: Sender signing practices may of
"discardable" would be used by
entities which send usually inappropriate for domains of end
users, because of the potential for mailing lists and similar
agents to modify messages in such a way as to render the
signature invalid. Domains sending mail that is expected to
pass with no significant modification to the recipient, such as
domains sending only transactional email to individual
addresses and which messages, are willing appropriate
places to accept consider the consequence publication of
having some mail which is re-signed appear suspicious in
return a "discardable" practice.
See [RFC5016] section 5.3 and Appendix A for additional control over their addresses. Strict
practices may also be used by entities which do not send
(and therefore do not sign) any email. further
discussion.

ABNF:

ssp-dkim-tag = "dkim" [FWS] *WSP "=" [FWS] *WSP ("unknown" /
"all" / "strict")

handling= Non-compliant message handling request for the domain
(plain-text; OPTIONAL). Possible values are "discardable")

t= Flags, represented as follows:

process Messages which a colon-separated list of names (plain-text;
OPTIONAL, default is that no flags are Suspicious from this domain SHOULD be
processed by the verifier, although set). Flag values are:

s The signing practices apply only to the SSP failure MAY named domain, and not
to subdomains.

ABNF:

ssp-t-tag = %x75 *WSP "=" *WSP ssp-t-tag-flag
0*( *WSP ":" *WSP ssp-t-tag-flag )
ssp-t-tag-flag = "s" / hyphenated-word
; for future extension
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-")
(ALPHA / DIGIT) ]
Unrecognized flags MUST be
considered included in subsequent evaluation of the message. This result that is provided
to the default value.

deny Messages which are Suspicious from this domain MAY be
rejected, bounced, or otherwise not delivered at the option of
the verifier.

NON-NORMATIVE EXPLANATION: The "deny" practice Evaluator.

4. IANA Considerations

IANA is intended
for use by domains that value security over deliverability.
For example, a domain used by a financial institution to
send transactional email, which signs all of its messages,
might consider their concern about phishing messages
purporting to come from their domain to be higher than their
concern about some some legitimate messages not being
delivered. The "handling=deny" practice allows them requested to
express that concern in a way that can be acted upon by
verifiers, if they so choose.

ABNF:

ssp-handling-tag = "handling" [FWS] "=" [FWS] ("process" /
"deny")

t= Flags, represented as create a colon-separated list of names (plain-text;
OPTIONAL, default is that no flags are set). Flag values are:

y The domain is testing signing practices, "DKIM selector name" registry and the Verifier
SHOULD NOT consider a message suspicious based on the record.

s The signing practices apply only to
reserve the named domain, selector name ""_ssp"" to avoid confusion between DKIM
key records and not SSP records.

*<<< Needs to subdomains.

ABNF:

ssp-t-tag = %x75 [FWS] "=" [FWS] ssp-t-tag-flag
0*( [FWS] ":" [FWS] ssp-t-tag-flag )
ssp-t-tag-flag = "y" / "s" / hyphenated-word
; for future extension
hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-")
(ALPHA / DIGIT) ]

Unrecognized flags MUST be ignored.

4.4. updated to be more complete; see 4871 for examples
>>>*

5. Security Considerations

Security considerations in the Sender Signing Practices Check Procedure

Verifiers MUST produce a result that is semantically equivalent are mostly
related to
applying attempts on the following steps part of malicious senders to represent
themselves as other authors, often in an attempt to defraud either
the order listed. In practice,
several of these steps can recipient or an Alleged Author.

Additional security considerations regarding Sender Signing Practices
may be performed in parallel found in order to
improve performance.

1. If a valid Originator Signature exists, the message is not
Suspicious, and DKIM threat analysis [RFC4686].

*<<<THIS SECTION IS NOT COMPLETE.>>>*

5.1. DNS Attacks

An attacker might attack the algorithm terminates.

2. The Verifier MUST query DNS for a TXT record corresponding infrastructure in an attempt to
the Originator Domain prefixed by "_ssp._domainkey.". If the
result of this query
impersonate SSP records. However, such an attacker is a NOERROR response with one or more
answers which are syntactically-valid SSP responses, proceed likely to
step 7.

3. The Verifier MUST query DNS for an MX
attack at a higher level, e.g., redirecting "A" or "MX" record corresponding
lookups in order to capture traffic that was legitimately intended
for the Originator Domain (with no prefix). This query is made only
to check target domain. Domains concerned about this should use
DNSSEC [RFC4033].

Because SSP operates within the existence framework of the domain name and MAY be done in
parallel with legacy e-mail
system, the query made default result in step 2. If the result absence of this
query is an NXDOMAIN error, the message is Suspicious and the
algorithm terminates.

NON-NORMATIVE DISCUSSION: Any resource SSP record type could be
used for this query since is that
the existence of a resource record
of any type will prevent an NXDOMAIN error. The choice domain does not sign all of MX
for this purpose is because this record type its messages. It is thought to be
the most common for likely domains, and will therefore result
in
important that the SSP Checker distinguish a result which DNS failure such as
SERVFAIL from other DNS errors so that appropriate actions can be more readily cached than
taken.

5.2. DNS Wildcards

Wildcards within a negative
result.

4. If domain publishing SSP records, including but not
limited to wildcard "MX" records, pose a particular problem. While
referencing the immediate parent of the Originator Domain is a top-level domain (a domain consisting allows the discovery of a single element such as "com",
"us", or "jp"), then the message is not Suspicious (because no an
SSP record was found) and the algorithm terminates. The
verifier MAY also compare the parent domain against a locally-
maintained list of known address suffixes (e.g., .co.uk) and
terminate the algorithm with a not Suspicious result if the
parent domain matches corresponding to an entry on the list.

5. The Verifier MUST query DNS for unintended immediate-child subdomain,
wildcard records apply at multiple levels. For example, if there is
a TXT wildcard "MX" record for "example.com", the immediate
parent domain, prefixed with "_ssp._domainkey." If the result
of this query is a NOERROR response with one or more answers
which are syntactically-valid SSP responses, proceed to step 6.
Otherwise, the message is not Suspicious and the algorithm
terminates.

6. If domain
"foo.bar.example.com" can receive mail through the SSP "t" tag exists in named mail
exchanger. Conversely, the response and any existence of the flags
is "s" (indicating record makes it should not apply
impossible to a subdomain), the
message tell whether "foo.bar.example.com" is a legitimate name
since a query for that name will not Suspicious and the algorithm terminates.

7. If the return an "NXDOMAIN" error. For
that reason, SSP "t" tag exists in the response and any coverage for subdomains of the flags
is "y" (indicating testing), the message domains containing a
wildcard record is not Suspicious and
the algorithm terminates.

8. If the value of the incomplete.

NON-NORMATIVE NOTE: Complete SSP "dkim" tag is "unknown", the message is
not Suspicious and the algorithm terminates.

9. If the value coverage of the SSP "dkim" tag is "all", and one or more
Verifier Acceptable Third-Party Signatures are present on the
message, the message is not Suspicious and the algorithm
terminates.

10. The message is Suspicious and the algorithm terminates.

If domains containing
(or where any of the queries involved in the Sender Signing Practices Check
result parent contains) wildcards generally cannot be
guaranteed.

6. References

6.1. Normative References

[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[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. Informative References

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.

[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006.

[RFC5016] Thomas, M., "Requirements for a SERVFAIL error response, the verifier MAY either queue
the message or return an SMTP error indicating a temporary failure.

5. IANA Considerations

IANA is requested DomainKeys Identified Mail
(DKIM) Signing Practices Protocol", RFC 5016,
October 2007.

Appendix A. Usage Examples (INFORMATIVE)

These examples are intended to create illustrate typical uses of SSP. They
are not intended to be exhaustive, nor to apply to every domain or
mail system's individual situation.

A.1. Single Location Domains

A common mail system configuration handles all of a "DKIM selector name" registry domain's users'
incoming and to
reserve outgoing mail through a single MTA or cluster of MTAs.
In that case, the selector name "_ssp" MTA(s) can be configured to avoid confusion between DKIM key
records and sign outgoing mail with
an Author Signature.

In this situation it might be appropriate to publish an SSP records.

6. Security Considerations

Security considerations in record
for the Sender Signing Practices 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
travelling users, or web sites that provide "mail an article"
features.

Domain managers are mostly
related advised to attempts on consider the part of malicious senders to represent
themselves as other senders, often ways that mail processing
can modify messages in ways that will invalidate an attempt to defraud either
the recipient existing DKIM
signature, such as mailing lists, courtesy forwarders, and other
paths that could add or modify headers, or modify the Alleged Originator.

Additional security considerations regarding Sender Signing Practices
may be found in message body.
In that case, if the modifications invalidate the DKIM threat analysis [RFC4686].

6.1. Fraudulent Sender Address

[[Assuming 3rd party signature is based on Sender header field]] If signature,
recipient MTAs will consider the Sender Signing Practices sanction third-party signing, mail not to have an
attacker can create Author
Signature, even though the signature was present when the mail was
originally sent.

A.2. Bulk Mailing Domains

Another common configuration uses a message domain solely for bulk or
broadcast mail, with no individual human users, again typically
sending all the mail through a From header field single MTA or cluster of MTAs that can
apply an
arbitrary sender and a legitimately signed Sender header field

6.2. DNS Attacks

An attacker might attack Author Signature. In this case, the DNS infrastructure 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 an attempt mailing lists, but could still send mail through other
paths that might invalidate signatures.

Domain owners often use specialist mailing providers to
impersonate SSP records. However, such an attacker is more likely send their
bulk mail. In that case, the mailing provider needs access to
attack at a higher level, e.g., redirecting A or MX record lookups
suitable signing key in order to capture traffic that was legitimately intended apply an Author Signature. One
possible route would be for the
target domain. Domains concerned about this should use DNSSEC
[RFC4033].

Because SSP operates within 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 framework of mailing provider, for example,
bigbank.example might delegate email.bigbank.example to such a
provider. In that case, the legacy e-mail
system, provider can generate the default result keys and DKIM
DNS records itself and use the subdomain in the absence of an SSP record is that Author Address in the
mail.

A.3. Bulk Mailing Domains with Discardable Mail

In some cases, a domain does not might sign all of its messages. Therefore, outgoing mail with an
Author Signature, but prefers that recipient systems discard mail
without a DNS
attack which valid Author Signature to avoid confusion from mail sent
from sources that do not apply an Author Signature. (This latter
kind of mail is successful in suppressing the sometimes loosely called "forgeries".) In that case,
it may be appropriate to publish an SSP response record containing
"discardable". Note that a domain SHOULD NOT publish a "discardable"
record if it wishes to maximize the likelihood that mail from the
verifier
domain is sufficient to delivered, since it could cause some fraction of the mail
the verifier domain sends to see unsigned messages
as non-suspicious, even when that is not intended by be discarded.

As a special case, if a domain sends no mail at all, it can safely
publish a "discardable" SSP record, since any mail with an author
address in the alleged
originating domain.

7. References

7.1. Normative References

[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.

[RFC2119] Bradner, S., "Key words for domain is a forgery.

A.4. Third Party Senders

Another common 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.

7.2. Informative References

[I-D.ietf-dkim-ssp-requirements]
Thomas, M., "Requirements case is for a DKIM Signing Practices
Protocol", draft-ietf-dkim-ssp-requirements-05 (work 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
progress), April 2007.

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., the
RFC2822 From: or other headers. Due to the many and S.
Rose, "DNS Security Introduction 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 Requirements",
RFC 4033, March 2005.

[RFC4686] Fenton, J., "Analysis other usages of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006. DKIM.

Appendix A. B. Acknowledgements

The authors wish to thank many members of the ietf-dkim mailing list,
in particular Arvel Hathcock and Eliot Lear, list
for valuable suggestions and constructive criticism of earlier
versions of this draft.

This draft incorporates content from a parallel "DKIM Author Signing
Policies" document edited by John Levine. The authors appreciate
this contribution.

Appendix B. C. Change Log

B.1.

*NOTE TO RFC EDITOR: This section may be removed upon publication of
this document as an RFC.*

C.1. Changes since -ietf-dkim-ssp-01

o Reworded introduction for clarity.

o Various definition clarifications.

o Changed names of practices to unknown, all, and discardable.

o Removed normative language mandating use of SSP in particular
situations (issue 1538).

o Clarified possible confusion over handling of syntax errors.

o Removed normative language from Introduction (issue 1538).

o Changed "Originator" to "Author" throughout (issue 1529).

o Removed all references to Third-Party Signatures (issues 1512,
1521).

o Removed all mention of "Suspicious" (issues 1528, 1530).

o Removed "t=y" (testing) flag (issue 1540).

o Removed "handling" tag (issue 1513).

o Broke up the "Sender Signing Practices Check Procedure" into two
algorithms: fetching the SSP record and interpretation thereof
(issues 1531, 1535; partially addresses issue 1520).
Interpretation is now the responsibility of the Evaluator.

o Document restructuring for better flow and remove redundancies
(some may address issue 1523, but I'm not sure I understand that
issue completely; also issues 1532, 1537).

o Removed all mention of how this interacts with users, even though
it makes parts of the document harder to understand (issue 1526).

o Introduced the concepts of "SSP Checker" and "Evaluator".

o Multiple author case now handled my separate invocations of SSP
checker by Evaluator (issue 1525).

o Removed check to avoid querying top-level domains.

o Changed ABNF use of whitespace from [FWS] to *WSP (partially
addresses issue 1543).

C.2. Changes since -ietf-dkim-ssp-00

o Clarified Operation Overview and eliminated use of Legitimate as
the counterpart of Suspicious since the words have different
meanings.

o Improved discussion (courtesy of Arvel Hathcock) of the use of TXT
records in DNS vs. a new RR type.

o Clarified publication rules for multilevel names.

o Better description of overall record syntax, in particular that
records with unknown tags are considered syntactically correct.

o Clarified Sender Signing Practices Check Procedure, primarily by
use of new term Originator Author Domain.

o Eliminated section "Third-Party Signatures and Mailing Lists" that
is better included in the DKIM overview document.

o Added "handling" tag to express alleged sending domain's
preference about handling of Suspicious messages.

o Clarified handling of SERVFAIL error in SSP check.

o Replaced "entity" with "domain", since with the removal of user-
granularity SSP, the only entities having sender signing policies
are domains.

B.2.

C.3. Changes since -allman-ssp-02

o Removed user-granularity SSP and u= tag.

o Replaced DKIMP resource record with a TXT record.

o Changed name of the primary tag from "p" to "dkim".

o Replaced lookup algorithm with one which traverses upward at most
one level.

o Added description of records which must be published, and effect
of wildcard records within the domain, on SSP.

B.3.

C.4. Changes since -allman-ssp-01

o Changed term "Sender Signing Policy" to "Sender Signing
Practices".

o Changed query methodology to use a separate DNS resource record
type, DKIMP.

o Changed tag values from SPF-like symbols to words.

o User level policies now default to that of the domain if not
specified.

o Removed the "Compliance" section since we're still not clear on
what goes here.

o Changed the "parent domain" policy to only search up one level
(assumes that subdomains will publish SSP records if appropriate).

o Added detailed description of SSP check procedure.

B.4.

C.5. Changes since -allman-ssp-00

From a "diff" perspective, the changes are extensive. Semantically,
the changes are:

o Added section on "Third-Party Signatures and Mailing Lists"

o Added "Compliance" (transferred from -base document). I'm not
clear on what needs to be done here.

o Extensive restructuring.

Authors' Addresses

Eric Allman
Sendmail, Inc.
6475 Christie Ave, Suite 350
Emeryville, CA 94608
USA

Phone: +1 510 594 5501
Email: eric+dkim@sendmail.org
URI:

Mark Delany
Yahoo! Inc.
701 First Avenue
Sunnyvale, CA 94089
USA

Phone: +1 408 349 6831
Email: markd+dkim@yahoo-inc.com
URI:

Jim Fenton
Cisco Systems, Inc.
MS SJ-9/2
170 W. Tasman Drive
San Jose, CA 95134-1706
USA

Phone: +1 408 526 5914
Email: fenton@cisco.com
URI:

Full Copyright Statement

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).