DKIM Working Group D. Otis Internet-Draft Trend Micro, NSSG Expires: April 1, 2007 September 28, 2006 DKIM Originating Signing Policy (DOSP) draft-otis-dkim-dosp-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 1, 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, their role related to offering assurances, such as when an identity referencing the DOSP policy is assured to be valid. Otis Expires April 1, 2007 [Page 1] Internet-Draft DOSP September 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 . . . . . . . . . 6 3. DOSP Assertions . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.1. (A)ll initial messages signed . . . . . . . . . . . . 11 3.2.2. (L)ocal-Part policy is published . . . . . . . . . . . 11 3.2.3. (N)ot signing . . . . . . . . . . . . . . . . . . . . 11 3.2.4. (O)nly compliant services employed . . . . . . . . . . 11 3.2.5. (T)rusted Designated Local-Parts . . . . . . . . . . . 12 3.2.6. (V)alid Designated Local-Parts . . . . . . . . . . . . 12 3.3. Designated Signing for Address . . . . . . . . . . . . . . 12 3.4. Designated Signing for Domain . . . . . . . . . . . . . . 12 3.5. Local-Part . . . . . . . . . . . . . . . . . . . . . . . . 13 3.6. Policies in Aggregate . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. DNS Example . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Otis Expires April 1, 2007 [Page 2] Internet-Draft DOSP September 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 within 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 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. The DOSP allows the originating domain to make assertions that indicate when a referencing identity is valid or when a signing domain fulfills DOSP policy requirements. This is accomplished by designating roles for various signing domains. In addition, DOSP allows signing domains to associate with the SMTP Clients. By allowing signing domains to designate their SMTP Clients, anti-replay mechanisms can be by-passed for these SMTP Clients. Otis Expires April 1, 2007 [Page 3] Internet-Draft DOSP September 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 policies regarding the validity of related identities provide valuable advisory information. This advisory information allows the safe application of message annotations for ensuring trusted identities are properly recognized. Policy assertions convey which domains are authoritative and can assure valid identifiers. This information is essential for the proper recognition of valid email-addresses of trusted identities, as well as 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 policy assertions are only assurances of the message's the initial state. Blocking messages from non- designated sources or with invalid signatures will not provide sufficient protection, and is also likely to disrupt message delivery in many cases. Senders may become frustrated with delivery problems, while recipients remain exposed to look-alike or "cousin" domain spoofs, and are easily misled when only the 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 fully included within the DKIM Signature header field 'i=' parameter, or must be signed by a domain with a role of only signing valid email-addresses. 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 represent equally trustworthy identities or all follow the same practices. For the purposes of annotating messages based upon a trusted domain, local-part associations 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 Otis Expires April 1, 2007 [Page 4] Internet-Draft DOSP September 2006 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 the DOSP local-part policies. Otis Expires April 1, 2007 [Page 5] Internet-Draft DOSP September 2006 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. The DKIM protocol is designed to protect message content from alteration and to offer a verified signing domain. However, by design, the signing domain remains 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 messages 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. Being able to associate and assert policy for the [RFC2821].MailFrom email-address may prevent Delivery Status Notifications (DSNs) from being sent when this email-address is forged. Being able to associate SMTP Clients with the signing domain may 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 experimentation. 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 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 replay messages 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 Otis Expires April 1, 2007 [Page 6] Internet-Draft DOSP September 2006 with the domain administering the SMTP Client publicly transmitting the message. When the signing domain differs from that of the domain of 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 could also be designated as only providing a valid signature for fulfilling an assertion that all email-addresses are being signed, but that these email-addresses are not assured to be valid. While this latter role does 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. When the originating email-address domain differs from that of a provider adding DKIM signatures, 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 standardized formats for the exchange of 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 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 Otis Expires April 1, 2007 [Page 7] Internet-Draft DOSP September 2006 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. Otis Expires April 1, 2007 [Page 8] Internet-Draft DOSP September 2006 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 [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 = %2B ; "+" 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) ; VALCHAR = %x21-3A / %x3C-7E ; "!" to "~" except ";" ALNUMPUNC = ALPHA / DIGIT / underscore ; tag-value = [1*VALCHAR 0*( 1*(WSP / FWS) 1*VALCHAR)] ; 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 = MailFrom ; ehlo-label = base32( sha-1( lcase(EHLO-domain))) ; 32 characters Otis Expires April 1, 2007 [Page 9] Internet-Draft DOSP September 2006 +-----+--------------------------------+ | 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 | | | | | N | Not signing | | | | | O | Only compliant subsequent services employed | | | | | L | Local-Part policies are published | | | | | T | Trusted Designated Local-Part | | | | | V | Valid Designated Local-Part | +------+---------------------------------------------+ 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. The content of this concatenated string 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: "._DKIM-.." "._DKIM-.." "._DKIM-.." 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. Otis Expires April 1, 2007 [Page 10] Internet-Draft DOSP September 2006 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 / %x4C / %x4E / %x4F ; "A", "L", "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. 3.2.2. (L)ocal-Part policy is published This "L" flag asserts that local-part policy is published for the corresponding message header field or parameter. For example when a policy is published at ._DKIM-F. that has the "L" flag asserted, then local-part policy can be found at ._DKIM-LF.. This flag is not valid in "ehlo-policy" records. 3.2.3. (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.4. (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 Otis Expires April 1, 2007 [Page 11] Internet-Draft DOSP September 2006 willing to forego the use of many common services where signatures might be damaged, for example. 3.2.5. (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-policy" records. 3.2.6. (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-policy" records. 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 do not play the role of providing valid email-addresses, they only provide valid signatures. When the domain is prefixed with the "*." wildcard label, then all subdomains of this domain are also included to allow multiple "sig-labels" to share a common resource record. 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. This list is not valid in "ehlo-policy" records. When the signing domain used to generate the "sig-label" is not found in the list, and the list is not empty, the policy should be obtained by replacing the "sig-label" with "*" instead. In practice, this step should rarely be needed. 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. In addition, these domains play the role of providing valid email-addresses. When the domain is prefixed with the "*." wildcard label, then all Otis Expires April 1, 2007 [Page 12] Internet-Draft DOSP September 2006 subdomains of this domain are also included, which allows multiple "sig-labels" to share a common resource record. 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. This list also confirms SMTP Client domains in "ehlo-policy" records. When the EHLO or signing domain used to generate the "ehlo- label" or "sig-label" respectively is not found in the list, and the list is not empty, the policy should be obtained by replacing the "ehlo-label" or "sig-label" with "*" instead. In practice, this step should rarely be needed. 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 the designated local-part for which policy is being published. The local-part values contained within this tag confirms that the policy applies for the listed local-parts. These local-part values may be included in policies not referenced using "lp-labels". It is expected only a few email-addresses warrant special handling. When the local-part used to generate the "lp-label" is not found in the list, and the list is not empty, the policy should be obtained by replacing the "lp-label" with "*" instead. In practice, this step should rarely be needed. This list is not valid in "ehlo-policy" records. lp = local-part 0*(*FWS colon *FWS 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 flags 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 asserts that regardless of the DKIM signature header field's 'i=' semantics, email-address should not be considered Otis Expires April 1, 2007 [Page 13] Internet-Draft DOSP September 2006 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. It is unlikely there are benefits obtained by listing the domain in "Designated Signing for Address" (a=) list. 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 that no mail originates from this domain. o A domain that ensures that all messages are initially signed and attempts to ensure their users employ only complaint services, may indicate this extraordinary effort is being made 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 the related assertions. The current ":" flag separator can be considered to represent a logical AND of the related assertions. Otis Expires April 1, 2007 [Page 14] Internet-Draft DOSP September 2006 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 considered practical. Otis Expires April 1, 2007 [Page 15] Internet-Draft DOSP September 2006 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 1, 2007 [Page 16] Internet-Draft DOSP September 2006 6. Acknowledgements Hector Santos, and Frank Ellermann. Otis Expires April 1, 2007 [Page 17] Internet-Draft DOSP September 2006 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, . [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. [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 Identified Mail (DKIM)", RFC 4686, September 2006. Otis Expires April 1, 2007 [Page 18] Internet-Draft DOSP September 2006 Appendix A. DNS Example #### # example.com email domain using isp.com as a signing domain # EHLO host-name mx-01.example.com. IN A 10.1.1.1 #### 2822.From policy *.DKIM-F.example.com. IN TXT "v=0.0; a=*.example.com; l=admin; f=A:T:V;" # "isp.com" sig-label hgssd3snmi6635j5743vdjhajkmpmfif.DKIM-F.example.com. IN TXT "v=0.0; a=isp.com; f=A;" #### 2821.MailFrom policy *.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; a=isp.com; f=A;" #### 2822.Sender policy *.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;" #### 2821.EHLO policy *.DKIM-E.example.com. IN TXT "v=0.0; a=*.example.com; f=A;" # "mx-01.example.com" ehlo-label inkzgjwvtenf4zjexukzo4qknqhgwee6.DKIM-E.example.com. IN TXT "v=0.0; a=*.example.com; f=A;" Otis Expires April 1, 2007 [Page 19] Internet-Draft DOSP September 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 1, 2007 [Page 20] Internet-Draft DOSP September 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 1, 2007 [Page 21]