On Apr 21, 2009, at 8:40 AM, Barry Leiba wrote:
The usual set of formats and diffs are at:
<http://dkim.org/ietf-dkim.htm#errata>
Surprised to still see that this has not been corrected.
Errata:
Original Text:
,---
The tendency is to have the MUA highlight the address associated with
this *signing identity* in some way, in an attempt to show the user
the address from which the mail was sent.
'---
Corrected Text:
,---
The tendency is to have the MUA highlight the SDID, in an attempt to
show the user the identity that is claiming responsibility for the
message.
'---
This text dramatically revises the meaning of the original RFC and
goes well beyond the role of an Errata.
Properly Corrected the text would be as follows:
,---
The tendency is to have the MUA highlight the AUID, in an attempt to
show the user the identity that is claiming responsibility for the
message.
'---
Changes of this nature should be done within a bis, if needed.
The Signing Identity as defined in RFC 4871 is the i= value.
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.
Section 3.5:
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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html