| TOC |
|
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 © The Internet Society (2006).
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.
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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
1.
Introduction
2.
DKIM Policy Compliance and Safe Annotations
2.1.
The Signing Domain
3.
DOSP Assertions
3.1.
Version
3.2.
Flags
3.2.1.
(A)ll initial messages signed
3.2.2.
(D)efault
3.2.3.
(L)ocal-Part policy is published
3.2.4.
(N)ot signing
3.2.5.
(O)nly compliant services employed
3.2.6.
(T)rusted Designated Local-Parts
3.2.7.
(V)alid Designated Local-Parts
3.3.
Designated Signing for Address
3.4.
Designated Signing for Domain
3.5.
Local-Part
3.6.
Policies in Aggregate
4.
IANA Considerations
5.
Security Considerations
6.
Acknowledgements
7.
References
7.1.
Normative References
7.2.
Informative References
Appendix A.
DNS Example of permissive all-signed From policy
Appendix B.
DNS Example of restrictive MailFrom policy
Appendix C.
DNS Example of permissive all-signed Sender policy
Appendix D.
DNS Example of restrictive EHLO policy
Appendix E.
DNS Example of permissive all-signed From with published local-part policy
Appendix F.
DNS Example of restrictive From policy
Appendix G.
DNS Example of a highly restrictive From policy
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
This document describes how [I-D.ietf-dkim-base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” August 2006.) 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:
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.
The goal of DOSP is to:
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:
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, 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.
| TOC |
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] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” August 2006.) 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] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.).MailFrom email-address. Allowing the [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.).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.
| TOC |
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 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 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.
| TOC |
Syntax descriptions use the form described in Augmented BNF for Syntax Specifications [RFC4234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.).
The "base32" function is defined in [RFC3548] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” July 2003.) and the "sha-1" hash function is defined in [FIPS.180-2.2002] (National Institute of Standards and Technology, “Secure Hash Standard,” August 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 ;
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] (Resnick, P., “Internet Message Format,” April 2001.).From
Originator = "O" ; [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.).Sender/Resent-Sender/Resent-From
MailFrom = "M" ; [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.).MAIL FROM
Ehlo = "E" ; [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.).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 |
| DOSP Tags |
| 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 |
| DOSP Flags |
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] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.) 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.
| TOC |
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.]
| TOC |
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)
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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
| TOC |
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.
dsd = [ANY] domain 0*(*FWS colon *FWS [ANY] domain)
dsd-list = %x64 [FWS] equals [FWS] dsd
| TOC |
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
| TOC |
| TOC |
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.
| TOC |
This draft defines signing policies related to [I-D.ietf-dkim-base] (Allman, E., “DomainKeys Identified Mail (DKIM) Signatures,” August 2006.). 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.
| TOC |
Hector Santos, and Frank Ellermann.
| TOC |
| TOC |
| [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 (TXT, HTML, XML). |
| [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. |
| TOC |
| [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. |
| TOC |
####
# 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;
| TOC |
#### 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;"
| TOC |
#### 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;"
| TOC |
#### 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
| TOC |
#### 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;"
| TOC |
#### 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;"
| TOC |
# 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;"
| TOC |
| 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 |
| TOC |
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.
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 © 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.
Funding for the RFC Editor function is currently provided by the Internet Society.