+1
My understanding is that i= does not need to represent a valid email address,
it just need to be in a kind of valid email address format.
So if we keep i= as is in the spec, we can conclude the standard process and
give a meaning of i= outside this spec in another RFC?
----- Original Message -----
From: "Tony Hansen" <tony(_at_)att(_dot_)com>
To: "IETF DKIM WG" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Wednesday, 6 April, 2011 11:05:02 AM
Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html