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/ |