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/