On Tue, Jun 18, 2013 at 7:59 AM, Dave Crocker <dcroc...@bbiw.net> wrote:
> On 6/18/2013 7:18 AM, Tony Hansen wrote: > > I always thought it would be a nice follow-on to DKIM to provide a way > > for a site to specify how that site was using i=; that is, to provide > > some clarity and comprehension for that value. For example, our > > implementation placed the authenticated userid into i=. I know of one > > site that appears to use a hash of the authenticated userid. John L says > > his site uses "how the mail was injected (submit, webmail, whatever) and > > who the user was if it knows". When there is a deterministic mechanism > > used to create i=, and the mechanism is known, then it is possible for > > additional logic to be added to the receiving side as well. > It would also have to be something trustable. Otherwise, why should you believe the party making such a statement? A bad guy will put any value there that increases the likelihood of making it to the inbox, whether it's true or not. > I'm sure Tony already knows this, but just to make sure it's part of the > thread: > > Anyone can define a value-added protocol layer on top of DKIM. It > can define all sorts of additional semantics. > > It needs a method of declaring its presence, such as an extra > header field or a special external query, but after that, it's free to > define anything it wants, including a public meaning for i= > ATPS did exactly this. It may be a poor example in that it has seen approximately zero uptake due to lack of demand, but it does demonstrate the mechanism Dave's describing here. -MSK
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
