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 i=(_at_)good(_dot_)largeisp(_dot_)com,
Suresh Ramasubramanian wrote:
On Tue, Jan 27, 2009 at 8:28 AM, Tony Hansen <tony(_at_)att(_dot_)com> 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.
NOTE WELL: This list operates according to