RFC's
RFC 4871 - DomainKeys Identified Mail (DKIM) Signatures

Network Working Group E. Allman

Request for Comments: 4871 Sendmail, Inc.

Obsoletes: 4870 J. Callas

Category: Standards Track PGP Corporation

M. Delany

M. Libbey

Yahoo! Inc

J. Fenton

M. Thomas

Cisco Systems, Inc.

May 2007

DomainKeys Identified Mail (DKIM) Signatures

Status of This Memo

This document specifies an Internet standards track protocol for the

Internet community, and requests discussion and suggestions for

improvements. Please refer to the current edition of the "Internet

Official Protocol Standards" (STD 1) for the standardization state

and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The IETF Trust (2007).

Abstract

DomainKeys Identified Mail (DKIM) defines a domain-level

authentication framework for email using public-key cryptography and

key server technology to permit verification of the source and

contents of messages by either Mail Transfer Agents (MTAs) or Mail

User Agents (MUAs). The ultimate goal of this framework is to permit

a signing domain to assert responsibility for a message, thus

protecting message signer identity and the integrity of the messages

they convey while retaining the functionality of Internet email as it

is known today. Protection of email identity may assist in the

global control of "spam" and "phishing".

Allman, et al. Standards Track [Page 1]

RFC 4871 DKIM Signatures May 2007

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5

1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5

1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5

2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5

2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6

2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7

2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7

3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8

3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10

3.3. Signing and Verification Algorithms . . . . . . . . . . . 11

3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13

3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 17

3.6. Key Management and Representation . . . . . . . . . . . . 25

3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29

3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 31

4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 32

4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 32

4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 33

5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 34

5.1. Determine Whether the Email Should Be Signed and by

Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2. Select a Private Key and Corresponding Selector

Information . . . . . . . . . . . . . . . . . . . . . . . 35

5.3. Normalize the Message to Prevent Transport Conversions . . 35

5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36

5.5. Recommended Signature Content . . . . . . . . . . . . . . 38

5.6. Compute the Message Hash and Signature . . . . . . . . . . 39

5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 40

6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 40

6.1. Extract Signatures from the Message . . . . . . . . . . . 41

6.2. Communicate Verification Results . . . . . . . . . . . . . 46

6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 47

7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48

7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48

7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 49

7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 49

7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 50

7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 50

7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51

7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51

7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52

Allman, et al. Standards Track [Page 2]

RFC 4871 DKIM Signatures May 2007

7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 52

8. Security Considerations . . . . . . . . . . . . . . . . . . . 52

8.1. Misuse of Body Length Limits ("l=" Tag) . . . . . . . . . 52

8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53

8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54

8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54

8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55

8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 55

8.7. Intentionally Malformed Key Records . . . . . . . . . . . 56

8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 56

8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56

8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56

8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56

8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 56

8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 57

9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57

9.1. Normative References . . . . . . . . . . . . . . . . . . . 57

9.2. Informative References . . . . . . . . . . . . . . . . . . 58

Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60

A.1. The user composes an email . . . . . . . . . . . . . . . . 60

A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61

A.3. The email signature is verified . . . . . . . . . . . . . 61

Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62

B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63

B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65

Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67

Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68

Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69

Allman, et al. Standards Track [Page 3]

RFC 4871 DKIM Signatures May 2007

1. Introduction

DomainKeys Identified Mail (DKIM) defines a mechanism by which email

messages can be cryptographically signed, permitting a signing domain

to claim responsibility for the introduction of a message into the

mail stream. Message recipients can verify the signature by querying

the signer's domain directly to retrieve the appropriate public key,

and thereby confirm that the message was attested to by a party in

possession of the private key for the signing domain.

The approach taken by DKIM differs from previous approaches to

message signing (e.g., Secure/Multipurpose Internet Mail Extensions

(S/MIME) [RFC1847], OpenPGP [RFC2440]) in that:

o the message signature is written as a message header field so that

neither human recipients nor existing MUA (Mail User Agent)

software is confused by signature-related content appearing in the

message body;

o there is no dependency on public and private key pairs being

issued by well-known, trusted certificate authorities;

o there is no dependency on the deployment of any new Internet

protocols or services for public key distribution or revocation;

o signature verification failure does not force rejection of the

message;

o no attempt is made to include encryption as part of the mechanism;

o message archiving is not a design goal.

DKIM:

o is compatible with the existing email infrastructure and

transparent to the fullest extent possible;

o requires minimal new infrastructure;

o can be implemented independently of clients in order to reduce

deployment time;

o can be deployed incrementally;

o allows delegation of signing to third parties.

Allman, et al. Standards Track [Page 4]

RFC 4871 DKIM Signatures May 2007

1.1. Signing Identity

DKIM separates the question of the identity of the signer of the

message from the purported author of the message. In particular, a

signature includes the identity of the signer. Verifiers can use the

signing information to decide how they want to process the message.

The signing identity is included as part of the signature header

field.

INFORMATIVE RATIONALE: The signing identity specified by a DKIM

signature is not required to match an address in any particular

header field because of the broad methods of interpretation by

recipient mail systems, including MUAs.

1.2. Scalability

DKIM is designed to support the extreme scalability requirements that

characterize the email identification problem. There are currently

over 70 million domains and a much larger number of individual

addresses. DKIM seeks to preserve the positive aspects of the

current email infrastructure, such as the ability for anyone to

communicate with anyone else without introduction.

1.3. Simple Key Management

DKIM differs from traditional hierarchical public-key systems in that

no Certificate Authority infrastructure is required; the verifier

requests the public key from a repository in the domain of the

claimed signer directly rather than from a third party.

The DNS is proposed as the initial mechanism for the public keys.

Thus, DKIM currently depends on DNS administration and the security

of the DNS system. DKIM is designed to be extensible to other key

fetching services as they become available.

2. Terminology and Definitions

This section defines terms used in the rest of the document. Syntax

descriptions use the form described in Augmented BNF for Syntax

Specifications [RFC4234].

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

Allman, et al. Standards Track [Page 5]

RFC 4871 DKIM Signatures May 2007

2.1. Signers

Elements in the mail system that sign messages on behalf of a domain

are referred to as signers. These may be MUAs (Mail User Agents),

MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other

agents such as mailing list exploders. In general, any signer will

be involved in the injection of a message into the message system in

some way. The key issue is that a message must be signed before it

leaves the administrative domain of the signer.

2.2. Verifiers

Elements in the mail system that verify signatures are referred to as

verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs.

In most cases it is expected that verifiers will be close to an end

user (reader) of the message or some consuming agent such as a

mailing list exploder.

2.3. Whitespace

There are three forms of whitespace:

o WSP represents simple whitespace, i.e., a space or a tab character

(formal definition in [RFC4234]).

o LWSP is linear whitespace, defined as WSP plus CRLF (formal

definition in [RFC4234]).

o FWS is folding whitespace. It allows multiple lines separated by

CRLF followed by at least one whitespace, to be joined.

The formal ABNF for these are (WSP and LWSP are given for information

only):

WSP = SP / HTAB

LWSP = *(WSP / CRLF WSP)

FWS = [*WSP CRLF] 1*WSP

The definition of FWS is identical to that in [RFC2822] except for

the exclusion of obs-FWS.

2.4. Common ABNF Tokens

The following ABNF tokens are used elsewhere in this document:

hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]

base64string = 1*(ALPHA / DIGIT / "+" / "/" / [FWS])

[ "=" [FWS] [ "=" [FWS] ] ]

Allman, et al. Standards Track [Page 6]

RFC 4871 DKIM Signatures May 2007

2.5. Imported ABNF Tokens

The following tokens are imported from other RFCs as noted. Those

RFCs should be considered definitive.

The following tokens are imported from [RFC2821]:

o "Local-part" (implementation warning: this permits quoted strings)

o "sub-domain"

The following tokens are imported from [RFC2822]:

o "field-name" (name of a header field)

o "dot-atom-text" (in the Local-part of an email address)

The following tokens are imported from [RFC2045]:

o "qp-section" (a single line of quoted-printable-encoded text)

o "hex-octet" (a quoted-printable encoded octet)

INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not obey

the rules of RFC 4234 and must be interpreted accordingly,

particularly as regards case folding.

Other tokens not defined herein are imported from [RFC4234]. These

are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF,

etc.

2.6. DKIM-Quoted-Printable

The DKIM-Quoted-Printable encoding syntax resembles that described in

Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded

as an "=" followed by two hexadecimal digits from the alphabet

"0123456789ABCDEF" (no lowercase characters permitted) representing

the hexadecimal-encoded integer value of that character. All control

characters (those with values < %x20), 8-bit characters (values >

%x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon

(";", %x3B) MUST be encoded. Note that all whitespace, including

SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS

MAY be added at arbitrary locations in order to avoid excessively

long lines; such whitespace is NOT part of the value, and MUST be

removed before decoding.

Allman, et al. Standards Track [Page 7]

RFC 4871 DKIM Signatures May 2007

ABNF:

dkim-quoted-printable =

*(FWS / hex-octet / dkim-safe-char)

; hex-octet is from RFC 2045

dkim-safe-char = %x21-3A / %x3C / %x3E-7E

; '!' - ':', '<', '>' - '~'

; Characters not listed as "mail-safe" in

; RFC 2049 are also not recommended.

INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-

Printable as defined in RFC 2045 in several important ways:

1. Whitespace in the input text, including CR and LF, must be

encoded. RFC 2045 does not require such encoding, and does

not permit encoding of CR or LF characters that are part of a

CRLF line break.

2. Whitespace in the encoded text is ignored. This is to allow

tags encoded using DKIM-Quoted-Printable to be wrapped as

needed. In particular, RFC 2045 requires that line breaks in

the input be represented as physical line breaks; that is not

the case here.

3. The "soft line break" syntax ("=" as the last non-whitespace

character on the line) does not apply.

4. DKIM-Quoted-Printable does not require that encoded lines be

no more than 76 characters long (although there may be other

requirements depending on the context in which the encoded

text is being used).

3. Protocol Elements

Protocol Elements are conceptual parts of the protocol that are not

specific to either signers or verifiers. The protocol descriptions

for signers and verifiers are described in later sections (Signer

Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This

section must be read in the context of those sections.

3.1. Selectors

To support multiple concurrent public keys per signing domain, the

key namespace is subdivided using "selectors". For example,

selectors might indicate the names of office locations (e.g.,

"sanfrancisco", "coolumbeach", and "reykjavik"), the signing date

(e.g., "january2005", "february2005", etc.), or even the individual

user.

Allman, et al. Standards Track [Page 8]

RFC 4871 DKIM Signatures May 2007

Selectors are needed to support some important use cases. For

example:

o Domains that want to delegate signing capability for a specific

address for a given duration to a partner, such as an advertising

provider or other outsourced function.

o Domains that want to allow frequent travelers to send messages

locally without the need to connect with a particular MSA.

o "Affinity" domains (e.g., college alumni associations) that

provide forwarding of incoming mail, but that do not operate a

mail submission agent for outgoing mail.

Periods are allowed in selectors and are component separators. When

keys are retrieved from the DNS, periods in selectors define DNS

label boundaries in a manner similar to the conventional use in

domain names. Selector components might be used to combine dates

with locations, for example, "march2005.reykjavik". In a DNS

implementation, this can be used to allow delegation of a portion of

the selector namespace.

ABNF:

selector = sub-domain *( "." sub-domain )

The number of public keys and corresponding selectors for each domain

is determined by the domain owner. Many domain owners will be

satisfied with just one selector, whereas administratively

distributed organizations may choose to manage disparate selectors

and key pairs in different regions or on different email servers.

Beyond administrative convenience, selectors make it possible to

seamlessly replace public keys on a routine basis. If a domain

wishes to change from using a public key associated with selector

"january2005" to a public key associated with selector

"february2005", it merely makes sure that both public keys are

advertised in the public-key repository concurrently for the

transition period during which email may be in transit prior to

verification. At the start of the transition period, the outbound

email servers are configured to sign with the "february2005" private

key. At the end of the transition period, the "january2005" public

key is removed from the public-key repository.

INFORMATIVE NOTE: A key may also be revoked as described below.

The distinction between revoking and removing a key selector

record is subtle. When phasing out keys as described above, a

signing domain would probably simply remove the key record after

Allman, et al. Standards Track [Page 9]

RFC 4871 DKIM Signatures May 2007

the transition period. However, a signing domain could elect to

revoke the key (but maintain the key record) for a further period.

There is no defined semantic difference between a revoked key and

a removed key.

While some domains may wish to make selector values well known,

others will want to take care not to allocate selector names in a way

that allows harvesting of data by outside parties. For example, if

per-user keys are issued, the domain owner will need to make the

decision as to whether to associate this selector directly with the

user name, or make it some unassociated random value, such as a

fingerprint of the public key.

INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key

(for example, changing the key associated with a user's name)

makes it impossible to tell the difference between a message that

didn't verify because the key is no longer valid versus a message

that is actually forged. For this reason, signers are ill-advised

to reuse selectors for new keys. A better strategy is to assign

new keys to new selectors.

3.2. Tag=Value Lists

DKIM uses a simple "tag=value" syntax in several contexts, including

in messages and domain signature records.

Values are a series of strings containing either plain text, "base64"

text (as defined in [RFC2045], Section 6.8), "qp-section" (ibid,

Section 6.7), or "dkim-quoted-printable" (as defined in Section 2.6).

The name of the tag will determine the encoding of each value.

Unencoded semicolon (";") characters MUST NOT occur in the tag value,

since that separates tag-specs.

INFORMATIVE IMPLEMENTATION NOTE: Although the "plain text" defined

below (as "tag-value") only includes 7-bit characters, an

implementation that wished to anticipate future standards would be

advised not to preclude the use of UTF8-encoded text in tag=value

lists.

Allman, et al. Standards Track [Page 10]

RFC 4871 DKIM Signatures May 2007

Formally, the syntax rules are as follows:

tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]

tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]

tag-name = ALPHA 0*ALNUMPUNC

tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]

