Lets also keep mind that i= predated any reputation assessment
modeling the WG cogs took on which was first out of scope as oppose to
the focus with the chartered policy standard proposal. Hence DKIM
verification output modeling was based on a security model to protect
against any signature declaration violations. That included fraud
protection for any optional signer usage of i=.
Take Policy out of the picture, with the focus mainly on reputation
assessment of valid signatures, from what I see, the modeling based on
a d= signer domain feed to independent trust assessment service is
technically limited. Maybe the problem is such, in the name of
getting trust into the DKIM picture, too much emphasis was placed on
just using one identity for a specific form on trust modeling.
I voted to remove because I personally didn't see any value in it, it
was ambiguous to explain why/when someone should consider it, and I
was seeing false positives where the signature was computationally
correct but failed with the allowable value checking against d= value.
This promoted a new verifier option to skip this granularity check.
But if it remains even with improved semantics and we have no more
focus on policy to help protect against violations, it seems we might
need to feed it to reputation models.
--
HLS
Tony Hansen wrote:
On 4/5/2011 5:23 PM, Dave CROCKER wrote:
On 4/5/2011 12:29 PM, John R. Levine wrote:
I have lots of mailboxes internally that have mail shoveled to them
based on From:. If the mail is from a source that I trust, "i=" would
be just as useful that way.
We all filter on From:. If you know the domain is well-behaved, what's
the point of using i= rather than From: ?
This thread has a basic flaw: it is predicated on a a particular
interpretation
of i=, which is undocumented and certainly not standardized.
And thus we come full circle, back to the original suggestions that we
remove i= and the counter suggestion we provide a mechanism for a
signing domain to specify how they put information into i=.
Several notes:
1) What started this was a suggestion to remove i=, essentially because
in its current form it's unusable.
2) I countered with a suggestion that before we decide to remove it, we
need to understand if there were any way to make it useful, such as by
letting the signing domain indicate how it *is* using the i= construct.
3) Making it useful doesn't require recycling bis back at proposed; it
only requires that i= not be removed so that the other work can proceed
behind bis to fill in the gaps.
4) I don't recall seeing this particular suggestion coming up on the
list before, but I may have missed it amongst the flood of messages in
the past few years.
If folks want to have a discussion about filtering based on a validated
author
identifier or address, they should start with a construct that is
standardized
to provide that. Currently, there is no such construct.
As for any thought that i= could be made into that construct, I think the
reasons that are not practical have been explained at length.
5) Perhaps it *is* too late to salvage i=.
6) If it *is* too late to salvage i=, I think the discussion is still
good and might lead to us discovering what *would* be useful.
Tony Hansen
tony(_at_)att(_dot_)com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html