But it breaks one of the constraints placed on the i= value, which is
not a good thing. Why do that when you can get the same functionality by
using the valid values of [email protected], [email protected] and
[email protected]?
Tony Hansen
[email protected]
Suresh Ramasubramanian wrote:
> On Tue, Jan 27, 2009 at 8:28 AM, Tony Hansen <[email protected]> wrote:
>> I don't think this idea meets the criteria that the i= value represents the
>>
>> Identity of the user or agent (e.g., a mailing list manager) on
>> behalf of which this message is signed ...
>
> When you have a large, faceless mass of users (say at a huge consumer
> ISP), all subject to the same outbound filtering norms, the identity
> or the individual reputation of the actual user who emitted the
> message is, frankly, irrelevant. And the individual value of an i= in
> such a situation wouldnt be worth anything at all assuming d= =
> sum(i=) in a reputation score..
>
> Or for us - we have 76 million ++ users, 400k domains. We could if we
> so choose sign i=customerdomain1.com, customerdomain2.net etc .. but
> we dont want individual reputation scores for different domains on our
> network when they are all subject to the same acceptable use policy,
> and same outbound (and inbound) filtering criteria.
>
> And this suggestion from Mike Adkins would be a much more apt way to
> use i= in such a context.
>
>> My reading of this is that you can have a 1-to-1 mapping between the i=
>> value and the user/agent's identity, and you can have an N-to-1 mapping,
>> but you can't have a 1-to-N mapping. "good", "bad" and "suspect" do not
>> represent the identity.
>
> They represent something more useful in such a context - an aggregated
> identity that helps distinguish reputation in a more fine grained way
> than simply d=largeisp.com .. while not going to the ridiculous
> lengths that several million different values of i= would take this
> line of reasoning.
>
> srs
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