; WSP and FWS prohibited at beginning and end

tval = 1*VALCHAR

VALCHAR = %x21-3A / %x3C-7E

; EXCLAMATION to TILDE except SEMICOLON

ALNUMPUNC = ALPHA / DIGIT / "_"

Note that WSP is allowed anywhere around tags. In particular, any

WSP after the "=" and any WSP before the terminating ";" is not part

of the value; however, WSP inside the value is significant.

Tags MUST be interpreted in a case-sensitive manner. Values MUST be

processed as case sensitive unless the specific tag description of

semantics specifies case insensitivity.

Tags with duplicate names MUST NOT occur within a single tag-list; if

a tag name does occur more than once, the entire tag-list is invalid.

Whitespace within a value MUST be retained unless explicitly excluded

by the specific tag description.

Tag=value pairs that represent the default value MAY be included to

aid legibility.

Unrecognized tags MUST be ignored.

Tags that have an empty value are not the same as omitted tags. An

omitted tag is treated as having the default value; a tag with an

empty value explicitly designates the empty string as the value. For

example, "g=" does not mean "g=*", even though "g=*" is the default

for that tag.

3.3. Signing and Verification Algorithms

DKIM supports multiple digital signature algorithms. Two algorithms

are defined by this specification at this time: rsa-sha1 and rsa-

sha256. The rsa-sha256 algorithm is the default if no algorithm is

specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256.

Signers MUST implement and SHOULD sign using rsa-sha256.

Allman, et al. Standards Track [Page 11]

RFC 4871 DKIM Signatures May 2007

INFORMATIVE NOTE: Although sha256 is strongly encouraged, some

senders of low-security messages (such as routine newsletters) may

prefer to use sha1 because of reduced CPU requirements to compute

a sha1 hash. In general, sha256 should always be used whenever

possible.

3.3.1. The rsa-sha1 Signing Algorithm

The rsa-sha1 Signing Algorithm computes a message hash as described

in Section 3.7 below using SHA-1 [FIPS.180-2.2002] as the hash-alg.

That hash is then signed by the signer using the RSA algorithm

