On Jan 28, 2009, at 6:33 PM, Mark Delany wrote:
>
> On Jan 28, 2009, at 5:22 PM, Suresh Ramasubramanian wrote:
>
>> On Thu, Jan 29, 2009 at 2:22 AM, Douglas Otis <[email protected]>
>> wrote:
>>> There will be work involved when dealing with opaque i= values when
>>> assessing reputations. Any amount of consolidation of this
>>> information will
>>> induce a higher degree of collateral blocking. It seems best to
>>> keep this
>>> an opaque value that the sender fully controls.
>>
>> Those opaque i= values will be of some use to the sender. I see no
>> reason why the receiver can't simply ignore them.
>
> Colo(u)r me dumb/confused/take-your-pick, but is i= effectively the
> moral equivalent of IDENT (RFC1413)?
That's how I've been thinking about it for a while. It's an opaque
cookie that's primarily of value to the sender when the receiver
passes it back to them in the context of a particular connection.
Some implementations leave data in that cookie that's immediately
useful ("this mail was from apache@, huh?") and some don't, and
there's no way other than human eyeballs or heuristics to guess
whether there's that data in any particular case.
Ident is pretty widely feared and misunderstood, which is
why I've never tried to use the parallel between the two. And is,
itself, another parallel I guess.
Cheers,
Steve
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
