ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft Errata on RFC 4871

2009-01-29 14:39:09


Al Iverson wrote:
If you would be so kind, would you help me understand the concept of a
UAID a bit better. It's an email address, but it can be
non-resolvable? What's a real world example of that -- in how either
an ISP or ESP would want to sign in such a way? I'm a bit cornfused.

Al,

1. I can easily believe that the Errata text needs to be even more clear about 
this string.  Submissions to improve it are eagerly sought...

2.  It is *not* an email address, in terms of the DKIM base spec. So some 
signers well might choose to make it be an actual email address, but that's not 
something that DKIM knows (or cares) about.

3.  It is an identifier that is created by the signer, to indicate the user or 
agent that wants the signing to be done. The 'role' of this user or agent is 
unspecified; the message might not have any other reference to this user or 
agent.  (Notably this means that there is no indication that it is the author, 
and it well might not be the author.)

4.  For receivers, this string is completely opaque -- that is, 
uninterpretable. 
  Therefore, within the scope of the DKIM base specification, the entire i= 
string is *always* unresolvable, in that it has no syntax and no semantics, 
other than string1(_at_)string2, and string2 equals d= or is a subdomain of d=.

5.  It might be worth including the i= value, when communicating back with the 
signer; it might facilitate auditing and/or debugging.

6.  There might be special cases that allow a receiver to extract useful 
information from the string, although this is entirely outside the DKIM base 
specification.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html