On 01/10/10 18:28, Dave CROCKER wrote: > > > On 10/1/2010 10:15 AM, Murray S. Kucherawy wrote: >> The spec simply states that DKIM doesn't require any binding at all. >> (Section 1.1) > > > It occurs to me that this language permits a misinterpretation and that > stronger > and more direct language would be appropriate. > > By saying "is not required to match", the current spec leaves open the > possibility that the presence of a match might be taken to be meaningful by > DKIM. > > However the reality is that DKIM is literally blind to the relationship > between > a d= domain and a domain name in any other field. > > I think the text should therefore be revised from: > >> 1.1. Signing Identity > ... >> INFORMATIVE RATIONALE: The signing identity specified by a DKIM >> signature is not required to match an address in any particular >> header field because of the broad methods of interpretation by >> recipient mail systems, including MUAs. > > (hmm. the use of the term 'address' is probably also inappropriate since it > means email address in the email world, rather than domain name address.) > > > > to be: > > 1.1. Signing Identity > ... > The signing identity specified by a DKIM signature is entirely > independent > of the identities present in any particular header field. The interpretation > of
s/identities/identifiers/ above? S. > a match that is possible between the signing identity and the identifier in > another field is outside the scope of DKIM. > > > (I've removed the "Informative Rationale" label because the proposed text > really > moves into explanation of the protocol, rather than explanation of its > motivation or the like.) > > d/ > > ps. just so no one is confused: this does not change the protocol at all; it > merely clarifies a point that is often misunderstood. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
