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.
ietf-dkim mailing list