DKIM Working Group M. Thomas
Internet-Draft Cisco Systems
Intended status: Informational April 23, 2007
Expires: October 25, 2007
Requirements for a DKIM Signing Practices Protocol
draft-ietf-dkim-ssp-requirements-04
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 October 25, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Thomas Expires October 25, 2007 [Page 1]
Internet-Draft DKIM-SSP-REQ April 2007
Abstract
DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism
for domains to assert responsibility for the messages they handle. A
related mechanism will allow an administrator to publish various
statements about their DKIM signing practices. This document defines
requirements for this mechanism, distinguishing between those that
must be satisified (MUST), and those that are highly desirable
(SHOULD).
Thomas Expires October 25, 2007 [Page 2]
Internet-Draft DKIM-SSP-REQ April 2007
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 RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. SSP Problem Scenarios . . . . . . . . . . . . . . . . . . . . 7
3.1. Problem Scenario 1: Is All Mail Signed with DKIM? . . . . 7
3.2. Problem Scenario 2: Illegitimate Domain Name Use . . . . . 8
4. SSP Deployment Considerations . . . . . . . . . . . . . . . . 10
4.1. Deployment Consideration 1: Outsourced Signing . . . . . . 10
4.2. Deployment Consideration 2: Subdomain Coverage . . . . . . 10
4.3. Deployment Consideration 3: Resent Original Mail . . . . . 10
4.4. Deployment Consideration 4: Incremental Deployment of
Signing . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Deployment Consideration 5: Performance and Caching . . . 11
4.6. Deployment Consideration 6: Human Legibility of
Practices . . . . . . . . . . . . . . . . . . . . . . . . 12
4.7. Deployment Consideration 7: Extensibility . . . . . . . . 12
4.8. Deployment Consideration 8: Security . . . . . . . . . . . 12
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Discovery Requirements . . . . . . . . . . . . . . . . . . 13
5.2. SSP Transport Requirements . . . . . . . . . . . . . . . . 14
5.3. Practice and Expectation Requirements . . . . . . . . . . 14
5.4. Extensibility and Forward Compatibility Requirements . . . 16
6. Security Requirements . . . . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23
Thomas Expires October 25, 2007 [Page 3]
Internet-Draft DKIM-SSP-REQ April 2007
Intellectual Property and Copyright Statements . . . . . . . . . . 24
Thomas Expires October 25, 2007 [Page 4]
Internet-Draft DKIM-SSP-REQ April 2007
1. Introduction
DomainKeys Identified Mail [I-D.ietf-dkim-base]defines a message
level signing and verification mechanism for email. While a DKIM
signed message speaks for itself, there is ambiguity if a message
doesn't have a valid first party signature (ie, on behalf of the
RFC2822.From address): is this to be expected or not? For email this
is an especially difficult problem since there is no expectation of a
priori knowledge of a sending domain's practices. This ambiguity can
be used to mount a bid down attack which is inherent with systems
that allow optional authentication like email: if a receiver doesn't
know otherwise, it should not assume that the lack of a valid
signature is exceptional without other information. Thus, an
attacker can take advantage of the ambiguity and simply not sign
messages. If a protocol could be developed for a domain to publish
its DKIM signing practices, a message verifier could take that into
account when it receives an unsigned piece of email.
This document defines the requirements for a mechanism that permits
the publication of Sender Signing Practices (SSP). The document is
organized into two main sections: a Problem and Deployment Scenario
section which describes the problems that SSP is intended to address
as well as the deployment issues surrounding the base problems. The
second section is the Requirements that arise because of those
scenarios.
Thomas Expires October 25, 2007 [Page 5]
Internet-Draft DKIM-SSP-REQ April 2007
2. Definitions
o Domain Holder: the entity that controls the contents of the DNS
subtree starting at the domain, either directly or by delegation
via NS records it controls.
o First Party Address: For DKIM, a first party address is defined to
be the [RFC2822].From address in the message header; a first party
address is also known as an Author address
o First Party Signature: a first party signature is a valid
signature where the domain tag (d= or the more specific identity
i= tag) matches the first party address. "Matches" in this
context is defined in [I-D.ietf-dkim-base]
o Third Party Signature: a third party signature is a valid
signature that does not qualify as a First Party Signature. Note
that a DKIM third party signature is not required to correspond to
a third party address such as Sender or List-Id, etc.
o Practice: a statement according to the [RFC2822].From domain
holder of externally verifiable behavior in the email messages it
sends. A practice should always be true when received by a
topologically adjacent SMTP server.
o Expectation: an Expectation combines with a Practice to convey
what the domain holder considers the likely survivability of the
Practice for a non-topologically adjacent receiver.
o DKIM Signing Complete: a Practice where the domain holder asserts
that all legitimate mail will be sent with a valid First Party
Signature.
Thomas Expires October 25, 2007 [Page 6]
Internet-Draft DKIM-SSP-REQ April 2007
3. SSP Problem Scenarios
The email world is a diverse place with many deployment
considerations. This section tries to outline some usage scenarios
that it is expected that DKIM signing/verifying will take place in,
and how a new protocol might be helpful to clarify the relevance of
DKIM signed mail.
3.1. Problem Scenario 1: Is All Mail Signed with DKIM?
After auditing their outgoing mail and deploying DKIM signing for all
of their legitimate outgoing mail, a domain could be said to be DKIM
signing complete. That is, the domain has to the best of its ability
ensured that all legitimate mail purporting to have come from that
domain contains a valid DKIM signature.
A receiver in the general case doesn't know what the practices are
for a given domain. Thus the receiver is at a disadvantage in that
it does not know if it should expect all mail to be signed from a
given domain or not. This knowledge gap leads to a trivially
exploitable bid-down attack where the attacker merely sends unsigned
mail; since the receiver doesn't know the practices of the signing
domain, it cannot treat the message any more harshly for lack of a
valid signature.
An information service which allows a receiver to query for the
practices and expectations of the first party domain when no valid
first party signature is found could be useful in closing this gap.
A receiver could use this information to treat such questionable mail
with varying degrees of prejudice.
Note that for the foreseeable future, unrestricted use patterns of
mail (eg where users may be members of mailing lists, etc) will
likely suffer occasional non-malicious signature failure in transit.
While probably not a large percentage of total traffic, the kind of
breakage may be a significant concern for those usage patterns. This
scenario defines where the sender cannot set any expectation as to
whether an individual message will arrive intact.
Even without that expectation, a receiver may be able to take
advantage of the knowledge that the domain's practice is to sign all
mail and bias its filters against unsigned or damaged in transit
mail. This information should not be expected to be used in a binary
yes/no fashion, but instead as a data point among others in a
filtering system.
The following exchange illustrates problem scenario 1.
Thomas Expires October 25, 2007 [Page 7]
Internet-Draft DKIM-SSP-REQ April 2007
1. Mail with a [RFC2822].From A sends to B with a missing or broken
DKIM first party signature from A
2. B would like to know whether that is an expected state of
affairs.
3. A provides information that it signs all outgoing mail, but
places no expectation on whether it will arrive with an intact
first party signature.
4. B could use this information to bias its filters to examines the
message with some suspicion.
3.2. Problem Scenario 2: Illegitimate Domain Name Use
A class of mail typified by transactional mail from high value
domains is the target of phishing attacks. In particular, many
phishing scams forge the [RFC2822].From address in addition to
spoofing much of the content to trick unsuspecting users into
revealing sensitive information. Domain holders sending this kind of
mail would like the ability to give an enhanced guarantee that mail
sent in their name should always arrive with the proof that the
domain holder consented to its transmission. That is, the message
should contain a valid first party signature as defined above.
From a receiver's standpoint, knowing that a domain not only signs
all of its mail, but places a very high value on the receipt of a
valid first party signature from that domain is helpful. Hence a
receiver can know that the domain not only signs all of its mail, but
also feels it essential that legitimate mail must have its first
party signatures survive transit. A receiver with the knowledge of
the sender's expectations in hand might choose to process messages
not conforming to the published practices in a special manner. Note
that the ability to state an enhanced guarantee of a valid signature
means that senders should expect mail that traverses modifying
intermediaries (eg, mailing lists, etc) will be likely be quarantined
or deleted, thus this scenario is more narrow than problem scenario
1.
[Informative Note: in terms of a receiving filter, one may choose
to treat scenario 2 much more harshly than scenario 1; where
scenario 1 looks odd, scenario 2 looks like something is very
wrong]
1. Mail with a [RFC2822].From A purportedly sends to B with a
missing or broken first party DKIM signature from A
Thomas Expires October 25, 2007 [Page 8]
Internet-Draft DKIM-SSP-REQ April 2007
2. B would like to know whether that is an expected state of
affairs.
3. A provides information that it signs all outgoing mail, but
places an expectation that it should arrive with an intact first
party signature, and that the receiver should be much more wary
if it does not.
4. B could use this information to bias its filters such that it
examines the message with great suspicion.
Thomas Expires October 25, 2007 [Page 9]
Internet-Draft DKIM-SSP-REQ April 2007
4. SSP Deployment Considerations
Given the problems enumerated above for which we'd like SSP to
provide information to recipients, there are a number of scenarios
that are not related to the problems that are to be solved, per se,
but the actual mechanics of implementing/deploying the information
service that SSP would provide.
4.1. Deployment Consideration 1: Outsourced Signing
Many domains do not run their own mail infrastructure, or may
outsource parts of it to third parties. It is desirable for a domain
holder to have the ability delegate to other entities the ability to
sign for the domain holder. One obvious use scenario is a domain
holder from a small domain that needs to have the ability for their
outgoing ISP to sign all of their mail on behalf of the domain
holder. Other use scenarios include outsourced bulk mail for
marketing campaigns, as well as outsourcing various business
functions such as insurance benefits, etc.
4.2. Deployment Consideration 2: Subdomain Coverage
A SSP client will perform lookups on incoming mail streams to provide
the information as proposed in the problem scenarios. The domain
part of the first address of the RFC2822.From will form the basis to
fetch the published information. A trivial attack to circumvent
finding the published information can be mounted by simply using a
subdomain of the parent domain which doesn't have published
information. This attack is called the subdomain attack: that is, a
domain wants to not only publish a policy for a given DNS label it
controls, but it would also like to protect all subdomains of that
label as well. If this characteristic is not met, an attacker would
need only create a possibly fictitious subdomain that was not covered
by SSP's information service. Thus, it would be advantageous for SSP
to not only cover a given domain, but all subdomains of that domain
as well.
4.3. Deployment Consideration 3: Resent Original Mail
Resent mail is a common occurrence in many scenarios in the email
world of today. For example, Alice sends a DKIM signed message with
a published practice of signing all messages to Bob's mailing list.
Bob, being a good net citizen, wants to be able to take his part of
the responsibility of the message in question, so he DKIM signs the
message, perhaps corresponding to the Sender address.
Note that this scenario is completely orthogonal to whether Alice's
signature survived Bob's mailing list: Bob merely wants to assert his
Thomas Expires October 25, 2007 [Page 10]
Internet-Draft DKIM-SSP-REQ April 2007
part in the chain of accountability for the benefit of the ultimate
receivers. It would be useful for this practice to be encouraged as
it gives a more accurate view of who handled the message. It also
has the side benefit that remailers that are not friendly to DKIM
first party signatures (ie, break them) can be potentially assessed
by the receiver based on the receiver's opinion of the signing
domains that actually survived.
4.4. Deployment Consideration 4: Incremental Deployment of Signing
As a practical matter, it may be difficult for a domain to roll out
DKIM signing such that they can publish the DKIM Signing Complete
practice given the complexities of the user population, outsourced
vendors sending on its behalf, etc. This leaves open an exploit that
high-value mail such as in Problem Scenario 2 must be classified to
the least common denominator of the published practices. It would be
desirable to allow a domain holder to publish a list of exceptions
which would have a more restrictive practices statement. NB: this
consideration has been deemed met by the mechanisms provided by the
base DKIM signing mechanism; it is merely documented here as having
been an issue.
For example, bigbank.example.com might be ready to say that
statements@bigbank.example.com is always signed, but the rest of the
domain, say, is not. Another situation is that the practices of some
address local parts in a given domain are not the same as practices
of other local parts. Using the same example of
statements@bigbank.example.com being a transactional kind of email
which would like to publish very strong practices, mixed in with the
rest of the user population local parts which may go through mailing
lists, etc, for which a less strong statement is appropriate.
It should be said that DKIM, through the use of subdomains, can
already support this kind of differentiation. That is, in order to
publish a strong practice, one only has to segregate those cases into
different subdomains. For example: accounts.bigbank.example.com
would publish constrained practices while
corporateusers.bigbank.example.com might publish more permissive
practices.
4.5. Deployment Consideration 5: Performance and Caching
Email service provides an any-any mesh of potential connections: all
that is required is the publication of an MX record and a SMTP
listener to receive mail. Thus the use of SSP is likely to fall into
two main scenarios, the first of which are large, well known domains
who are in constant contact with one another. In this case caching
of records is essential for performance, including the caching of the
Thomas Expires October 25, 2007 [Page 11]
Internet-Draft DKIM-SSP-REQ April 2007
non-existence of records (ie, negative caching).
The second main scenario is when a domain exchanges mail with a much
smaller volume domain. This scenario can be both perfectly normal as
with the case of vanity domains, and sadly a vector for those sending
mail for anti-social reasons. In this case we'd like the message
exchange burden to SSP querier to be low, since many of the lookups
will not provide a useful answer. Likewise, it would be advantageous
to have upstream caching here as well so that, say, a mailing list
exploder on a small domain does not result in an explosion of queries
back at the root and authoritative server for the small domain.
4.6. Deployment Consideration 6: Human Legibility of Practices
While SSP records are likely to be primarily consumed by an
automaton, for the foreseeable future they are also likely to be
inspected by hand. It would be nice to have the practices stated in
a fashion which is also intuitive to the human inspectors.
4.7. Deployment Consideration 7: Extensibility
While this document pertains only to requirements surrounding DKIM
signing practices, it would be beneficial for the protocol to be able
to extend to other protocols.
4.8. Deployment Consideration 8: Security
SSP must be able to withstand life in a hostile open internet
environment. These include DoS attacks, and especially DoS attacks
that leverage themselves through amplification inherent in the
protocol. In addition, while a useful protocol may be built without
strong source authentication provided by the information service, a
path to strong source authentication should be provided by the
protocol, or underlying protocols.
Thomas Expires October 25, 2007 [Page 12]
Internet-Draft DKIM-SSP-REQ April 2007
5. Requirements
This section defines the requirements for SSP. As with most
requirements documents, these requirements define the MINIMUM
requirements that a candidate protocol must provide. It should also
be noted that SSP must fulfill all of the requirements.
5.1. Discovery Requirements
Receivers need a means of obtaining information about a sender's DKIM
practices. This requires a means of discovering where the
information is and what it contains.
1. The author is the first-party sender of a message, as specified
in the [rfc2822].From field. SSP's information is associated
with the author's domain name and is published subordinate to
that domain name.
2. In order to limit the cost of its use, any query service
supplying SSP's information MUST provide a definitive responsive
within a small, deterministic number of query exchanges.
[Informative Note: this, for all intents and purposes is a
prohibition on anything that might produce loops or result in
extended delays and overhead; also though "deterministic"
doesn't specify how many exchanges, the expectation is "few".]
[Refs: Deployment Considerations 2, 5]
3. SSP's publishing mechanism MUST be defined such that it does not
lead to multiple records of different protocols residing at the
same location.
[Informative note: An example is multiple resource record of
the same type within a common DNS leaf. Hence, uniquely
defined leaf names or uniquely defined resource record types
will ensure unambiguous reference.]
[Refs: Deployment Consideration 2]
4. SSP retrieval SHOULD provide coverage for not only a given domain
but all of its subdomains as well. The process of obtaining the
parent domain's practices MUST complete in a deterministic number
of steps. It is recognized that there is some reasonable doubt
about the feasibility of a widely accepted solution to this
requirement. If the working group does not achieve rough
consensus on a solution, it MUST document the relevant security
considerations in the protocol specification.
Thomas Expires October 25, 2007 [Page 13]
Internet-Draft DKIM-SSP-REQ April 2007
[Refs: Deployment Considerations 2, 5
5.2. SSP Transport Requirements
The publication and query mechanism will operate as an an internet-
based message exchange. There are multiple requirements for this
lower layer service:
1. The exchange SHOULD have existing widespread deployment of the
transport layer, especially if riding on top of a true transport
layer (eg, TCP, UDP).
[Refs: Deployment Considerations 5, 7]
2. The query/response in terms of latency time and the number of
packets involved MUST be low (order of 1 or 2 exchanges).
[Refs: Deployment Consideration 5]
3. If the infrastructure doesn't provide caching (ala DNS), the
records retrieved MUST provide initiators the ability maintain
their own cache. Existing caching infrastructure is, however,
highly desirable.
[Refs: Deployment Consideration 5]
4. Multiple geographically and topologically diverse servers MUST be
supported for high availability
[Refs: Deployment Considerations 5, 7]
5.3. Practice and Expectation Requirements
As stated in the definitions a Practice is a statement according to
the [RFC2822].From domain holder of externally verifiable behavior in
the email messages it sends. As an example, a Practice might be
defined that all email messages will contain a DKIM signature
corresponding to the RFC2822.From address. Since there is a
possibility of alteration between what a sender sends and a receiver
examines, an Expectation combines with a Practice to convey what the
RFC2822.From domain considers the likely outcome of the survivability
of the Practice at a receiver. For example, a Practice that a valid
DKIM for the RFC2822.From address is present when it is sent from the
domain, and an Expectation that it will remain present and valid for
all receivers whether topologically adjacent or not.
1. SSP MUST be able to make Practices and Expectation assertions
about the domain part of a [RFC2822].From address in the context
Thomas Expires October 25, 2007 [Page 14]
Internet-Draft DKIM-SSP-REQ April 2007
of DKIM. SSP will not make assertions about other addresses for
DKIM at this time.
[Refs: Problem Scenarios 1,2]
2. SSP MUST provide a concise linkage between the [RFC2822].From
and the identity in the DKIM i= tag, or its default if it is
missing in the signature. That is, SSP MUST precisely define
the semantics of what qualifies as a First Party Signature.
[Refs: Problem Scenarios 1,2]
3. SSP MUST be able to publish a Practice that the domain's signing
behavior is "DKIM Signing Complete". That is, all messages were
transmitted with a valid first party signature.
[Refs: Problem Scenario 1]
4. SSP MUST be able to publish an Expectation that a verifiable
first party DKIM Signature should be expected on receipt of a
message.
[Refs: Problem Scenario 2]
5. Practices and Expectations MUST be presented in SSP syntax using
as intuitive a descriptor as possible. For example, p=? would
be better represented as p=unknown.
[Refs: Deployment Consideration 6]
6. Because DKIM uses DNS to store selectors, there is always the
ability for a domain holder to delegate all or parts of the
_domainkey subdomain to an affiliated party of the domain
holder's choosing. That is, the domain holder may set an NS
record for _domainkey.example.com to delegate to an email
provider who manages the entire namespace. There is also the
ability for the domain holder to partition its namespace into
subdomains to further constrain third parties. For example, a
domain holder could delegate only
_domainkey.benefits.example.com to a third party to constrain
the third party to only be able to produce valid signatures in
the benefits.example.com subdomain. Last, a domain holder can
even use CNAME's to delegate individual leaf nodes. Given the
above considerations, SSP need not invent a different means of
allowing affiliated parties to sign on a domain's behalf at this
time.
Thomas Expires October 25, 2007 [Page 15]
Internet-Draft DKIM-SSP-REQ April 2007
[Refs: Deployment Consideration 4]
7. Practices and Expectations MUST be presented as an information
service from the signing domain to be consumed as an added
factor to the receiver's local policy. In particular, a
Practice or Expectation MUST NOT mandate any disposition stance
on the receiver.
[Refs: Problem Scenarios 1, 2]
8. There is no requirement that SSP publish a Practices of any/all
third parties that MUST NOT sign on the domain holder's behalf.
This should be considered out of scope.
[INFORMATIVE NOTE: this is essentially saying that the
protocol doesn't have to concern itself with being a
blacklist repository.]
[Refs: Problem Scenarios 1,2]
9. SSP MUST NOT be required to be invoked if a valid first party
signature is found.
[Refs: Deployment Consideration 2]
10. SSP MUST NOT provide a mechanism which impugns the existence of
non-first party signatures in a message. A corollary of this
requirement is that the protocol MUST NOT link practices of
first party signers with the practices of third party signers.
[INFORMATIVE NOTE: the main thrust of this requirement is
that practices should only be published for that which the
publisher has control, and should not meddle in what is
ultimately the local policy of the receiver.]
[Refs: Deployment Consideration 3]
5.4. Extensibility and Forward Compatibility Requirements
1. SSP MUST NOT extend to any other protocol than DKIM for email at
this time. SSP SHOULD be extensible for protocols other than
DKIM.
[Refs: Deployment Consideration 7]
2. SSP MUST be able to add new Practices and Expectations within the
existing discovery/transport/practices in a backward compatible
fashion.
Thomas Expires October 25, 2007 [Page 16]
Internet-Draft DKIM-SSP-REQ April 2007
[Refs: Deployment Consideration 7]
Thomas Expires October 25, 2007 [Page 17]
Internet-Draft DKIM-SSP-REQ April 2007
6. Security Requirements
1. SSP for a high-value domain is potentially a high-value DoS
target, especially since the unavailability of SSP's record could
make unsigned messages less suspicious.
2. SSP MUST NOT make highly leveraged amplification or make-work
attacks possible. In particular the work and message exchanges
involved MUST be order of a constant.
[Refs: Deployment Consideration 8]
3. SSP MUST have the ability for a domain holder to provide SSP's
data such that a receiver can determine that it is authentically
from the domain holder with a large degree of certainty. SSP may
provide means which provide less certainty in trade off for ease
of deployment.
[Refs: Deployment Consideration 8]
Thomas Expires October 25, 2007 [Page 18]
Internet-Draft DKIM-SSP-REQ April 2007
7. IANA Considerations
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
Thomas Expires October 25, 2007 [Page 19]
Internet-Draft DKIM-SSP-REQ April 2007
8. Security Considerations
This document defines requirements for a new protocol and the
security related requirements are defined above. There is an
expectation that SSP will not always be required to have source
authentication of the practices information which is noteworthy.
Thomas Expires October 25, 2007 [Page 20]
Internet-Draft DKIM-SSP-REQ April 2007
9. Acknowledgments
Dave Crocker and Jim Fenton provided substantial review of this
document.
Thomas Expires October 25, 2007 [Page 21]
Internet-Draft DKIM-SSP-REQ April 2007
10. References
10.1. Normative References
[I-D.ietf-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM)
Signatures", draft-ietf-dkim-base-04 (work in progress),
July 2006.
[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.
10.2. Informative References
Thomas Expires October 25, 2007 [Page 22]
Internet-Draft DKIM-SSP-REQ April 2007
Author's Address
Michael Thomas
Cisco Systems
606 Sanchez St
San Francisco, California 94114
USA
Phone: +1-408-525-5386
Fax: +1-408-525-5386
Email: mat@cisco.com
Thomas Expires October 25, 2007 [Page 23]
Internet-Draft DKIM-SSP-REQ April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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).
Thomas Expires October 25, 2007 [Page 24]
