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
t...@att.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