(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the

signer's private key. The hash MUST NOT be truncated or converted

into any form other than the native binary form before being signed.

The signing algorithm SHOULD use a public exponent of 65537.

3.3.2. The rsa-sha256 Signing Algorithm

The rsa-sha256 Signing Algorithm computes a message hash as described

in Section 3.7 below using SHA-256 [FIPS.180-2.2002] as the hash-alg.

That hash is then signed by the signer using the RSA algorithm

(defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the

signer's private key. The hash MUST NOT be truncated or converted

into any form other than the native binary form before being signed.

3.3.3. Key Sizes

Selecting appropriate key sizes is a trade-off between cost,

performance, and risk. Since short RSA keys more easily succumb to

off-line attacks, signers MUST use RSA keys of at least 1024 bits for

long-lived keys. Verifiers MUST be able to validate signatures with

keys ranging from 512 bits to 2048 bits, and they MAY be able to

validate signatures with larger keys. Verifier policies may use the

length of the signing key as one metric for determining whether a

signature is acceptable.

Factors that should influence the key size choice include the

following:

o The practical constraint that large (e.g., 4096 bit) keys may not

fit within a 512-byte DNS UDP response packet

o The security constraint that keys smaller than 1024 bits are

subject to off-line attacks

o Larger keys impose higher CPU costs to verify and sign email

Allman, et al. Standards Track [Page 12]

RFC 4871 DKIM Signatures May 2007

o Keys can be replaced on a regular basis, thus their lifetime can

be relatively short

o The security goals of this specification are modest compared to

typical goals of other systems that employ digital signatures

See [RFC3766] for further discussion on selecting key sizes.

3.3.4. Other Algorithms

Other algorithms MAY be defined in the future. Verifiers MUST ignore

any signatures using algorithms that they do not implement.

3.4. Canonicalization

Empirical evidence demonstrates that some mail servers and relay

systems modify email in transit, potentially invalidating a

signature. There are two competing perspectives on such

modifications. For most signers, mild modification of email is

immaterial to the authentication status of the email. For such

signers, a canonicalization algorithm that survives modest in-transit

modification is preferred.

Other signers demand that any modification of the email, however

minor, result in a signature verification failure. These signers

prefer a canonicalization algorithm that does not tolerate in-transit

modification of the signed email.

Some signers may be willing to accept modifications to header fields

that are within the bounds of email standards such as [RFC2822], but

are unwilling to accept any modification to the body of messages.

To satisfy all requirements, two canonicalization algorithms are

defined for each of the header and the body: a "simple" algorithm

that tolerates almost no modification and a "relaxed" algorithm that

tolerates common modifications such as whitespace replacement and

header field line rewrapping. A signer MAY specify either algorithm

for header or body when signing an email. If no canonicalization

algorithm is specified by the signer, the "simple" algorithm defaults

for both header and body. Verifiers MUST implement both

canonicalization algorithms. Note that the header and body may use

different canonicalization algorithms. Further canonicalization

algorithms MAY be defined in the future; verifiers MUST ignore any

signatures that use unrecognized canonicalization algorithms.

Canonicalization simply prepares the email for presentation to the

signing or verification algorithm. It MUST NOT change the

Allman, et al. Standards Track [Page 13]

RFC 4871 DKIM Signatures May 2007

transmitted data in any way. Canonicalization of header fields and

body are described below.

NOTE: This section assumes that the message is already in "network

normal" format (text is ASCII encoded, lines are separated with CRLF

characters, etc.). See also Section 5.3 for information about

normalizing the message.

3.4.1. The "simple" Header Canonicalization Algorithm

The "simple" header canonicalization algorithm does not change header

fields in any way. Header fields MUST be presented to the signing or

verification algorithm exactly as they are in the message being

signed or verified. In particular, header field names MUST NOT be

case folded and whitespace MUST NOT be changed.

3.4.2. The "relaxed" Header Canonicalization Algorithm

The "relaxed" header canonicalization algorithm MUST apply the

following steps in order:

o Convert all header field names (not the header field values) to

lowercase. For example, convert "SUBJect: AbC" to "subject: AbC".

o Unfold all header field continuation lines as described in

[RFC2822]; in particular, lines with terminators embedded in

continued header field values (that is, CRLF sequences followed by

WSP) MUST be interpreted without the CRLF. Implementations MUST

NOT remove the CRLF at the end of the header field value.

o Convert all sequences of one or more WSP characters to a single SP

character. WSP characters here include those before and after a

line folding boundary.

o Delete all WSP characters at the end of each unfolded header field

value.

o Delete any WSP characters remaining before and after the colon

separating the header field name from the header field value. The

colon separator MUST be retained.

3.4.3. The "simple" Body Canonicalization Algorithm

The "simple" body canonicalization algorithm ignores all empty lines

at the end of the message body. An empty line is a line of zero

length after removal of the line terminator. If there is no body or

no trailing CRLF on the message body, a CRLF is added. It makes no

Allman, et al. Standards Track [Page 14]

RFC 4871 DKIM Signatures May 2007

other changes to the message body. In more formal terms, the

"simple" body canonicalization algorithm converts "0*CRLF" at the end

of the body to a single "CRLF".

Note that a completely empty or missing body is canonicalized as a

single "CRLF"; that is, the canonicalized length will be 2 octets.

3.4.4. The "relaxed" Body Canonicalization Algorithm

The "relaxed" body canonicalization algorithm:

o Ignores all whitespace at the end of lines. Implementations MUST

NOT remove the CRLF at the end of the line.

o Reduces all sequences of WSP within a line to a single SP

character.

o Ignores all empty lines at the end of the message body. "Empty

line" is defined in Section 3.4.3.

INFORMATIVE NOTE: It should be noted that the relaxed body

canonicalization algorithm may enable certain types of extremely

crude "ASCII Art" attacks where a message may be conveyed by

adjusting the spacing between words. If this is a concern, the

"simple" body canonicalization algorithm should be used instead.

3.4.5. Body Length Limits

A body length count MAY be specified to limit the signature

calculation to an initial prefix of the body text, measured in

octets. If the body length count is not specified, the entire

message body is signed.

INFORMATIVE RATIONALE: This capability is provided because it is

very common for mailing lists to add trailers to messages (e.g.,

instructions how to get off the list). Until those messages are

also signed, the body length count is a useful tool for the

verifier since it may as a matter of policy accept messages having

valid signatures with extraneous data.

INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables

an attack in which an attacker modifies a message to include

content that solely benefits the attacker. It is possible for the

appended content to completely replace the original content in the

end recipient's eyes and to defeat duplicate message detection

algorithms. To avoid this attack, signers should be wary of using

Allman, et al. Standards Track [Page 15]

RFC 4871 DKIM Signatures May 2007

this tag, and verifiers might wish to ignore the tag or remove

text that appears after the specified content length, perhaps

based on other criteria.

The body length count allows the signer of a message to permit data

to be appended to the end of the body of a signed message. The body

length count MUST be calculated following the canonicalization

algorithm; for example, any whitespace ignored by a canonicalization

algorithm is not included as part of the body length count. Signers

of MIME messages that include a body length count SHOULD be sure that

the length extends to the closing MIME boundary string.

INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that

the only acceptable modifications are to add to the MIME postlude

would use a body length count encompassing the entire final MIME

boundary string, including the final "--CRLF". A signer wishing

to allow additional MIME parts but not modification of existing

parts would use a body length count extending through the final

MIME boundary string, omitting the final "--CRLF". Note that this

only works for some MIME types, e.g., multipart/mixed but not

multipart/signed.

A body length count of zero means that the body is completely

unsigned.

Signers wishing to ensure that no modification of any sort can occur

should specify the "simple" canonicalization algorithm for both

header and body and omit the body length count.

3.4.6. Canonicalization Examples (INFORMATIVE)

In the following examples, actual whitespace is used only for

clarity. The actual input and output text is designated using

bracketed descriptors: "<sp>" for a space character, "<htab>" for a </htab></sp>

tab character, and "<crlf>" for a carriage-return/line-feed sequence. </crlf>

For example, "X <sp> Y" and "X<sp>Y" represent the same three </sp></sp>

characters.

Example 1: A message reading:

A: <sp> X <crlf></crlf></sp>

B <sp> : <sp> Y <htab><crlf></crlf></htab></sp></sp>

<htab> Z <sp><sp><crlf></crlf></sp></sp></htab>

<crlf></crlf>

<sp> C <sp><crlf></crlf></sp></sp>

D <sp><htab><sp> E <crlf></crlf></sp></htab></sp>

<crlf></crlf>

<crlf></crlf>

Allman, et al. Standards Track [Page 16]

RFC 4871 DKIM Signatures May 2007

when canonicalized using relaxed canonicalization for both header and

body results in a header reading:

a:X <crlf></crlf>

b:Y <sp> Z <crlf></crlf></sp>

and a body reading:

<sp> C <crlf></crlf></sp>

D <sp> E <crlf></crlf></sp>

Example 2: The same message canonicalized using simple

canonicalization for both header and body results in a header

reading:

A: <sp> X <crlf></crlf></sp>

B <sp> : <sp> Y <htab><crlf></crlf></htab></sp></sp>

<htab> Z <sp><sp><crlf></crlf></sp></sp></htab>

and a body reading:

<sp> C <sp><crlf></crlf></sp></sp>

D <sp><htab><sp> E <crlf></crlf></sp></htab></sp>

Example 3: When processed using relaxed header canonicalization and

simple body canonicalization, the canonicalized version has a header

of:

a:X <crlf></crlf>

b:Y <sp> Z <crlf></crlf></sp>

and a body reading:

<sp> C <sp><crlf></crlf></sp></sp>

D <sp><htab><sp> E <crlf></crlf></sp></htab></sp>

3.5. The DKIM-Signature Header Field

The signature of the email is stored in the DKIM-Signature header

field. This header field contains all of the signature and key-

fetching data. The DKIM-Signature value is a tag-list as described

in Section 3.2.

The DKIM-Signature header field SHOULD be treated as though it were a

trace header field as defined in Section 3.6 of [RFC2822], and hence

SHOULD NOT be reordered and SHOULD be prepended to the message.

Allman, et al. Standards Track [Page 17]

RFC 4871 DKIM Signatures May 2007

The DKIM-Signature header field being created or verified is always

included in the signature calculation, after the rest of the header

fields being signed; however, when calculating or verifying the

signature, the value of the "b=" tag (signature value) of that DKIM-

Signature header field MUST be treated as though it were an empty

string. Unknown tags in the DKIM-Signature header field MUST be

included in the signature calculation but MUST be otherwise ignored

by verifiers. Other DKIM-Signature header fields that are included

in the signature should be treated as normal header fields; in

particular, the "b=" tag is not treated specially.

The encodings for each field type are listed below. Tags described

as qp-section are encoded as described in Section 6.7 of MIME Part

One [RFC2045], with the additional conversion of semicolon characters

to "=3B"; intuitively, this is one line of quoted-printable encoded

text. The dkim-quoted-printable syntax is defined in Section 2.6.

Tags on the DKIM-Signature header field along with their type and

requirement status are shown below. Unrecognized tags MUST be

ignored.

v= Version (MUST be included). This tag defines the version of this

specification that applies to the signature record. It MUST have

the value "1". Note that verifiers must do a string comparison

on this value; for example, "1" is not the same as "1.0".

ABNF:

sig-v-tag = %x76 [FWS] "=" [FWS] "1"

INFORMATIVE NOTE: DKIM-Signature version numbers are expected

to increase arithmetically as new versions of this

specification are released.

a= The algorithm used to generate the signature (plain-text;

REQUIRED). Verifiers MUST support "rsa-sha1" and "rsa-sha256";

signers SHOULD sign using "rsa-sha256". See Section 3.3 for a

description of algorithms.

ABNF:

sig-a-tag = %x61 [FWS] "=" [FWS] sig-a-tag-alg

sig-a-tag-alg = sig-a-tag-k "-" sig-a-tag-h

sig-a-tag-k = "rsa" / x-sig-a-tag-k

sig-a-tag-h = "sha1" / "sha256" / x-sig-a-tag-h

x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension

x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension

Allman, et al. Standards Track [Page 18]

RFC 4871 DKIM Signatures May 2007

b= The signature data (base64; REQUIRED). Whitespace is ignored in

this value and MUST be ignored when reassembling the original

signature. In particular, the signing process can safely insert

FWS in this value in arbitrary places to conform to line-length

limits. See Signer Actions (Section 5) for how the signature is

computed.

ABNF:

sig-b-tag = %x62 [FWS] "=" [FWS] sig-b-tag-data

sig-b-tag-data = base64string

bh= The hash of the canonicalized body part of the message as limited

by the "l=" tag (base64; REQUIRED). Whitespace is ignored in

this value and MUST be ignored when reassembling the original

signature. In particular, the signing process can safely insert

FWS in this value in arbitrary places to conform to line-length

limits. See Section 3.7 for how the body hash is computed.

ABNF:

sig-bh-tag = %x62 %x68 [FWS] "=" [FWS] sig-bh-tag-data

sig-bh-tag-data = base64string

c= Message canonicalization (plain-text; OPTIONAL, default is

"simple/simple"). This tag informs the verifier of the type of

canonicalization used to prepare the message for signing. It

consists of two names separated by a "slash" (%d47) character,

corresponding to the header and body canonicalization algorithms

respectively. These algorithms are described in Section 3.4. If

only one algorithm is named, that algorithm is used for the

header and "simple" is used for the body. For example,

"c=relaxed" is treated the same as "c=relaxed/simple".

ABNF:

sig-c-tag = %x63 [FWS] "=" [FWS] sig-c-tag-alg

["/" sig-c-tag-alg]

sig-c-tag-alg = "simple" / "relaxed" / x-sig-c-tag-alg

x-sig-c-tag-alg = hyphenated-word ; for later extension

d= The domain of the signing entity (plain-text; REQUIRED). This is

the domain that will be queried for the public key. This domain

MUST be the same as or a parent domain of the "i=" tag (the

signing identity, as described below), or it MUST meet the

requirements for parent domain signing described in Section 3.8.

When presented with a signature that does not meet these

requirement, verifiers MUST consider the signature invalid.

Allman, et al. Standards Track [Page 19]

RFC 4871 DKIM Signatures May 2007

Internationalized domain names MUST be encoded as described in

[RFC3490].

ABNF:

sig-d-tag = %x64 [FWS] "=" [FWS] domain-name

domain-name = sub-domain 1*("." sub-domain)

; from RFC 2821 Domain, but excluding address-literal

h= Signed header fields (plain-text, but see description; REQUIRED).

A colon-separated list of header field names that identify the

header fields presented to the signing algorithm. The field MUST

contain the complete list of header fields in the order presented

to the signing algorithm. The field MAY contain names of header

fields that do not exist when signed; nonexistent header fields

do not contribute to the signature computation (that is, they are

treated as the null input, including the header field name, the

separating colon, the header field value, and any CRLF

terminator). The field MUST NOT include the DKIM-Signature

header field that is being created or verified, but may include

others. Folding whitespace (FWS) MAY be included on either side

of the colon separator. Header field names MUST be compared

against actual header field names in a case-insensitive manner.

This list MUST NOT be empty. See Section 5.4 for a discussion of

choosing header fields to sign.

ABNF:

sig-h-tag = %x68 [FWS] "=" [FWS] hdr-name

0*( *FWS ":" *FWS hdr-name )

hdr-name = field-name

INFORMATIVE EXPLANATION: By "signing" header fields that do not

actually exist, a signer can prevent insertion of those

header fields before verification. However, since a signer

cannot possibly know what header fields might be created in

the future, and that some MUAs might present header fields

that are embedded inside a message (e.g., as a message/rfc822

content type), the security of this solution is not total.

INFORMATIVE EXPLANATION: The exclusion of the header field name

and colon as well as the header field value for non-existent

header fields prevents an attacker from inserting an actual

header field with a null value.

Allman, et al. Standards Track [Page 20]

RFC 4871 DKIM Signatures May 2007

i= Identity of the user or agent (e.g., a mailing list manager) on

behalf of which this message is signed (dkim-quoted-printable;

OPTIONAL, default is an empty Local-part followed by an "@"

followed by the domain from the "d=" tag). The syntax is a

standard email address where the Local-part MAY be omitted. The

domain part of the address MUST be the same as or a subdomain of

the value of the "d=" tag.

Internationalized domain names MUST be converted using the steps

listed in Section 4 of [RFC3490] using the "ToASCII" function.

ABNF:

sig-i-tag = %x69 [FWS] "=" [FWS] [ Local-part ] "@" domain-name

INFORMATIVE NOTE: The Local-part of the "i=" tag is optional

because in some cases a signer may not be able to establish a

verified individual identity. In such cases, the signer may

wish to assert that although it is willing to go as far as

signing for the domain, it is unable or unwilling to commit

to an individual user name within their domain. It can do so

by including the domain part but not the Local-part of the

identity.

INFORMATIVE DISCUSSION: This document does not require the value

of the "i=" tag to match the identity in any message header

fields. This is considered to be a verifier policy issue.

Constraints between the value of the "i=" tag and other

identities in other header fields seek to apply basic

authentication into the semantics of trust associated with a

role such as content author. Trust is a broad and complex

topic and trust mechanisms are subject to highly creative

attacks. The real-world efficacy of any but the most basic

bindings between the "i=" value and other identities is not

well established, nor is its vulnerability to subversion by

an attacker. Hence reliance on the use of these options

should be strictly limited. In particular, it is not at all

clear to what extent a typical end-user recipient can rely on

any assurances that might be made by successful use of the

"i=" options.

l= Body length count (plain-text unsigned decimal integer; OPTIONAL,

default is entire body). This tag informs the verifier of the

number of octets in the body of the email after canonicalization

included in the cryptographic hash, starting from 0 immediately

following the CRLF preceding the body. This value MUST NOT be

larger than the actual number of octets in the canonicalized

message body.

Allman, et al. Standards Track [Page 21]

RFC 4871 DKIM Signatures May 2007

INFORMATIVE IMPLEMENTATION WARNING: Use of the "l=" tag might

allow display of fraudulent content without appropriate

warning to end users. The "l=" tag is intended for

increasing signature robustness when sending to mailing lists

that both modify their content and do not sign their

messages. However, using the "l=" tag enables attacks in

which an intermediary with malicious intent modifies a

message to include content that solely benefits the attacker.

It is possible for the appended content to completely replace

the original content in the end recipient's eyes and to

defeat duplicate message detection algorithms. Examples are

described in Security Considerations (Section 8). To avoid

this attack, signers should be extremely wary of using this

tag, and verifiers might wish to ignore the tag or remove

text that appears after the specified content length.

INFORMATIVE NOTE: The value of the "l=" tag is constrained to 76

decimal digits. This constraint is not intended to predict

the size of future messages or to require implementations to

use an integer representation large enough to represent the

maximum possible value, but is intended to remind the

implementer to check the length of this and all other tags

during verification and to test for integer overflow when

decoding the value. Implementers may need to limit the

actual value expressed to a value smaller than 10^76, e.g.,

to allow a message to fit within the available storage space.

ABNF:

sig-l-tag = %x6c [FWS] "=" [FWS] 1*76DIGIT

q= A colon-separated list of query methods used to retrieve the

public key (plain-text; OPTIONAL, default is "dns/txt"). Each

query method is of the form "type[/options]", where the syntax

and semantics of the options depend on the type and specified

options. If there are multiple query mechanisms listed, the

choice of query mechanism MUST NOT change the interpretation of

the signature. Implementations MUST use the recognized query

mechanisms in the order presented.

Currently, the only valid value is "dns/txt", which defines the DNS

TXT record lookup algorithm described elsewhere in this document.

The only option defined for the "dns" query type is "txt", which

MUST be included. Verifiers and signers MUST support "dns/txt".

Allman, et al. Standards Track [Page 22]

RFC 4871 DKIM Signatures May 2007

ABNF:

sig-q-tag = %x71 [FWS] "=" [FWS] sig-q-tag-method

*([FWS] ":" [FWS] sig-q-tag-method)

sig-q-tag-method = "dns/txt" / x-sig-q-tag-type

["/" x-sig-q-tag-args]

x-sig-q-tag-type = hyphenated-word ; for future extension

x-sig-q-tag-args = qp-hdr-value

s= The selector subdividing the namespace for the "d=" (domain) tag

(plain-text; REQUIRED).

ABNF:

sig-s-tag = %x73 [FWS] "=" [FWS] selector

t= Signature Timestamp (plain-text unsigned decimal integer;

RECOMMENDED, default is an unknown creation time). The time that

this signature was created. The format is the number of seconds

since 00:00:00 on January 1, 1970 in the UTC time zone. The

value is expressed as an unsigned integer in decimal ASCII. This

value is not constrained to fit into a 31- or 32-bit integer.

Implementations SHOULD be prepared to handle values up to at

least 10^12 (until approximately AD 200,000; this fits into 40

bits). To avoid denial-of-service attacks, implementations MAY

consider any value longer than 12 digits to be infinite. Leap

seconds are not counted. Implementations MAY ignore signatures

that have a timestamp in the future.

ABNF:

sig-t-tag = %x74 [FWS] "=" [FWS] 1*12DIGIT

x= Signature Expiration (plain-text unsigned decimal integer;

RECOMMENDED, default is no expiration). The format is the same

as in the "t=" tag, represented as an absolute date, not as a

time delta from the signing timestamp. The value is expressed as

an unsigned integer in decimal ASCII, with the same constraints

on the value in the "t=" tag. Signatures MAY be considered

invalid if the verification time at the verifier is past the

expiration date. The verification time should be the time that

the message was first received at the administrative domain of

the verifier if that time is reliably available; otherwise the

current time should be used. The value of the "x=" tag MUST be

greater than the value of the "t=" tag if both are present.

Allman, et al. Standards Track [Page 23]

RFC 4871 DKIM Signatures May 2007

INFORMATIVE NOTE: The "x=" tag is not intended as an anti-replay

defense.

ABNF:

sig-x-tag = %x78 [FWS] "=" [FWS] 1*12DIGIT

z= Copied header fields (dkim-quoted-printable, but see description;

OPTIONAL, default is null). A vertical-bar-separated list of

selected header fields present when the message was signed,

including both the field name and value. It is not required to

include all header fields present at the time of signing. This

field need not contain the same header fields listed in the "h="

tag. The header field text itself must encode the vertical bar

("|", %x7C) character (i.e., vertical bars in the "z=" text are

metacharacters, and any actual vertical bar characters in a

copied header field must be encoded). Note that all whitespace

must be encoded, including whitespace between the colon and the

header field value. After encoding, FWS MAY be added at

arbitrary locations in order to avoid excessively long lines;

such whitespace is NOT part of the value of the header field, and

MUST be removed before decoding.

The header fields referenced by the "h=" tag refer to the fields in

the RFC 2822 header of the message, not to any copied fields in

the "z=" tag. Copied header field values are for diagnostic use.

Header fields with characters requiring conversion (perhaps from

legacy MTAs that are not [RFC2822] compliant) SHOULD be converted

as described in MIME Part Three [RFC2047].

ABNF:

sig-z-tag = %x7A [FWS] "=" [FWS] sig-z-tag-copy

*( [FWS] "|" sig-z-tag-copy )

sig-z-tag-copy = hdr-name ":" qp-hdr-value

qp-hdr-value = dkim-quoted-printable ; with "|" encoded

INFORMATIVE EXAMPLE of a signature header field spread across

multiple continuation lines:

Allman, et al. Standards Track [Page 24]

RFC 4871 DKIM Signatures May 2007

DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane;

c=simple; q=dns/txt; i=@eng.example.net;

t=1117574938; x=1118006938;

h=from:to:subject:date;

z=From:foo@eng.example.net|To:joe@example.com|

Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;

bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;

b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ

VoG4ZHRNiYzR

3.6. Key Management and Representation

Signature applications require some level of assurance that the

verification public key is associated with the claimed signer. Many

applications achieve this by using public key certificates issued by

a trusted third party. However, DKIM can achieve a sufficient level

of security, with significantly enhanced scalability, by simply

having the verifier query the purported signer's DNS entry (or some

security-equivalent) in order to retrieve the public key.

