draft-ietf-dkim-rfc4871bis-11.txt   draft-ietf-dkim-rfc4871bis-12.txt 
Network Working Group D. Crocker, Ed. Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking Internet-Draft Brandenburg InternetWorking
Obsoletes: 4871, 5672 T. Hansen, Ed. Obsoletes: 4871, 5672 T. Hansen, Ed.
(if approved) AT&T Laboratories (if approved) AT&T Laboratories
Intended status: Standards Track M. Kucherawy, Ed. Intended status: Standards Track M. Kucherawy, Ed.
Expires: December 17, 2011 Cloudmark Expires: December 17, 2011 Cloudmark
June 15, 2011 June 15, 2011
DomainKeys Identified Mail (DKIM) Signatures DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-11 draft-ietf-dkim-rfc4871bis-12
Abstract Abstract
DomainKeys Identified Mail (DKIM) permits a person, role, or DomainKeys Identified Mail (DKIM) permits a person, role, or
organization that owns the signing domain to claim some organization that owns the signing domain to claim some
responsibility for a message by associating the domain with the responsibility for a message by associating the domain with the
message. This can be an author's organization, an operational relay message. This can be an author's organization, an operational relay
or one of their agents. DKIM separates the question of the identity or one of their agents. DKIM separates the question of the identity
of the signer of the message from the purported author of the of the signer of the message from the purported author of the
message. Assertion of responsibility is validated through a message. Assertion of responsibility is validated through a
skipping to change at page 13, line 28 skipping to change at page 13, line 28
below (as "tag-value") only includes 7-bit characters, an below (as "tag-value") only includes 7-bit characters, an
implementation that wished to anticipate future standards would be implementation that wished to anticipate future standards would be
advised not to preclude the use of UTF8-encoded text in tag=value advised not to preclude the use of UTF8-encoded text in tag=value
lists. lists.
Formally, the ABNF syntax rules are as follows: Formally, the ABNF syntax rules are as follows:
tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]
tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS] tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name = ALPHA 0*ALNUMPUNC tag-name = ALPHA 0*ALNUMPUNC
tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ] tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]
; WSP and FWS prohibited at beginning and end ; Prohibits WSP and FWS at beginning and end
tval = 1*VALCHAR tval = 1*VALCHAR
VALCHAR = %x21-3A / %x3C-7E VALCHAR = %x21-3A / %x3C-7E
; EXCLAMATION to TILDE except SEMICOLON ; EXCLAMATION to TILDE except SEMICOLON
ALNUMPUNC = ALPHA / DIGIT / "_" ALNUMPUNC = ALPHA / DIGIT / "_"
Note that WSP is allowed anywhere around tags. In particular, any Note that WSP is allowed anywhere around tags. In particular, any
WSP after the "=" and any WSP before the terminating ";" is not part WSP after the "=" and any WSP before the terminating ";" is not part
of the value; however, WSP inside the value is significant. of the value; however, WSP inside the value is significant.
Tags MUST be interpreted in a case-sensitive manner. Values MUST be Tags MUST be interpreted in a case-sensitive manner. Values MUST be
skipping to change at page 46, line 41 skipping to change at page 46, line 41
INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this
is to insert the DKIM-Signature header field at the beginning of is to insert the DKIM-Signature header field at the beginning of
the header block. In particular, it may be placed before any the header block. In particular, it may be placed before any
existing Received header fields. This is consistent with treating existing Received header fields. This is consistent with treating
DKIM-Signature as a trace header field. DKIM-Signature as a trace header field.
6. Verifier Actions 6. Verifier Actions
Since a signer MAY remove or revoke a public key at any time, it is Since a signer MAY remove or revoke a public key at any time, it is
recommended that verification occur in a timely manner. In many advised that verification occur in a timely manner. In many
configurations, the most timely place is during acceptance by the configurations, the most timely place is during acceptance by the
border MTA or shortly thereafter. In particular, deferring border MTA or shortly thereafter. In particular, deferring
verification until the message is accessed by the end user is verification until the message is accessed by the end user is
discouraged. discouraged.
A border or intermediate MTA MAY verify the message signature(s). An A border or intermediate MTA MAY verify the message signature(s). An
MTA who has performed verification MAY communicate the result of that MTA who has performed verification MAY communicate the result of that
verification by adding a verification header field to incoming verification by adding a verification header field to incoming
messages. This considerably simplifies things for the user, who can messages. This considerably simplifies things for the user, who can
now use an existing mail user agent. Most MUAs have the ability to now use an existing mail user agent. Most MUAs have the ability to
 End of changes. 3 change blocks. 
3 lines changed or deleted 3 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/