Michael Adkins wrote:
> Siegel, Ellen wrote:
>>> If I choose to segment my signing based on my own assessment of the
>>> user, as I do now with outbound ip addresses, then I would probably make
>>> that a subdomain in d= (d=assessment.example.com). If I also choose to
>>> specify an i= value, then that segmentation will spill over giving us
>>> something like [email protected]. If my assessment of that
>>> user changes, then the i= value will change as well. So, i= does
>>> contain the identity of the user but is not necessarily a stable value.
>>>
>>
>> Interesting. This model would seem to break down, or at least get
>> complicated, in cases where i= values are supposed to match email
>> addresses... presumably the "assessment" part of the d=domain would
>> not be visible in the actual email address, or it would require major
>> changes to migrate users from one bucket ("assessment" subdomain) to
>> another.
>>
>> Does that mean you're implicitly assuming that there's no direct link
>> between the d= (or i=) domain and the email address?
>>
>> Ellen
>>
>>
> There isn't. We host mail for numerous domains, but we're planning to
> sign all of it as d=assessment.aol.com for the reasons Suresh mentioned
> (same use policies, filtering, etc.). Plus, a single user identity in my
> system can have multiple email addresses associated with it, so it makes
> more sense (in my mind at least) to set [email protected]
> instead of [email protected]. For example, a single
> dial-up customer can have up to seven mailboxes at a time but there's
> still only one responsible identity for the account. I believe broadband
> access providers have similar setups.
This looks just fine to me. By using the user_id, you're satisfying the
semantics of
Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed
and still maintains the uniqueness of that identity.
I don't think this is the same as what Suresh was describing, though. He
was talking about using assessment labels for the i= value, such as
[email protected], rather than a value directly linked to the
known user/agent.
Tony Hansen
[email protected]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