DKIM keys can potentially be stored in multiple types of key servers

and in multiple formats. The storage and format of keys are

irrelevant to the remainder of the DKIM algorithm.

Parameters to the key lookup algorithm are the type of the lookup

(the "q=" tag), the domain of the signer (the "d=" tag of the DKIM-

Signature header field), and the selector (the "s=" tag).

public_key = dkim_find_key(q_val, d_val, s_val)

This document defines a single binding, using DNS TXT records to

distribute the keys. Other bindings may be defined in the future.

3.6.1. Textual Representation

It is expected that many key servers will choose to present the keys

in an otherwise unstructured text format (for example, an XML form

would not be considered to be unstructured text for this purpose).

The following definition MUST be used for any DKIM key represented in

an otherwise unstructured textual form.

The overall syntax is a tag-list as described in Section 3.2. The

current valid tags are described below. Other tags MAY be present

and MUST be ignored by any implementation that does not understand

them.

Allman, et al. Standards Track [Page 25]

RFC 4871 DKIM Signatures May 2007

v= Version of the DKIM key record (plain-text; RECOMMENDED, default

is "DKIM1"). If specified, this tag MUST be set

&lt;PRE&gt; Network Working Group E. Allman Request for Comments: 4871 Sendmail, Inc. Obsoletes: 4870 J. Callas Category: Standards Track PGP Corporation M. Delany M. Libbey Yahoo! Inc J. Fenton M. Thomas Cisco Systems, Inc. May 2007 DomainKeys Identified Mail (DKIM) Signatures Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the &quot;Internet Official Protocol Standards&quot; (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). The ultimate goal of this framework is to permit a signing domain to assert responsibility for a message, thus protecting message signer identity and the integrity of the messages they convey while retaining the functionality of Internet email as it is known today. Protection of email identity may assist in the global control of &quot;spam&quot; and &quot;phishing&quot;. Allman, et al. Standards Track [Page 1] RFC 4871 DKIM Signatures May 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Signing Identity . . . . . . . . . . . . . . . . . . . . . 5 1.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Simple Key Management . . . . . . . . . . . . . . . . . . 5 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 2.1. Signers . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Verifiers . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Whitespace . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4. Common ABNF Tokens . . . . . . . . . . . . . . . . . . . . 6 2.5. Imported ABNF Tokens . . . . . . . . . . . . . . . . . . . 7 2.6. DKIM-Quoted-Printable . . . . . . . . . . . . . . . . . . 7 3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Tag=Value Lists . . . . . . . . . . . . . . . . . . . . . 10 3.3. Signing and Verification Algorithms . . . . . . . . . . . 11 3.4. Canonicalization . . . . . . . . . . . . . . . . . . . . . 13 3.5. The DKIM-Signature Header Field . . . . . . . . . . . . . 17 3.6. Key Management and Representation . . . . . . . . . . . . 25 3.7. Computing the Message Hashes . . . . . . . . . . . . . . . 29 3.8. Signing by Parent Domains . . . . . . . . . . . . . . . . 31 4. Semantics of Multiple Signatures . . . . . . . . . . . . . . . 32 4.1. Example Scenarios . . . . . . . . . . . . . . . . . . . . 32 4.2. Interpretation . . . . . . . . . . . . . . . . . . . . . . 33 5. Signer Actions . . . . . . . . . . . . . . . . . . . . . . . . 34 5.1. Determine Whether the Email Should Be Signed and by Whom . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.2. Select a Private Key and Corresponding Selector Information . . . . . . . . . . . . . . . . . . . . . . . 35 5.3. Normalize the Message to Prevent Transport Conversions . . 35 5.4. Determine the Header Fields to Sign . . . . . . . . . . . 36 5.5. Recommended Signature Content . . . . . . . . . . . . . . 38 5.6. Compute the Message Hash and Signature . . . . . . . . . . 39 5.7. Insert the DKIM-Signature Header Field . . . . . . . . . . 40 6. Verifier Actions . . . . . . . . . . . . . . . . . . . . . . . 40 6.1. Extract Signatures from the Message . . . . . . . . . . . 41 6.2. Communicate Verification Results . . . . . . . . . . . . . 46 6.3. Interpret Results/Apply Local Policy . . . . . . . . . . . 47 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 7.1. DKIM-Signature Tag Specifications . . . . . . . . . . . . 48 7.2. DKIM-Signature Query Method Registry . . . . . . . . . . . 49 7.3. DKIM-Signature Canonicalization Registry . . . . . . . . . 49 7.4. _domainkey DNS TXT Record Tag Specifications . . . . . . . 50 7.5. DKIM Key Type Registry . . . . . . . . . . . . . . . . . . 50 7.6. DKIM Hash Algorithms Registry . . . . . . . . . . . . . . 51 7.7. DKIM Service Types Registry . . . . . . . . . . . . . . . 51 7.8. DKIM Selector Flags Registry . . . . . . . . . . . . . . . 52 Allman, et al. Standards Track [Page 2] RFC 4871 DKIM Signatures May 2007 7.9. DKIM-Signature Header Field . . . . . . . . . . . . . . . 52 8. Security Considerations . . . . . . . . . . . . . . . . . . . 52 8.1. Misuse of Body Length Limits (&quot;l=&quot; Tag) . . . . . . . . . 52 8.2. Misappropriated Private Key . . . . . . . . . . . . . . . 53 8.3. Key Server Denial-of-Service Attacks . . . . . . . . . . . 54 8.4. Attacks Against the DNS . . . . . . . . . . . . . . . . . 54 8.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 55 8.6. Limits on Revoking Keys . . . . . . . . . . . . . . . . . 55 8.7. Intentionally Malformed Key Records . . . . . . . . . . . 56 8.8. Intentionally Malformed DKIM-Signature Header Fields . . . 56 8.9. Information Leakage . . . . . . . . . . . . . . . . . . . 56 8.10. Remote Timing Attacks . . . . . . . . . . . . . . . . . . 56 8.11. Reordered Header Fields . . . . . . . . . . . . . . . . . 56 8.12. RSA Attacks . . . . . . . . . . . . . . . . . . . . . . . 56 8.13. Inappropriate Signing by Parent Domains . . . . . . . . . 57 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 57 9.1. Normative References . . . . . . . . . . . . . . . . . . . 57 9.2. Informative References . . . . . . . . . . . . . . . . . . 58 Appendix A. Example of Use (INFORMATIVE) . . . . . . . . . . . . 60 A.1. The user composes an email . . . . . . . . . . . . . . . . 60 A.2. The email is signed . . . . . . . . . . . . . . . . . . . 61 A.3. The email signature is verified . . . . . . . . . . . . . 61 Appendix B. Usage Examples (INFORMATIVE) . . . . . . . . . . . . 62 B.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 63 B.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 65 Appendix C. Creating a Public Key (INFORMATIVE) . . . . . . . . . 67 Appendix D. MUA Considerations . . . . . . . . . . . . . . . . . 68 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 69 Allman, et al. Standards Track [Page 3] RFC 4871 DKIM Signatures May 2007 1. Introduction DomainKeys Identified Mail (DKIM) defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the introduction of a message into the mail stream. Message recipients can verify the signature by querying the signer&#039;s domain directly to retrieve the appropriate public key, and thereby confirm that the message was attested to by a party in possession of the private key for the signing domain. The approach taken by DKIM differs from previous approaches to message signing (e.g., Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC1847], OpenPGP [RFC2440]) in that: o the message signature is written as a message header field so that neither human recipients nor existing MUA (Mail User Agent) software is confused by signature-related content appearing in the message body; o there is no dependency on public and private key pairs being issued by well-known, trusted certificate authorities; o there is no dependency on the deployment of any new Internet protocols or services for public key distribution or revocation; o signature verification failure does not force rejection of the message; o no attempt is made to include encryption as part of the mechanism; o message archiving is not a design goal. DKIM: o is compatible with the existing email infrastructure and transparent to the fullest extent possible; o requires minimal new infrastructure; o can be implemented independently of clients in order to reduce deployment time; o can be deployed incrementally; o allows delegation of signing to third parties. Allman, et al. Standards Track [Page 4] RFC 4871 DKIM Signatures May 2007 1.1. Signing Identity DKIM separates the question of the identity of the signer of the message from the purported author of the message. In particular, a signature includes the identity of the signer. Verifiers can use the signing information to decide how they want to process the message. The signing identity is included as part of the signature header field. INFORMATIVE RATIONALE: The signing identity specified by a DKIM signature is not required to match an address in any particular header field because of the broad methods of interpretation by recipient mail systems, including MUAs. 1.2. Scalability DKIM is designed to support the extreme scalability requirements that characterize the email identification problem. There are currently over 70 million domains and a much larger number of individual addresses. DKIM seeks to preserve the positive aspects of the current email infrastructure, such as the ability for anyone to communicate with anyone else without introduction. 1.3. Simple Key Management DKIM differs from traditional hierarchical public-key systems in that no Certificate Authority infrastructure is required; the verifier requests the public key from a repository in the domain of the claimed signer directly rather than from a third party. The DNS is proposed as the initial mechanism for the public keys. Thus, DKIM currently depends on DNS administration and the security of the DNS system. DKIM is designed to be extensible to other key fetching services as they become available. 2. Terminology and Definitions This section defines terms used in the rest of the document. Syntax descriptions use the form described in Augmented BNF for Syntax Specifications [RFC4234]. The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this document are to be interpreted as described in [RFC2119]. Allman, et al. Standards Track [Page 5] RFC 4871 DKIM Signatures May 2007 2.1. Signers Elements in the mail system that sign messages on behalf of a domain are referred to as signers. These may be MUAs (Mail User Agents), MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other agents such as mailing list exploders. In general, any signer will be involved in the injection of a message into the message system in some way. The key issue is that a message must be signed before it leaves the administrative domain of the signer. 2.2. Verifiers Elements in the mail system that verify signatures are referred to as verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. In most cases it is expected that verifiers will be close to an end user (reader) of the message or some consuming agent such as a mailing list exploder. 2.3. Whitespace There are three forms of whitespace: o WSP represents simple whitespace, i.e., a space or a tab character (formal definition in [RFC4234]). o LWSP is linear whitespace, defined as WSP plus CRLF (formal definition in [RFC4234]). o FWS is folding whitespace. It allows multiple lines separated by CRLF followed by at least one whitespace, to be joined. The formal ABNF for these are (WSP and LWSP are given for information only): WSP = SP / HTAB LWSP = *(WSP / CRLF WSP) FWS = [*WSP CRLF] 1*WSP The definition of FWS is identical to that in [RFC2822] except for the exclusion of obs-FWS. 2.4. Common ABNF Tokens The following ABNF tokens are used elsewhere in this document: hyphenated-word = ALPHA [ *(ALPHA / DIGIT / &quot;-&quot;) (ALPHA / DIGIT) ] base64string = 1*(ALPHA / DIGIT / &quot;+&quot; / &quot;/&quot; / [FWS]) [ &quot;=&quot; [FWS] [ &quot;=&quot; [FWS] ] ] Allman, et al. Standards Track [Page 6] RFC 4871 DKIM Signatures May 2007 2.5. Imported ABNF Tokens The following tokens are imported from other RFCs as noted. Those RFCs should be considered definitive. The following tokens are imported from [RFC2821]: o &quot;Local-part&quot; (implementation warning: this permits quoted strings) o &quot;sub-domain&quot; The following tokens are imported from [RFC2822]: o &quot;field-name&quot; (name of a header field) o &quot;dot-atom-text&quot; (in the Local-part of an email address) The following tokens are imported from [RFC2045]: o &quot;qp-section&quot; (a single line of quoted-printable-encoded text) o &quot;hex-octet&quot; (a quoted-printable encoded octet) INFORMATIVE NOTE: Be aware that the ABNF in RFC 2045 does not obey the rules of RFC 4234 and must be interpreted accordingly, particularly as regards case folding. Other tokens not defined herein are imported from [RFC4234]. These are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, etc. 2.6. DKIM-Quoted-Printable The DKIM-Quoted-Printable encoding syntax resembles that described in Quoted-Printable [RFC2045], Section 6.7: any character MAY be encoded as an &quot;=&quot; followed by two hexadecimal digits from the alphabet &quot;0123456789ABCDEF&quot; (no lowercase characters permitted) representing the hexadecimal-encoded integer value of that character. All control characters (those with values &amp;lt; %x20), 8-bit characters (values &amp;gt; %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon (&quot;;&quot;, %x3B) MUST be encoded. Note that all whitespace, including SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value, and MUST be removed before decoding. Allman, et al. Standards Track [Page 7] RFC 4871 DKIM Signatures May 2007 ABNF: dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char) ; hex-octet is from RFC 2045 dkim-safe-char = %x21-3A / %x3C / %x3E-7E ; &#039;!&#039; - &#039;:&#039;, &#039;&amp;lt;&#039;, &#039;&amp;gt;&#039; - &#039;~&#039; ; Characters not listed as &quot;mail-safe&quot; in ; RFC 2049 are also not recommended. INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted- Printable as defined in RFC 2045 in several important ways: 1. Whitespace in the input text, including CR and LF, must be encoded. RFC 2045 does not require such encoding, and does not permit encoding of CR or LF characters that are part of a CRLF line break. 2. Whitespace in the encoded text is ignored. This is to allow tags encoded using DKIM-Quoted-Printable to be wrapped as needed. In particular, RFC 2045 requires that line breaks in the input be represented as physical line breaks; that is not the case here. 3. The &quot;soft line break&quot; syntax (&quot;=&quot; as the last non-whitespace character on the line) does not apply. 4. DKIM-Quoted-Printable does not require that encoded lines be no more than 76 characters long (although there may be other requirements depending on the context in which the encoded text is being used). 3. Protocol Elements Protocol Elements are conceptual parts of the protocol that are not specific to either signers or verifiers. The protocol descriptions for signers and verifiers are described in later sections (Signer Actions (Section 5) and Verifier Actions (Section 6)). NOTE: This section must be read in the context of those sections. 3.1. Selectors To support multiple concurrent public keys per signing domain, the key namespace is subdivided using &quot;selectors&quot;. For example, selectors might indicate the names of office locations (e.g., &quot;sanfrancisco&quot;, &quot;coolumbeach&quot;, and &quot;reykjavik&quot;), the signing date (e.g., &quot;january2005&quot;, &quot;february2005&quot;, etc.), or even the individual user. Allman, et al. Standards Track [Page 8] RFC 4871 DKIM Signatures May 2007 Selectors are needed to support some important use cases. For example: o Domains that want to delegate signing capability for a specific address for a given duration to a partner, such as an advertising provider or other outsourced function. o Domains that want to allow frequent travelers to send messages locally without the need to connect with a particular MSA. o &quot;Affinity&quot; domains (e.g., college alumni associations) that provide forwarding of incoming mail, but that do not operate a mail submission agent for outgoing mail. Periods are allowed in selectors and are component separators. When keys are retrieved from the DNS, periods in selectors define DNS label boundaries in a manner similar to the conventional use in domain names. Selector components might be used to combine dates with locations, for example, &quot;march2005.reykjavik&quot;. In a DNS implementation, this can be used to allow delegation of a portion of the selector namespace. ABNF: selector = sub-domain *( &quot;.&quot; sub-domain ) The number of public keys and corresponding selectors for each domain is determined by the domain owner. Many domain owners will be satisfied with just one selector, whereas administratively distributed organizations may choose to manage disparate selectors and key pairs in different regions or on different email servers. Beyond administrative convenience, selectors make it possible to seamlessly replace public keys on a routine basis. If a domain wishes to change from using a public key associated with selector &quot;january2005&quot; to a public key associated with selector &quot;february2005&quot;, it merely makes sure that both public keys are advertised in the public-key repository concurrently for the transition period during which email may be in transit prior to verification. At the start of the transition period, the outbound email servers are configured to sign with the &quot;february2005&quot; private key. At the end of the transition period, the &quot;january2005&quot; public key is removed from the public-key repository. INFORMATIVE NOTE: A key may also be revoked as described below. The distinction between revoking and removing a key selector record is subtle. When phasing out keys as described above, a signing domain would probably simply remove the key record after Allman, et al. Standards Track [Page 9] RFC 4871 DKIM Signatures May 2007 the transition period. However, a signing domain could elect to revoke the key (but maintain the key record) for a further period. There is no defined semantic difference between a revoked key and a removed key. While some domains may wish to make selector values well known, others will want to take care not to allocate selector names in a way that allows harvesting of data by outside parties. For example, if per-user keys are issued, the domain owner will need to make the decision as to whether to associate this selector directly with the user name, or make it some unassociated random value, such as a fingerprint of the public key. INFORMATIVE OPERATIONS NOTE: Reusing a selector with a new key (for example, changing the key associated with a user&#039;s name) makes it impossible to tell the difference between a message that didn&#039;t verify because the key is no longer valid versus a message that is actually forged. For this reason, signers are ill-advised to reuse selectors for new keys. A better strategy is to assign new keys to new selectors. 3.2. Tag=Value Lists DKIM uses a simple &quot;tag=value&quot; syntax in several contexts, including in messages and domain signature records. Values are a series of strings containing either plain text, &quot;base64&quot; text (as defined in [RFC2045], Section 6.8), &quot;qp-section&quot; (ibid, Section 6.7), or &quot;dkim-quoted-printable&quot; (as defined in Section 2.6). The name of the tag will determine the encoding of each value. Unencoded semicolon (&quot;;&quot;) characters MUST NOT occur in the tag value, since that separates tag-specs. INFORMATIVE IMPLEMENTATION NOTE: Although the &quot;plain text&quot; defined below (as &quot;tag-value&quot;) only includes 7-bit characters, an implementation that wished to anticipate future standards would be advised not to preclude the use of UTF8-encoded text in tag=value lists. Allman, et al. Standards Track [Page 10] RFC 4871 DKIM Signatures May 2007 Formally, the syntax rules are as follows: tag-list = tag-spec 0*( &quot;;&quot; tag-spec ) [ &quot;;&quot; ] tag-spec = [FWS] tag-name [FWS] &quot;=&quot; [FWS] tag-value [FWS] tag-name = ALPHA 0*ALNUMPUNC tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] ; WSP and FWS prohibited at beginning and end tval = 1*VALCHAR VALCHAR = %x21-3A / %x3C-7E ; EXCLAMATION to TILDE except SEMICOLON ALNUMPUNC = ALPHA / DIGIT / &quot;_&quot; Note that WSP is allowed anywhere around tags. In particular, any WSP after the &quot;=&quot; and any WSP before the terminating &quot;;&quot; is not part of the value; however, WSP inside the value is significant. Tags MUST be interpreted in a case-sensitive manner. Values MUST be processed as case sensitive unless the specific tag description of semantics specifies case insensitivity. Tags with duplicate names MUST NOT occur within a single tag-list; if a tag name does occur more than once, the entire tag-list is invalid. Whitespace within a value MUST be retained unless explicitly excluded by the specific tag description. Tag=value pairs that represent the default value MAY be included to aid legibility. Unrecognized tags MUST be ignored. Tags that have an empty value are not the same as omitted tags. An omitted tag is treated as having the default value; a tag with an empty value explicitly designates the empty string as the value. For example, &quot;g=&quot; does not mean &quot;g=*&quot;, even though &quot;g=*&quot; is the default for that tag. 3.3. Signing and Verification Algorithms DKIM supports multiple digital signature algorithms. Two algorithms are defined by this specification at this time: rsa-sha1 and rsa- sha256. The rsa-sha256 algorithm is the default if no algorithm is specified. Verifiers MUST implement both rsa-sha1 and rsa-sha256. Signers MUST implement and SHOULD sign using rsa-sha256. Allman, et al. Standards Track [Page 11] RFC 4871 DKIM Signatures May 2007 INFORMATIVE NOTE: Although sha256 is strongly encouraged, some senders of low-security messages (such as routine newsletters) may prefer to use sha1 because of reduced CPU requirements to compute a sha1 hash. In general, sha256 should always be used whenever possible. 3.3.1. The rsa-sha1 Signing Algorithm The rsa-sha1 Signing Algorithm computes a message hash as described in Section 3.7 below using SHA-1 [FIPS.180-2.2002] as the hash-alg. That hash is then signed by the signer using the RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer&#039;s private key. The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed. The signing algorithm SHOULD use a public exponent of 65537. 3.3.2. The rsa-sha256 Signing Algorithm The rsa-sha256 Signing Algorithm computes a message hash as described in Section 3.7 below using SHA-256 [FIPS.180-2.2002] as the hash-alg. That hash is then signed by the signer using the RSA algorithm (defined in PKCS#1 version 1.5 [RFC3447]) as the crypt-alg and the signer&#039;s private key. The hash MUST NOT be truncated or converted into any form other than the native binary form before being signed. 3.3.3. Key Sizes Selecting appropriate key sizes is a trade-off between cost, performance, and risk. Since short RSA keys more easily succumb to off-line attacks, signers MUST use RSA keys of at least 1024 bits for long-lived keys. Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits, and they MAY be able to validate signatures with larger keys. Verifier policies may use the length of the signing key as one metric for determining whether a signature is acceptable. Factors that should influence the key size choice include the following: o The practical constraint that large (e.g., 4096 bit) keys may not fit within a 512-byte DNS UDP response packet o The security constraint that keys smaller than 1024 bits are subject to off-line attacks o Larger keys impose higher CPU costs to verify and sign email Allman, et al. Standards Track [Page 12] RFC 4871 DKIM Signatures May 2007 o Keys can be replaced on a regular basis, thus their lifetime can be relatively short o The security goals of this specification are modest compared to typical goals of other systems that employ digital signatures See [RFC3766] for further discussion on selecting key sizes. 3.3.4. Other Algorithms Other algorithms MAY be defined in the future. Verifiers MUST ignore any signatures using algorithms that they do not implement. 3.4. Canonicalization Empirical evidence demonstrates that some mail servers and relay systems modify email in transit, potentially invalidating a signature. There are two competing perspectives on such modifications. For most signers, mild modification of email is immaterial to the authentication status of the email. For such signers, a canonicalization algorithm that survives modest in-transit modification is preferred. Other signers demand that any modification of the email, however minor, result in a signature verification failure. These signers prefer a canonicalization algorithm that does not tolerate in-transit modification of the signed email. Some signers may be willing to accept modifications to header fields that are within the bounds of email standards such as [RFC2822], but are unwilling to accept any modification to the body of messages. To satisfy all requirements, two canonicalization algorithms are defined for each of the header and the body: a &quot;simple&quot; algorithm that tolerates almost no modification and a &quot;relaxed&quot; algorithm that tolerates common modifications such as whitespace replacement and header field line rewrapping. A signer MAY specify either algorithm for header or body when signing an email. If no canonicalization algorithm is specified by the signer, the &quot;simple&quot; algorithm defaults for both header and body. Verifiers MUST implement both canonicalization algorithms. Note that the header and body may use different canonicalization algorithms. Further canonicalization algorithms MAY be defined in the future; verifiers MUST ignore any signatures that use unrecognized canonicalization algorithms. Canonicalization simply prepares the email for presentation to the signing or verification algorithm. It MUST NOT change the Allman, et al. Standards Track [Page 13] RFC 4871 DKIM Signatures May 2007 transmitted data in any way. Canonicalization of header fields and body are described below. NOTE: This section assumes that the message is already in &quot;network normal&quot; format (text is ASCII encoded, lines are separated with CRLF characters, etc.). See also Section 5.3 for information about normalizing the message. 3.4.1. The &quot;simple&quot; Header Canonicalization Algorithm The &quot;simple&quot; header canonicalization algorithm does not change header fields in any way. Header fields MUST be presented to the signing or verification algorithm exactly as they are in the message being signed or verified. In particular, header field names MUST NOT be case folded and whitespace MUST NOT be changed. 3.4.2. The &quot;relaxed&quot; Header Canonicalization Algorithm The &quot;relaxed&quot; header canonicalization algorithm MUST apply the following steps in order: o Convert all header field names (not the header field values) to lowercase. For example, convert &quot;SUBJect: AbC&quot; to &quot;subject: AbC&quot;. o Unfold all header field continuation lines as described in [RFC2822]; in particular, lines with terminators embedded in continued header field values (that is, CRLF sequences followed by WSP) MUST be interpreted without the CRLF. Implementations MUST NOT remove the CRLF at the end of the header field value. o Convert all sequences of one or more WSP characters to a single SP character. WSP characters here include those before and after a line folding boundary. o Delete all WSP characters at the end of each unfolded header field value. o Delete any WSP characters remaining before and after the colon separating the header field name from the header field value. The colon separator MUST be retained. 3.4.3. The &quot;simple&quot; Body Canonicalization Algorithm The &quot;simple&quot; body canonicalization algorithm ignores all empty lines at the end of the message body. An empty line is a line of zero length after removal of the line terminator. If there is no body or no trailing CRLF on the message body, a CRLF is added. It makes no Allman, et al. Standards Track [Page 14] RFC 4871 DKIM Signatures May 2007 other changes to the message body. In more formal terms, the &quot;simple&quot; body canonicalization algorithm converts &quot;0*CRLF&quot; at the end of the body to a single &quot;CRLF&quot;. Note that a completely empty or missing body is canonicalized as a single &quot;CRLF&quot;; that is, the canonicalized length will be 2 octets. 3.4.4. The &quot;relaxed&quot; Body Canonicalization Algorithm The &quot;relaxed&quot; body canonicalization algorithm: o Ignores all whitespace at the end of lines. Implementations MUST NOT remove the CRLF at the end of the line. o Reduces all sequences of WSP within a line to a single SP character. o Ignores all empty lines at the end of the message body. &quot;Empty line&quot; is defined in Section 3.4.3. INFORMATIVE NOTE: It should be noted that the relaxed body canonicalization algorithm may enable certain types of extremely crude &quot;ASCII Art&quot; attacks where a message may be conveyed by adjusting the spacing between words. If this is a concern, the &quot;simple&quot; body canonicalization algorithm should be used instead. 3.4.5. Body Length Limits A body length count MAY be specified to limit the signature calculation to an initial prefix of the body text, measured in octets. If the body length count is not specified, the entire message body is signed. INFORMATIVE RATIONALE: This capability is provided because it is very common for mailing lists to add trailers to messages (e.g., instructions how to get off the list). Until those messages are also signed, the body length count is a useful tool for the verifier since it may as a matter of policy accept messages having valid signatures with extraneous data. INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables an attack in which an attacker modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient&#039;s eyes and to defeat duplicate message detection algorithms. To avoid this attack, signers should be wary of using Allman, et al. Standards Track [Page 15] RFC 4871 DKIM Signatures May 2007 this tag, and verifiers might wish to ignore the tag or remove text that appears after the specified content length, perhaps based on other criteria. The body length count allows the signer of a message to permit data to be appended to the end of the body of a signed message. The body length count MUST be calculated following the canonicalization algorithm; for example, any whitespace ignored by a canonicalization algorithm is not included as part of the body length count. Signers of MIME messages that include a body length count SHOULD be sure that the length extends to the closing MIME boundary string. INFORMATIVE IMPLEMENTATION NOTE: A signer wishing to ensure that the only acceptable modifications are to add to the MIME postlude would use a body length count encompassing the entire final MIME boundary string, including the final &quot;--CRLF&quot;. A signer wishing to allow additional MIME parts but not modification of existing parts would use a body length count extending through the final MIME boundary string, omitting the final &quot;--CRLF&quot;. Note that this only works for some MIME types, e.g., multipart/mixed but not multipart/signed. A body length count of zero means that the body is completely unsigned. Signers wishing to ensure that no modification of any sort can occur should specify the &quot;simple&quot; canonicalization algorithm for both header and body and omit the body length count. 3.4.6. Canonicalization Examples (INFORMATIVE) In the following examples, actual whitespace is used only for clarity. The actual input and output text is designated using bracketed descriptors: &quot;&lt;SP&gt;&quot; for a space character, &quot;&lt;HTAB&gt;&quot; for a tab character, and &quot;&lt;CRLF&gt;&quot; for a carriage-return/line-feed sequence. For example, &quot;X &lt;SP&gt; Y&quot; and &quot;X&lt;SP&gt;Y&quot; represent the same three characters. Example 1: A message reading: A: &lt;SP&gt; X &lt;CRLF&gt; B &lt;SP&gt; : &lt;SP&gt; Y &lt;HTAB&gt;&lt;CRLF&gt; &lt;HTAB&gt; Z &lt;SP&gt;&lt;SP&gt;&lt;CRLF&gt; &lt;CRLF&gt; &lt;SP&gt; C &lt;SP&gt;&lt;CRLF&gt; D &lt;SP&gt;&lt;HTAB&gt;&lt;SP&gt; E &lt;CRLF&gt; &lt;CRLF&gt; &lt;CRLF&gt; Allman, et al. Standards Track [Page 16] RFC 4871 DKIM Signatures May 2007 when canonicalized using relaxed canonicalization for both header and body results in a header reading: a:X &lt;CRLF&gt; b:Y &lt;SP&gt; Z &lt;CRLF&gt; and a body reading: &lt;SP&gt; C &lt;CRLF&gt; D &lt;SP&gt; E &lt;CRLF&gt; Example 2: The same message canonicalized using simple canonicalization for both header and body results in a header reading: A: &lt;SP&gt; X &lt;CRLF&gt; B &lt;SP&gt; : &lt;SP&gt; Y &lt;HTAB&gt;&lt;CRLF&gt; &lt;HTAB&gt; Z &lt;SP&gt;&lt;SP&gt;&lt;CRLF&gt; and a body reading: &lt;SP&gt; C &lt;SP&gt;&lt;CRLF&gt; D &lt;SP&gt;&lt;HTAB&gt;&lt;SP&gt; E &lt;CRLF&gt; Example 3: When processed using relaxed header canonicalization and simple body canonicalization, the canonicalized version has a header of: a:X &lt;CRLF&gt; b:Y &lt;SP&gt; Z &lt;CRLF&gt; and a body reading: &lt;SP&gt; C &lt;SP&gt;&lt;CRLF&gt; D &lt;SP&gt;&lt;HTAB&gt;&lt;SP&gt; E &lt;CRLF&gt; 3.5. The DKIM-Signature Header Field The signature of the email is stored in the DKIM-Signature header field. This header field contains all of the signature and key- fetching data. The DKIM-Signature value is a tag-list as described in Section 3.2. The DKIM-Signature header field SHOULD be treated as though it were a trace header field as defined in Section 3.6 of [RFC2822], and hence SHOULD NOT be reordered and SHOULD be prepended to the message. Allman, et al. Standards Track [Page 17] RFC 4871 DKIM Signatures May 2007 The DKIM-Signature header field being created or verified is always included in the signature calculation, after the rest of the header fields being signed; however, when calculating or verifying the signature, the value of the &quot;b=&quot; tag (signature value) of that DKIM- Signature header field MUST be treated as though it were an empty string. Unknown tags in the DKIM-Signature header field MUST be included in the signature calculation but MUST be otherwise ignored by verifiers. Other DKIM-Signature header fields that are included in the signature should be treated as normal header fields; in particular, the &quot;b=&quot; tag is not treated specially. The encodings for each field type are listed below. Tags described as qp-section are encoded as described in Section 6.7 of MIME Part One [RFC2045], with the additional conversion of semicolon characters to &quot;=3B&quot;; intuitively, this is one line of quoted-printable encoded text. The dkim-quoted-printable syntax is defined in Section 2.6. Tags on the DKIM-Signature header field along with their type and requirement status are shown below. Unrecognized tags MUST be ignored. v= Version (MUST be included). This tag defines the version of this specification that applies to the signature record. It MUST have the value &quot;1&quot;. Note that verifiers must do a string comparison on this value; for example, &quot;1&quot; is not the same as &quot;1.0&quot;. ABNF: sig-v-tag = %x76 [FWS] &quot;=&quot; [FWS] &quot;1&quot; INFORMATIVE NOTE: DKIM-Signature version numbers are expected to increase arithmetically as new versions of this specification are released. a= The algorithm used to generate the signature (plain-text; REQUIRED). Verifiers MUST support &quot;rsa-sha1&quot; and &quot;rsa-sha256&quot;; signers SHOULD sign using &quot;rsa-sha256&quot;. See Section 3.3 for a description of algorithms. ABNF: sig-a-tag = %x61 [FWS] &quot;=&quot; [FWS] sig-a-tag-alg sig-a-tag-alg = sig-a-tag-k &quot;-&quot; sig-a-tag-h sig-a-tag-k = &quot;rsa&quot; / x-sig-a-tag-k sig-a-tag-h = &quot;sha1&quot; / &quot;sha256&quot; / x-sig-a-tag-h x-sig-a-tag-k = ALPHA *(ALPHA / DIGIT) ; for later extension x-sig-a-tag-h = ALPHA *(ALPHA / DIGIT) ; for later extension Allman, et al. Standards Track [Page 18] RFC 4871 DKIM Signatures May 2007 b= The signature data (base64; REQUIRED). Whitespace is ignored in this value and MUST be ignored when reassembling the original signature. In particular, the signing process can safely insert FWS in this value in arbitrary places to conform to line-length limits. See Signer Actions (Section 5) for how the signature is computed. ABNF: sig-b-tag = %x62 [FWS] &quot;=&quot; [FWS] sig-b-tag-data sig-b-tag-data = base64string bh= The hash of the canonicalized body part of the message as limited by the &quot;l=&quot; tag (base64; REQUIRED). Whitespace is ignored in this value and MUST be ignored when reassembling the original signature. In particular, the signing process can safely insert FWS in this value in arbitrary places to conform to line-length limits. See Section 3.7 for how the body hash is computed. ABNF: sig-bh-tag = %x62 %x68 [FWS] &quot;=&quot; [FWS] sig-bh-tag-data sig-bh-tag-data = base64string c= Message canonicalization (plain-text; OPTIONAL, default is &quot;simple/simple&quot;). This tag informs the verifier of the type of canonicalization used to prepare the message for signing. It consists of two names separated by a &quot;slash&quot; (%d47) character, corresponding to the header and body canonicalization algorithms respectively. These algorithms are described in Section 3.4. If only one algorithm is named, that algorithm is used for the header and &quot;simple&quot; is used for the body. For example, &quot;c=relaxed&quot; is treated the same as &quot;c=relaxed/simple&quot;. ABNF: sig-c-tag = %x63 [FWS] &quot;=&quot; [FWS] sig-c-tag-alg [&quot;/&quot; sig-c-tag-alg] sig-c-tag-alg = &quot;simple&quot; / &quot;relaxed&quot; / x-sig-c-tag-alg x-sig-c-tag-alg = hyphenated-word ; for later extension d= The domain of the signing entity (plain-text; REQUIRED). This is the domain that will be queried for the public key. This domain MUST be the same as or a parent domain of the &quot;i=&quot; tag (the signing identity, as described below), or it MUST meet the requirements for parent domain signing described in Section 3.8. When presented with a signature that does not meet these requirement, verifiers MUST consider the signature invalid. Allman, et al. Standards Track [Page 19] RFC 4871 DKIM Signatures May 2007 Internationalized domain names MUST be encoded as described in [RFC3490]. ABNF: sig-d-tag = %x64 [FWS] &quot;=&quot; [FWS] domain-name domain-name = sub-domain 1*(&quot;.&quot; sub-domain) ; from RFC 2821 Domain, but excluding address-literal h= Signed header fields (plain-text, but see description; REQUIRED). A colon-separated list of header field names that identify the header fields presented to the signing algorithm. The field MUST contain the complete list of header fields in the order presented to the signing algorithm. The field MAY contain names of header fields that do not exist when signed; nonexistent header fields do not contribute to the signature computation (that is, they are treated as the null input, including the header field name, the separating colon, the header field value, and any CRLF terminator). The field MUST NOT include the DKIM-Signature header field that is being created or verified, but may include others. Folding whitespace (FWS) MAY be included on either side of the colon separator. Header field names MUST be compared against actual header field names in a case-insensitive manner. This list MUST NOT be empty. See Section 5.4 for a discussion of choosing header fields to sign. ABNF: sig-h-tag = %x68 [FWS] &quot;=&quot; [FWS] hdr-name 0*( *FWS &quot;:&quot; *FWS hdr-name ) hdr-name = field-name INFORMATIVE EXPLANATION: By &quot;signing&quot; header fields that do not actually exist, a signer can prevent insertion of those header fields before verification. However, since a signer cannot possibly know what header fields might be created in the future, and that some MUAs might present header fields that are embedded inside a message (e.g., as a message/rfc822 content type), the security of this solution is not total. INFORMATIVE EXPLANATION: The exclusion of the header field name and colon as well as the header field value for non-existent header fields prevents an attacker from inserting an actual header field with a null value. Allman, et al. Standards Track [Page 20] RFC 4871 DKIM Signatures May 2007 i= Identity of the user or agent (e.g., a mailing list manager) on behalf of which this message is signed (dkim-quoted-printable; OPTIONAL, default is an empty Local-part followed by an &quot;@&quot; followed by the domain from the &quot;d=&quot; tag). The syntax is a standard email address where the Local-part MAY be omitted. The domain part of the address MUST be the same as or a subdomain of the value of the &quot;d=&quot; tag. Internationalized domain names MUST be converted using the steps listed in Section 4 of [RFC3490] using the &quot;ToASCII&quot; function. ABNF: sig-i-tag = %x69 [FWS] &quot;=&quot; [FWS] [ Local-part ] &quot;@&quot; domain-name INFORMATIVE NOTE: The Local-part of the &quot;i=&quot; tag is optional because in some cases a signer may not be able to establish a verified individual identity. In such cases, the signer may wish to assert that although it is willing to go as far as signing for the domain, it is unable or unwilling to commit to an individual user name within their domain. It can do so by including the domain part but not the Local-part of the identity. INFORMATIVE DISCUSSION: This document does not require the value of the &quot;i=&quot; tag to match the identity in any message header fields. This is considered to be a verifier policy issue. Constraints between the value of the &quot;i=&quot; tag and other identities in other header fields seek to apply basic authentication into the semantics of trust associated with a role such as content author. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the &quot;i=&quot; value and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence reliance on the use of these options should be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the &quot;i=&quot; options. l= Body length count (plain-text unsigned decimal integer; OPTIONAL, default is entire body). This tag informs the verifier of the number of octets in the body of the email after canonicalization included in the cryptographic hash, starting from 0 immediately following the CRLF preceding the body. This value MUST NOT be larger than the actual number of octets in the canonicalized message body. Allman, et al. Standards Track [Page 21] RFC 4871 DKIM Signatures May 2007 INFORMATIVE IMPLEMENTATION WARNING: Use of the &quot;l=&quot; tag might allow display of fraudulent content without appropriate warning to end users. The &quot;l=&quot; tag is intended for increasing signature robustness when sending to mailing lists that both modify their content and do not sign their messages. However, using the &quot;l=&quot; tag enables attacks in which an intermediary with malicious intent modifies a message to include content that solely benefits the attacker. It is possible for the appended content to completely replace the original content in the end recipient&#039;s eyes and to defeat duplicate message detection algorithms. Examples are described in Security Considerations (Section 8). To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag or remove text that appears after the specified content length. INFORMATIVE NOTE: The value of the &quot;l=&quot; tag is constrained to 76 decimal digits. This constraint is not intended to predict the size of future messages or to require implementations to use an integer representation large enough to represent the maximum possible value, but is intended to remind the implementer to check the length of this and all other tags during verification and to test for integer overflow when decoding the value. Implementers may need to limit the actual value expressed to a value smaller than 10^76, e.g., to allow a message to fit within the available storage space. ABNF: sig-l-tag = %x6c [FWS] &quot;=&quot; [FWS] 1*76DIGIT q= A colon-separated list of query methods used to retrieve the public key (plain-text; OPTIONAL, default is &quot;dns/txt&quot;). Each query method is of the form &quot;type[/options]&quot;, where the syntax and semantics of the options depend on the type and specified options. If there are multiple query mechanisms listed, the choice of query mechanism MUST NOT change the interpretation of the signature. Implementations MUST use the recognized query mechanisms in the order presented. Currently, the only valid value is &quot;dns/txt&quot;, which defines the DNS TXT record lookup algorithm described elsewhere in this document. The only option defined for the &quot;dns&quot; query type is &quot;txt&quot;, which MUST be included. Verifiers and signers MUST support &quot;dns/txt&quot;. Allman, et al. Standards Track [Page 22] RFC 4871 DKIM Signatures May 2007 ABNF: sig-q-tag = %x71 [FWS] &quot;=&quot; [FWS] sig-q-tag-method *([FWS] &quot;:&quot; [FWS] sig-q-tag-method) sig-q-tag-method = &quot;dns/txt&quot; / x-sig-q-tag-type [&quot;/&quot; x-sig-q-tag-args] x-sig-q-tag-type = hyphenated-word ; for future extension x-sig-q-tag-args = qp-hdr-value s= The selector subdividing the namespace for the &quot;d=&quot; (domain) tag (plain-text; REQUIRED). ABNF: sig-s-tag = %x73 [FWS] &quot;=&quot; [FWS] selector t= Signature Timestamp (plain-text unsigned decimal integer; RECOMMENDED, default is an unknown creation time). The time that this signature was created. The format is the number of seconds since 00:00:00 on January 1, 1970 in the UTC time zone. The value is expressed as an unsigned integer in decimal ASCII. This value is not constrained to fit into a 31- or 32-bit integer. Implementations SHOULD be prepared to handle values up to at least 10^12 (until approximately AD 200,000; this fits into 40 bits). To avoid denial-of-service attacks, implementations MAY consider any value longer than 12 digits to be infinite. Leap seconds are not counted. Implementations MAY ignore signatures that have a timestamp in the future. ABNF: sig-t-tag = %x74 [FWS] &quot;=&quot; [FWS] 1*12DIGIT x= Signature Expiration (plain-text unsigned decimal integer; RECOMMENDED, default is no expiration). The format is the same as in the &quot;t=&quot; tag, represented as an absolute date, not as a time delta from the signing timestamp. The value is expressed as an unsigned integer in decimal ASCII, with the same constraints on the value in the &quot;t=&quot; tag. Signatures MAY be considered invalid if the verification time at the verifier is past the expiration date. The verification time should be the time that the message was first received at the administrative domain of the verifier if that time is reliably available; otherwise the current time should be used. The value of the &quot;x=&quot; tag MUST be greater than the value of the &quot;t=&quot; tag if both are present. Allman, et al. Standards Track [Page 23] RFC 4871 DKIM Signatures May 2007 INFORMATIVE NOTE: The &quot;x=&quot; tag is not intended as an anti-replay defense. ABNF: sig-x-tag = %x78 [FWS] &quot;=&quot; [FWS] 1*12DIGIT z= Copied header fields (dkim-quoted-printable, but see description; OPTIONAL, default is null). A vertical-bar-separated list of selected header fields present when the message was signed, including both the field name and value. It is not required to include all header fields present at the time of signing. This field need not contain the same header fields listed in the &quot;h=&quot; tag. The header field text itself must encode the vertical bar (&quot;|&quot;, %x7C) character (i.e., vertical bars in the &quot;z=&quot; text are metacharacters, and any actual vertical bar characters in a copied header field must be encoded). Note that all whitespace must be encoded, including whitespace between the colon and the header field value. After encoding, FWS MAY be added at arbitrary locations in order to avoid excessively long lines; such whitespace is NOT part of the value of the header field, and MUST be removed before decoding. The header fields referenced by the &quot;h=&quot; tag refer to the fields in the RFC 2822 header of the message, not to any copied fields in the &quot;z=&quot; tag. Copied header field values are for diagnostic use. Header fields with characters requiring conversion (perhaps from legacy MTAs that are not [RFC2822] compliant) SHOULD be converted as described in MIME Part Three [RFC2047]. ABNF: sig-z-tag = %x7A [FWS] &quot;=&quot; [FWS] sig-z-tag-copy *( [FWS] &quot;|&quot; sig-z-tag-copy ) sig-z-tag-copy = hdr-name &quot;:&quot; qp-hdr-value qp-hdr-value = dkim-quoted-printable ; with &quot;|&quot; encoded INFORMATIVE EXAMPLE of a signature header field spread across multiple continuation lines: Allman, et al. Standards Track [Page 24] RFC 4871 DKIM Signatures May 2007 DKIM-Signature: a=rsa-sha256; d=example.net; s=brisbane; c=simple; q=dns/txt; i=@eng.example.net; t=1117574938; x=1118006938; h=from:to:subject:date; z=From:foo@eng.example.net|To:joe@example.com| Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ VoG4ZHRNiYzR 3.6. Key Management and Representation Signature applications require some level of assurance that the verification public key is associated with the claimed signer. Many applications achieve this by using public key certificates issued by a trusted third party. However, DKIM can achieve a sufficient level of security, with significantly enhanced scalability, by simply having the verifier query the purported signer&#039;s DNS entry (or some security-equivalent) in order to retrieve the public key. DKIM keys can potentially be stored in multiple types of key servers and in multiple formats. The storage and format of keys are irrelevant to the remainder of the DKIM algorithm. Parameters to the key lookup algorithm are the type of the lookup (the &quot;q=&quot; tag), the domain of the signer (the &quot;d=&quot; tag of the DKIM- Signature header field), and the selector (the &quot;s=&quot; tag). public_key = dkim_find_key(q_val, d_val, s_val) This document defines a single binding, using DNS TXT records to distribute the keys. Other bindings may be defined in the future. 3.6.1. Textual Representation It is expected that many key servers will choose to present the keys in an otherwise unstructured text format (for example, an XML form would not be considered to be unstructured text for this purpose). The following definition MUST be used for any DKIM key represented in an otherwise unstructured textual form. The overall syntax is a tag-list as described in Section 3.2. The current valid tags are described below. Other tags MAY be present and MUST be ignored by any implementation that does not understand them. Allman, et al. Standards Track [Page 25] RFC 4871 DKIM Signatures May 2007 v= Version of the DKIM key record (plain-text; RECOMMENDED, default is &quot;DKIM1&quot;). If specified, this tag MUST be set to &quot;DKIM1&quot; (without the quotes). This tag MUST be the first tag in the record. Records beginning with a &quot;v=&quot; tag with any other value MUST be discarded. Note that verifiers must do a string comparison on this value; for example, &quot;DKIM1&quot; is not the same as &quot;DKIM1.0&quot;. ABNF: key-v-tag = %x76 [FWS] &quot;=&quot; [FWS] &quot;DKIM1&quot; g= Granularity of the key (plain-text; OPTIONAL, default is &quot;*&quot;). This value MUST match the Local-part of the &quot;i=&quot; tag of the DKIM- Signature header field (or its default value of the empty string if &quot;i=&quot; is not specified), with a single, optional &quot;*&quot; character matching a sequence of zero or more arbitrary characters (&quot;wildcarding&quot;). An email with a signing address that does not match the value of this tag constitutes a failed verification. The intent of this tag is to constrain which signing address can legitimately use this selector, for example, when delegating a key to a third party that should only be used for special purposes. Wildcarding allows matching for addresses such as &quot;user+*&quot; or &quot;*-offer&quot;. An empty &quot;g=&quot; value never matches any addresses. ABNF: key-g-tag = %x67 [FWS] &quot;=&quot; [FWS] key-g-tag-lpart key-g-tag-lpart = [dot-atom-text] [&quot;*&quot; [dot-atom-text] ] h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults to allowing all algorithms). A colon-separated list of hash algorithms that might be used. Signers and Verifiers MUST support the &quot;sha256&quot; hash algorithm. Verifiers MUST also support the &quot;sha1&quot; hash algorithm. ABNF: key-h-tag = %x68 [FWS] &quot;=&quot; [FWS] key-h-tag-alg 0*( [FWS] &quot;:&quot; [FWS] key-h-tag-alg ) key-h-tag-alg = &quot;sha1&quot; / &quot;sha256&quot; / x-key-h-tag-alg x-key-h-tag-alg = hyphenated-word ; for future extension Allman, et al. Standards Track [Page 26] RFC 4871 DKIM Signatures May 2007 k= Key type (plain-text; OPTIONAL, default is &quot;rsa&quot;). Signers and verifiers MUST support the &quot;rsa&quot; key type. The &quot;rsa&quot; key type indicates that an ASN.1 DER-encoded [ITU.X660.1997] RSAPublicKey [RFC3447] (see Sections 3.1 and A.1.1) is being used in the &quot;p=&quot; tag. (Note: the &quot;p=&quot; tag further encodes the value using the base64 algorithm.) ABNF: key-k-tag = %x76 [FWS] &quot;=&quot; [FWS] key-k-tag-type key-k-tag-type = &quot;rsa&quot; / x-key-k-tag-type x-key-k-tag-type = hyphenated-word ; for future extension n= Notes that might be of interest to a human (qp-section; OPTIONAL, default is empty). No interpretation is made by any program. This tag should be used sparingly in any key server mechanism that has space limitations (notably DNS). This is intended for use by administrators, not end users. ABNF: key-n-tag = %x6e [FWS] &quot;=&quot; [FWS] qp-section p= Public-key data (base64; REQUIRED). An empty value means that this public key has been revoked. The syntax and semantics of this tag value before being encoded in base64 are defined by the &quot;k=&quot; tag. INFORMATIVE RATIONALE: If a private key has been compromised or otherwise disabled (e.g., an outsourcing contract has been terminated), a signer might want to explicitly state that it knows about the selector, but all messages using that selector should fail verification. Verifiers should ignore any DKIM-Signature header fields with a selector referencing a revoked key. ABNF: key-p-tag = %x70 [FWS] &quot;=&quot; [ [FWS] base64string ] INFORMATIVE NOTE: A base64string is permitted to include white space (FWS) at arbitrary places; however, any CRLFs must be followed by at least one WSP character. Implementors and administrators are cautioned to ensure that selector TXT records conform to this specification. Allman, et al. Standards Track [Page 27] RFC 4871 DKIM Signatures May 2007 s= Service Type (plain-text; OPTIONAL; default is &quot;*&quot;). A colon- separated list of service types to which this record applies. Verifiers for a given service type MUST ignore this record if the appropriate type is not listed. Currently defined service types are as follows: * matches all service types email electronic mail (not necessarily limited to SMTP) This tag is intended to constrain the use of keys for other purposes, should use of DKIM be defined by other services in the future. ABNF: key-s-tag = %x73 [FWS] &quot;=&quot; [FWS] key-s-tag-type 0*( [FWS] &quot;:&quot; [FWS] key-s-tag-type ) key-s-tag-type = &quot;email&quot; / &quot;*&quot; / x-key-s-tag-type x-key-s-tag-type = hyphenated-word ; for future extension t= Flags, represented as a colon-separated list of names (plain- text; OPTIONAL, default is no flags set). The defined flags are as follows: y This domain is testing DKIM. Verifiers MUST NOT treat messages from signers in testing mode differently from unsigned email, even should the signature fail to verify. Verifiers MAY wish to track testing mode results to assist the signer. s Any DKIM-Signature header fields using the &quot;i=&quot; tag MUST have the same domain value on the right-hand side of the &quot;@&quot; in the &quot;i=&quot; tag and the value of the &quot;d=&quot; tag. That is, the &quot;i=&quot; domain MUST NOT be a subdomain of
live preview
enter atleast 10 characters
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
With selected deselect posts show selected posts
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft