On November 5, 2005 at 08:20, Douglas Otis wrote: > The opaque-identifier provides a means to automate compromised systems > out of existence by reducing tracking efforts by an order of magnitude. > The opaque-identifier would not expose people's identity as SSP does. > The opaque-identifier would only be understood by the provider. They > will understand. : )
An implementation problem with your opaque-id is the use of it to provide SSH-like (using your analogy) association with originating addresses and signing domain. In order for this relationship to work, the opaque-id must be the same for any given sender, making it problematic to use the opaque-id for tracking. For example, a customer of an ISP may connect through different IPs (e.g. dial-up), but to provide MUA identity associations, the opaque-id must be constant for the given customer. It appears you need to separate tracking with identity management to two different parameters. The "ID" would be for tracking while an separate opaque parameter is used to associate the message to a given sender within the signing domain (technically, revocation can then be applied to either parameter). It appears that the i= parameter in DKIM can be used in this role (side note: signers should use a value that does not expose any real email address or other information that can be exploited by bad actors). An MUA/MDA could track i= values for given rfc2822.From values versus the tracking opaque-id. Note, such identity associations does assume that the sending domain utilizes an identification scheme robust enough to denote who the sending user is. ISPs and organizations that just utilize IP addresses to authorize the sending of email will not be able to provide adequate i= values to facilitate MUA identity associations. --ewh _______________________________________________ ietf-dkim mailing list http://dkim.org
