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 i=user(_at_)assessment(_dot_)example(_dot_)com(_dot_) 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
i=user_id(_at_)assessment(_dot_)example(_dot_)com
instead of i=email_alias(_at_)assessment(_dot_)example(_dot_)com(_dot_) 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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html