DKIM Working Group D. Otis
Internet-Draft Trend Micro, NSSG
Expires: April 13, 2007 October 10, 2006
DKIM Originating Signing Policy (DOSP)
draft-otis-dkim-dosp-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 April 13, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
DOSP (DKIM Originator's Signing Policy) is a DNS-based mechanism for
associating domain-names and asserting separate DKIM related policies
for all originating header fields and parameters found in DKIM
related messages. DOSP can associate an email-address with a list of
signing domains, and a signing domain with a list of SMTP Clients.
DOSP also provides a means to assert whether signatures are always
initial provided, whether there was an effort to protect these
signatures, and their role related to offering assurances, such as
when an identity referencing the DOSP policy is assured to be valid.
Otis Expires April 13, 2007 [Page 1]
Internet-Draft DOSP October 2006
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].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. DKIM Policy Compliance and Safe Annotations . . . . . . . . . 5
2.1. The Signing Domain . . . . . . . . . . . . . . . . . . . . 5
3. DOSP Assertions . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. (A)ll initial messages signed . . . . . . . . . . . . 9
3.2.2. (D)efault . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. (L)ocal-Part policy is published . . . . . . . . . . . 10
3.2.4. (N)ot signing . . . . . . . . . . . . . . . . . . . . 10
3.2.5. (O)nly compliant services employed . . . . . . . . . . 10
3.2.6. (T)rusted Designated Local-Parts . . . . . . . . . . . 10
3.2.7. (V)alid Designated Local-Parts . . . . . . . . . . . . 10
3.3. Designated Signing for Address . . . . . . . . . . . . . . 11
3.4. Designated Signing for Domain . . . . . . . . . . . . . . 11
3.5. Local-Part . . . . . . . . . . . . . . . . . . . . . . . . 12
3.6. Policies in Aggregate . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. DNS Example of permissive all-signed From policy . . 15
Appendix B. DNS Example of restrictive MailFrom policy . . . . . 15
Appendix C. DNS Example of permissive all-signed Sender policy . 16
Appendix D. DNS Example of restrictive EHLO policy . . . . . . . 16
Appendix E. DNS Example of permissive all-signed From with
published local-part policy . . . . . . . . . . . . . 16
Appendix F. DNS Example of restrictive From policy . . . . . . . 17
Appendix G. DNS Example of a highly restrictive From policy . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Otis Expires April 13, 2007 [Page 2]
Internet-Draft DOSP October 2006
1. Introduction
This document describes how [I-D.ietf-dkim-base] signing can be
related to all of the various originating header fields and
parameters found in DKIM related messages. DOSP better secures the
use of the email-addresses and domain-names found in message header
fields and parameters. Recommended or suggested actions for a DKIM
receiver are not included, and are considered "out-of-scope" for this
document. The receiver is assumed to better understand their
environment's impact upon the performance of DKIM signatures and how
DKIM signatures are utilized within their domain.
There are many uncertainties in respect to the actual usage of the
DKIM protocol. These uncertainties exist for the following reasons:
o Intentionally vague DKIM protocol semantics
o Full adoption of DKIM is not implied
o Limited semantics for some signing domains
o Optional validity of email-addresses
o No assumed signature ordering or signing roles
o No direct association with the SMTP Client
DOSP can assert that messages originating from a domain specified in
a specific header field or parameter are all initially signed by a
designated signing domain. DOSP can also assert that only complaint
services are subsequently used, with an intended goal of ensuring
initial signatures are not damaged or removed. The assurance of
using only compliant services may enable more stringent message
handling by a receiver.
DOSP can also assert that an email-address domain is never used.
This assertion provides a means for avoiding invalid DKIM signature
spoofing of their domain. DOSP does not make distinctions between
first-party and third-party signatures. Any designated signature is
considered equivalent to a first-party signature for the purposes of
policy evaluation. DOSP domain-name associations are only inclusive.
DOSP allows the originating domain to make assertions that indicate
when a referencing identity is valid or when a signing domain
fulfills DOSP requirements. This is accomplished by assigning roles
for various signing domains. In addition, DOSP allows signing
domains to designate SMTP Clients. By allowing signing domains to
designate SMTP Clients, anti-replay mechanisms can be by-passed for
these SMTP Clients.
Otis Expires April 13, 2007 [Page 3]
Internet-Draft DOSP October 2006
The goal of DOSP is to:
o Fully enumerate signing practices for all originating domains
o Facilitate associations with all other domains
o Simplify steps for establishing a comprehensive DKIM policy
o Accommodate all practical deployment strategies
o Provide a means to assure email-addresses and sources
A message signed with DKIM, whether or not there is also a referenced
policy, does not indicate when a message is from a good or bad actor.
However, DKIM signatures will allow a recipient's trust to be
strengthened. Good actors establish trust. Bad actors do not.
Trust is an essential prerequisite. The DKIM signature header
field's 'i=' semantics or the DOSP assertions regarding the validity
of related identities provide valuable advisory information. This
advisory information allows the safer application of message
annotations for ensuring trusted identities are properly recognized.
Policy assertions convey which domains are authoritative and are able
to assure valid identifiers. This information is essential for the
proper recognition of valid email-addresses of trusted identities, as
well as noting when a message source may require added scrutiny.
The goal of DOSP is to incorporate a full range of possible signing
practices. The main objective of DOSP is to establish a basis for
evaluating all originating domains and their related email-addresses.
As should be expected, DOSP assertions are only assurances of the
message's initial state. Blocking messages from non-designated
sources or that have invalid signatures will not provide sufficient
protection, and is also likely to disrupt message delivery in many
cases. Senders may become frustrated by delivery problems, while
recipients still remain exposed to look-alike or "cousin" domain
spoofing, and will be easily misled when only a display-name is
initially seen.
For an email-address to be considered valid, it must be signed by
either a matching or a designated domain. In addition, this email-
address MUST be either:
o fully included within the signature header field 'i=' parameter
o signed by a domain with a role of signing valid email-addresses
o containing a local-part asserted as being valid
Even when an email-address is assured to be valid by one of these
mechanisms, it is not reasonable to consider all email-addresses from
a domain to represent equally trustworthy identities or that all
follow the same practices.
For the purposes of annotating messages based upon a trusted domain,
Otis Expires April 13, 2007 [Page 4]
Internet-Draft DOSP October 2006
local-part designations permit a domain to indicate which identities
are trustworthy from their perspective. The recipient must determine
independently, through various out-of-band methods, which domains or
identities should be considered trustworthy. When trust is based
upon a domain-name rather than a specific email-address, message
annotations should differ, and should be constrained to those
identities asserted as trustworthy in DOSP local-part policies.
2. DKIM Policy Compliance and Safe Annotations
DKIM allows a signing domain to selectively protect portions of a
message from modification and to selectively vouch for the validity
of an email-address when fully contained within the DKIM Signature
header field's 'i=' parameter. Neither this document or [I-D.ietf-
dkim-base] prescribe specific actions for receivers to take upon
completion of signature validation and policy conformance
assessments. While this document allows all originating domains a
means to succinctly assert domain associations and signing practices,
it does not advise how messages are to be handled.
While the DKIM protocol offers a verified signing domain, by design
signing domains remain unseen by the recipient. Message annotations
are required before recipients benefit substantially from DKIM
protections. Annotations of assured and trusted email-addresses may
entail placement into various folders or the addition of distinctive
markings. As with message handling in general, this document also
does not define how message annotations might be accomplished.
DKIM is fully independent of the SMTP Client and the
[RFC2821].MailFrom email-address. Allowing the [RFC2821].MailFrom
email-address to designate signing domains and assert signing
practices may prevent Delivery Status Notifications (DSNs) from being
sent when the email-address is forged. Allowing the signing domain
to designate SMTP Clients may allow receivers to circumvent
mechanisms guarding against possible message replay abuse. These two
policies represent entirely optional protection strategies that may
or may not prove either effective or practical. These are offered
only to allow for experimentation.
2.1. The Signing Domain
Unlike IPv4 addresses, there is virtually no limit on the number of
domain-names available. Registrar pricing of domain-names should
remain uniform, otherwise higher fees based upon an intrinsic value
established by the owner may cause them to become extortion targets.
Fees could be added under a guise of being incurred due to poor email
administration, for example. Initial costs for domain-names are
Otis Expires April 13, 2007 [Page 5]
Internet-Draft DOSP October 2006
unlikely to represent a deterrent, and it is unlikely registrars will
be able to fairly withdraw domain-names due to unsolicited bulk email
practices.
In addition, DKIM can not directly identify the domain transmitting
the message, and can not prevent abusive message replay. Abusive
message replay may prove indistinguishable from bulk mailings of
various types. As a result, message acceptance will likely remain
based primarily upon the IP address of the SMTP Client. Abuse
reporting facilitated by a DKIM signature should therefore correspond
with the domain administering the SMTP Client publicly transmitting
the message.
When the signing domain differs from that of the domain within the
originating email-address, DOSP offers a simple solution for email-
address policy compliance. Just as a DKIM signature can assert an
email-address is valid, a signing domain that only signs validated
email-addresses can be designated as playing the role of providing
valid email-addresses. This assertion remains valid even when
signing domains and the email-address domains differ.
A domain can be designated as providing just valid signatures. This
designated role can fulfill an assertion all email-addresses are
signed without also assuring these email-addresses are valid. While
this latter role of only offering valid signatures will not ensure
all possible spoofing is prevented, these messages should not receive
annotations indicating any assurances either. This role represents
an economical alternative enabling large scale autonomous
administration of domain associations. Designating domains that play
the role of only providing valid signatures may be suitable for non-
critical messages, where the goal may be to only improve delivery
acceptance.
When the originating email-address domain differs from that of a
provider's DKIM signing domains, DNS delegation or key exchanges are
required before these domains can match. The provider would need to
sign with the customer's key for messages sent using their account.
DNS delegations or private key exchanges will likely involve a
significant amount of detail, such as key selectors, user
limitations, suitable services, key resource record's Time-To-Live,
revocation and update procedures, and whether the DKIM Signature
header field's 'i=' semantics should be applied as indicating valid
email-addresses.
This DNS delegation effort will likely involve the sharing of these
details between the email provider, the domain owner, and the DNS
provider. As there are many ways in which this could be
accomplished, it is also unlikely for there to be consistent or
Otis Expires April 13, 2007 [Page 6]
Internet-Draft DOSP October 2006
standardized formats for exchanging this information. In addition,
when there are any security breaches, the domain owner might be held
accountable for message content that was never seen or logged by
them.
Protections offered by DKIM are largely related to the better
recognition of prior correspondents, and improved identification of
initial sources when instances of abuse are reported. While DOSP may
allow the receiver to detect and reject messages that appear non-
compliant, the overall cases where this might happen are likely to
represent a fairly small portion of the overall messages. When the
receiver seeks to protect the DKIM verification process with a
preliminary message filter, even acquiring DOSP policy records or
DKIM keys may inadvertently leak valuable information benefiting
abusive senders. The validation of DKIM and the obtaining of DOSP
resource records may consequently become limited to known trustworthy
domains.
3. DOSP Assertions
Syntax descriptions use the form described in Augmented BNF for
Syntax Specifications [RFC4234]. The "base32" function is defined in
[RFC3548] and the "sha-1" hash function is defined in [FIPS.180-
2.2002]. The function "lcase" converts upper-case ALPHA characters
to lower-case. The terminating period is not included in domain-name
conversions.
asterisk = %x2A ; "*"
plus = %x2B ; "+"
hyphen = %x2D ; "-"
period = %x2E ; "."
colon = %x3A ; ":"
semicolon = %x3B ; ";"
equals = %x3D ; "="
underscore = %x5F ; "_"
ldh = ALPHA / DIGIT / hyphen ;
let-dig = ALPHA | DIGIT ;
subdomain = let-dig [*61(ldh) let-dig] ;
domain = subdomain 1*(period subdomain) ;
ANY = asterisk period ; "*."
FWS = ([*WSP CRLF] 1*WSP) ;
ALNUMPUNC = ALPHA / DIGIT / underscore ;
Otis Expires April 13, 2007 [Page 7]
Internet-Draft DOSP October 2006
VALCHAR = %x21-3A / %x3C-7E ; "!" to "~" except ";"
UTF8-VAL = VALCHAR / UTF8-2 / UTF8-3 / UTF8-4 ;
UTF8-X = %x80-BF ;
UTF8-2 = %xC2-DF UTF8-X ;
UTF8-3 = %xE0 %xA0-BF UTF8-X / %xE1-EC 2(UTF8-X) /
%xED %x80-9F UTF8-X / %xEE-EF 2(UTF8-X) ;
UTF8-4 = %xF0 %x90-BF 2(UTF8-X) / %xF1-F3 3(UTF8-X) /
%xF4 %x80-8F 2(UTF8-X) ;
tag-value = [1*UTF8-VAL 0*( 1*(WSP / FWS) 1*UTF8-VAL)] ;
tag-list = tag-spec 0*(semicolon tag-spec)[semicolon] ;
tag-spec = [FWS] tag-name [FWS] equals [FWS] tag-value [FWS] ;
tag-name = ALPHA 0*ALNUMPUNC ;
From = "F" ; [RFC2822].From
Originator = "O" ; [RFC2822].Sender/Resent-Sender/Resent-From
MailFrom = "M" ; [RFC2821].MAIL FROM
Ehlo = "E" ; [RFC2821].EHLO
LocalPart = "L" ; left-hand side of email-address
sig-policy = (From / Originator / MailFrom) ;
sig-label = base32( sha-1( lcase(signing-domain))) ; 32 characters
lp-policy = LocalPart (From / Originator) ;
lp-label = base32( sha-1(local-part)) ; 32 characters
ehlo-policy = Ehlo ;
ehlo-label = base32( sha-1( lcase(ehlo-domain))) ; 32 characters
+-----+--------------------------------+
| Tag | Function |
+-----+--------------------------------+
| v= | Version |
| f= | Flags |
| a= | Designated Signing for Address |
| d= | Designated Signing for Domain |
| l= | Designated Local-Part |
+-----+--------------------------------+
+------+---------------------------------------------+
| Flag | Function |
+------+---------------------------------------------+
| A | All initial messages signed |
| D | Default |
| L | Local-Part policies are published |
| N | Not signing |
| O | Only compliant subsequent services employed |
| T | Trusted Designated Local-Part |
| V | Valid Designated Local-Part |
+------+---------------------------------------------+
Otis Expires April 13, 2007 [Page 8]
Internet-Draft DOSP October 2006
The receiver obtains the DOSP email-address domain policy using a DNS
query for an IN class TXT resource record. The character-strings
contained within the TXT resource record are concatenated into
forming a single string. A character-string is a single length octet
followed by that number of characters treated as binary information.
Entering UTF-8 characters may require an escape sequence using the
"\DDD" decimal syntax. The content of this concatenated string is
UTF-8 encoded per [RFC3629] and contains a tag-list based upon the
ABNF format defined within this section. Unrecognized tags MUST be
ignored. A policy record may be located at these domains:
<sig-label>._DKIM-<sig-policy>.<email-address domain>.
<lp-label>._DKIM-<lp-policy>.<email-address domain>.
<ehlo-label>._DKIM-<ehlo-policy>.<signing domain>.
Policies accessed with "lp-labels" should not include any designated
domains.
3.1. Version
v= Version (MUST be included). This tag defines the version of this
specification that applies to the signature record. It MUST have the
value 0.0.
Version = %x76 [FWS] equals [FWS] "0.0"
INFORMATIVE NOTE: DKIM-Signature version numbers are expected to
increase arithmetically as new versions of this specification are
released.
[INFORMATIVE NOTE: Upon publication, this version number should be
changed to "1", and this note should be delete.]
3.2. Flags
f= Flags (Optional). This tag defines a list of flags that assert
various aspects of the email-address domain signing policy.
flag = %x41 / %x44 / %x4C/ %x4E / %x4F / %x54 / %x56 ;
"A", "D", "L", "N", "O", "T", & "V"
Flags =%x66 [FWS] equals [FWS] flag 0*(*FWS colon *FWS flag)
3.2.1. (A)ll initial messages signed
This "A" flag asserts that messages carrying the email-address domain
within the relevant header field or parameter are all initially
signed by a designated domain.
Otis Expires April 13, 2007 [Page 9]
Internet-Draft DOSP October 2006
3.2.2. (D)efault
This "D" flag asserts that this policy represents a default value.
When the reference used to obtain the policy can not be confirmed, a
subsequent query at the "_default" label is not required.
3.2.3. (L)ocal-Part policy is published
This "L" flag asserts that local-part policy is published for the
corresponding message header field. For example when a policy is
published at <sig-label>._DKIM-F.<email-address domain> that has the
"L" flag asserted, then local-part policy can be found at <lp-
label>._DKIM-LF.<email-address domain>. This flag is not valid in
Ehlo and MailFrom records.
3.2.4. (N)ot signing
This "N" flag asserts that messages carrying the email-address domain
within the relevant header field or parameter are not initially
signed. This assertion might be suitable as a means to prevent or
terminate a policy record search, and to assure that no signatures
are generated by this domain as a means to prevent invalid signature
spoofing.
3.2.5. (O)nly compliant services employed
This "O" flag asserts that messages carrying the email-address domain
within the relevant header field or parameter are not subsequently
used in conjunction with services that may either damage or remove
the initial signature. This assertion might be suitable for domains
willing to forego the use of many common services where signatures
might be damaged, for example.
3.2.6. (T)rusted Designated Local-Parts
This "T" flag asserts that messages carrying the email-address
containing a designated local-part found in the 'l=' tag local-part
list are considered trustworthy by the email-address domain. This
flag is not valid in Ehlo and MailFrom records.
3.2.7. (V)alid Designated Local-Parts
This "V" flag asserts that messages carrying the email-address
containing a designated local-part found in the 'l=' tag local-part
list are considered to be valid by the email-address domain. This
flag is not valid in Ehlo and MailFrom records.
Otis Expires April 13, 2007 [Page 10]
Internet-Draft DOSP October 2006
3.3. Designated Signing for Address
a= Designated Signing for Address (Optional). This list defines
domains considered to be the equivalent of the respective email-
address domain for the purpose of assessing policy. These domains
play the role of providing valid email-addresses. When a domain is
prefixed with the "*." wildcard label, then all subdomains of this
domain are considered to be included in the list. The wildcard label
used in the list allows a common resource record to be shared by
multiple "sig-label" references.
It is possible for a signing domain to be at a higher level than the
respective email-address domain and not be designated. When the
signing domain is not specifically listed within either designated
signing domain lists (a= & d=), no policy related assurances are
made. When the signing domain used to generate the "sig-label" is
not found in either list, and the "D" flag is not asserted, the
policy should be obtained by replacing the "sig-label" with
"_default" instead. In practice, this step should rarely be needed.
This list is not valid in Ehlo and MailFrom records.
dsa = [ANY] domain 0*(*FWS colon *FWS [ANY] domain)
dsa-list = %x61 [FWS] equals [FWS] dsa
3.4. Designated Signing for Domain
d= Designated Signing for Address (Optional). This list defines
domains considered to be the equivalent of the respective email-
address domain for the purpose of assessing policy. These domains do
not play the role of providing valid email-addresses. These domains
only provide valid signatures for the purpose of assessing signing
compliance. This list also confirms SMTP Client domains in Ehlo
records. When a domain is prefixed with the "*." wildcard label,
then all subdomains of this domain are considered to be included in
the list. The wildcard label used in the list allows a common
resource record to be shared by multiple "sig-label" or "ehlo-label"
references.
It is possible for a signing domain to be at a higher level than the
respective email-address domain and not be designated. When the
signing domain is not specifically listed within either designated
signing domain lists (a= & d=), no policy related assurances are
made. When the ehlo-domain or signing domain used to generate the
"ehlo-label" or "sig-label" respectively is not found in a list, and
the "D" flag is not asserted, the policy should be obtained by
replacing the "ehlo-label" or "sig-label" with "_default" instead.
In practice, this step should rarely be needed.
Otis Expires April 13, 2007 [Page 11]
Internet-Draft DOSP October 2006
dsd = [ANY] domain 0*(*FWS colon *FWS [ANY] domain)
dsd-list = %x64 [FWS] equals [FWS] dsd
3.5. Local-Part
l= Local-Part policy published (Optional). This tag lists designated
local-parts for which policy is being published. The "(T)rusted
Designated Local-Parts" and the "(V)alid Designated Local-Parts"
flags only apply when the local-part has been confirmed by the "l="
list. It is expected that it might be common for only a few email-
addresses to warrant special handling where publishing separate
local-part policies can be avoided. When the local-part used to
generate the "lp-label" referencing the policy is not found in this
list, and the "D" flag is not asserted, the policy should be obtained
by replacing the "lp-label" with "_default" instead. In practice,
this step should rarely be needed. This list is not valid in Ehlo
and MailFrom records.
lp = [ANY] local-part 0*(*FWS colon *FWS [ANY] local-part)
lp-list = %x6C [FWS] equals [FWS] lp
3.6. Policies in Aggregate
o The default policy assumed is the same as when no optional fields
are entered in the DOSP records. This default policy makes no
assurance about whether all initial messages have been signed and
does not include any additional domain associations.
o When a policy flag is asserted, it may be necessary to list the
respective email-address domains in either the "Designated Signing
for Address" (a=) or "Designated Signing for Domain" (d=) list.
o Listing the email-address domain in the "Designated Signing for
Domain" list does not alter the DKIM signature header field's 'i='
semantics. The email-address should not be considered valid
unless indicated as such by the "i=" semantics, or when the local-
part is asserted as valid.
o When the "Designated Signing for Domain" (d=) list applies in the
case of the of [RFC2821].MailFrom parameter, this is indicative of
a valid signature satisfying a possibly asserted "(A)ll initial
messages signed" flag.
o When both the "Designated Signing for Address" (a=) and
"Designated Signing for Domain" (d=) list are empty, and the
"(A)ll initial messages signed" flag is asserted, this then means
Otis Expires April 13, 2007 [Page 12]
Internet-Draft DOSP October 2006
that no mail containing the referencing identifier originates from
this domain.
o A domain that ensures that all messages are initially signed, and
attempts to ensure that their users employ only complaint
services, may indicate this extraordinary effort by asserting both
the "(A)ll initial messages signed" and the "(O)nly compliant
services employed" flags. This combination of flags could be
helpful in overcoming phishing attempts without negatively
affecting domains that assert just the "(A)ll initial messages
signed" flag.
o Future flags may make use of the "+" symbol to indicate a logical
OR of related assertions. The current ":" flag separator can be
considered to represent a logical AND of related assertions.
4. IANA Considerations
This document may wish IANA to reserve the use of the "_DKIM-F",
"_DKIM-LF", "_DKIM-O", "_DKIM-LO", "_DKIM-M", and "_DKIM-E" domain-
name label.
Note to RFC Editor: this section may be removed on publication as an
RFC and no request is desired or registration is not considered
practical.
5. Security Considerations
This draft defines signing policies related to [I-D.ietf-dkim-base].
There is no expectation this policy information is from an
authenticated source. Network resources expended to acquire this
information should be proportional to that needed to verify the
signature. Strategies used by the receiver to limit possible
amplifications that might occur with signature verification should
also limit the impact of obtaining this information.
The use of the SHA-1 hash algorithm does not represent a security
concern. The hash simply ensures a deterministic domain-name size is
achieved. Unexpected collisions can be detected and handled by using
a default value.
Otis Expires April 13, 2007 [Page 13]
Internet-Draft DOSP October 2006
6. Acknowledgements
Hector Santos, and Frank Ellermann.
7. References
7.1. Normative References
[FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http://
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.
[I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", draft-ietf-dkim-base-05 (work in progress),
August 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
7.2. Informative References
[I-D.ietf-dkim-overview]
Hansen, T., "DomainKeys Identified Mail (DKIM) Service
Overview", draft-ietf-dkim-overview-01 (work in progress),
June 2006.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Otis Expires April 13, 2007 [Page 14]
Internet-Draft DOSP October 2006
Identified Mail (DKIM)", RFC 4686, September 2006.
Appendix A. DNS Example of permissive all-signed From policy
####
# Policies for Example.com email domain using example.com, isp.com,
# and example.com.isp.com as signing domains.
####
#### 2822.From policy ####
*._DKIM-F.example.com. IN TXT
"v=0.0; a=example.com; f=A:D;"
## "example.com" sig-label ##
s5qs7wwt62yx6yowseuzjntou633vtez._DKIM-F.example.com. IN TXT
"v=0.0; a=example.com; f=A:T;"
"l=admin:accounts:sales:do-not-reply:MAILER-DEAMON;"
## "isp.com" sig-label ##
hgssd3snmi6635j5743vdjhajkmpmfif._DKIM-F.example.com. IN TXT
"v=0.0; d=isp.com; f=A:T:V;"
"l=admin:accounts:sales:do-not-reply:MAILER-DEAMON;"
## "example.com.isp.com" sig-label ##
zzhffxwcfi7rpddqdigyhpbtaa7vwitu._DKIM-F.example.com. IN TXT
"v=0.0; a=example.com.isp.com; f=A:T:V;"
"l=admin:accounts:sales:do-not-reply:MAILER-DEAMON;
Appendix B. DNS Example of restrictive MailFrom policy
#### 2821.MailFrom policy ####
*._DKIM-M.example.com. IN TXT
"v=0.0; f=A:D;"
## "example.com" sig-label ##
s5qs7wwt62yx6yowseuzjntou633vtez._DKIM-M.example.com. IN TXT
"v=0.0; a=example.com; f=A;"
## "isp.com" sig-label ##
hgssd3snmi6635j5743vdjhajkmpmfif._DKIM-M.example.com. IN TXT
"v=0.0; d=isp.com; f=A;"
## "example.com.isp.com" sig-label ##
zzhffxwcfi7rpddqdigyhpbtaa7vwitu._DKIM-M.example.com. IN TXT
"v=0.0; d=example.com.isp.com; f=A;"
Otis Expires April 13, 2007 [Page 15]
Internet-Draft DOSP October 2006
Appendix C. DNS Example of permissive all-signed Sender policy
#### 2822.Sender policy #####
*._DKIM-O.example.com. IN TXT
"v=0.0; a=example.com; f=A:D;"
## "example.com" sig-label ##
s5qs7wwt62yx6yowseuzjntou633vtez._DKIM-O.example.com. IN TXT
"v=0.0; a=example.com; f=A;"
## "isp.com" sig-label ##
hgssd3snmi6635j5743vdjhajkmpmfif._DKIM-O.example.com. IN TXT
"v=0.0; a=isp.com; f=A;"
Appendix D. DNS Example of restrictive EHLO policy
#### 2821.EHLO policy #####
*._DKIM-E.example.com. IN TXT
"v=0.0; d=*.example.com; f=A:D;"
## "mx-01.example.com" ehlo-label (redundant) ##
inkzgjwvtenf4zjexukzo4qknqhgwee6._DKIM-E.example.com. IN TXT
"v=0.0; d=*.example.com; f=A;"
## EHLO host-name ##
mx-01.example.com. IN A
10.1.1.1
Appendix E. DNS Example of permissive all-signed From with published
local-part policy
#### 2822.From policy ####
*._DKIM-F.example.com. IN TXT
"v=0.0; a=example.com; f=A:D;"
## "example.com" sig-label ##
s5qs7wwt62yx6yowseuzjntou633vtez._DKIM-F.example.com. IN TXT
"v=0.0; a=example.com; f=A:L;"
*._DKIM-LF.example.com. IN TXT
"v=0.0; f=D;"
## "admin" lp-label ##
iak3zhxjdzbx3eg7qp5wj656gewzzhyf._DKIM-LF.example.com. IN TXT
"v=0.0; f=T:V; l=admin;"
Otis Expires April 13, 2007 [Page 16]
Internet-Draft DOSP October 2006
Appendix F. DNS Example of restrictive From policy
#### 2822.From policy ####
*._DKIM-F.example.com. IN TXT
"v=0.0; a=example.com; f=A:D:O;"
## "example.com" sig-label ##
s5qs7wwt62yx6yowseuzjntou633vtez._DKIM-F.example.com. IN TXT
"v=0.0; a=example.com; f=A:O:T;"
"l=admin:accounts:sales:do-not-reply:MAILER-DEAMON;"
Appendix G. DNS Example of a highly restrictive From policy
# This policy indicates all other domains are not valid
#### 2822.From policy ####
*._DKIM-F.example.com. IN TXT
"v=0.0; f=A:D:O;"
## "example.com" sig-label ##
s5qs7wwt62yx6yowseuzjntou633vtez._DKIM-F.example.com. IN TXT
"v=0.0; a=example.com; f=A:O:T;"
"l=admin:accounts:sales:do-not-reply:MAILER-DEAMON;"
Otis Expires April 13, 2007 [Page 17]
Internet-Draft DOSP October 2006
Author's Address
Douglas Otis
Trend Micro, NSSG
1737 North First Street, Suite 680
San Jose, CA 95112
USA
Phone: +1.408.453.6277
Email: doug_otis@trendmicro.com
Otis Expires April 13, 2007 [Page 18]
Internet-Draft DOSP October 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Otis Expires April 13, 2007 [Page 19]