--- 1/draft-ietf-dkim-rfc4871bis-11.txt 2011-06-15 20:15:44.000000000 +0200 +++ 2/draft-ietf-dkim-rfc4871bis-12.txt 2011-06-15 20:15:44.000000000 +0200 @@ -1,21 +1,21 @@ Network Working Group D. Crocker, Ed. Internet-Draft Brandenburg InternetWorking Obsoletes: 4871, 5672 T. Hansen, Ed. (if approved) AT&T Laboratories Intended status: Standards Track M. Kucherawy, Ed. Expires: December 17, 2011 Cloudmark June 15, 2011 DomainKeys Identified Mail (DKIM) Signatures - draft-ietf-dkim-rfc4871bis-11 + draft-ietf-dkim-rfc4871bis-12 Abstract DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a @@ -539,21 +539,21 @@ 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. Formally, the ABNF 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 + ; Prohibits WSP and FWS 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 @@ -2014,21 +2014,21 @@ INFORMATIVE IMPLEMENTATION NOTE: The easiest way to achieve this is to insert the DKIM-Signature header field at the beginning of the header block. In particular, it may be placed before any existing Received header fields. This is consistent with treating DKIM-Signature as a trace header field. 6. Verifier Actions 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 border MTA or shortly thereafter. In particular, deferring verification until the message is accessed by the end user is discouraged. A border or intermediate MTA MAY verify the message signature(s). An MTA who has performed verification MAY communicate the result of that verification by adding a verification header field to incoming messages. This considerably simplifies things for the user, who can now use an existing mail user agent. Most MUAs have the ability to