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 > [email protected] > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
