[ietf-dkim] Seriously.

[Hallam-Baker, Phillip]

I think this whole discussion (and most on the list) come from a failure to consider DKIM in the context of a system.
 
There are two questions that you can answer with a DKIM like specification:
 
1) Is there an authentic claim of responsibility from a trustworthy party?
2) Is there an authentic claim of origin from an identified party?
 
A claim of responsibility is not the same as a claim of origin. If all you want to do is to whitelist email for spam control purposes you simply do not care if the signer of the email is the originating party in any sense (author, employer, etc.). The multiple from issues is irrelevant.
 
If you do care about authenticated origin the RFC 822 headers are frankly irrelevant. The only claim(s) of origin you care about are those that are authenticated. If you have multiple From and only one is authenticated then you are only going to tread that one as authenticated for purposes where you require authentication. If all the From addresses are authenticated then you are fine.
 
 
 

________________________________

From: ietf-dkim-bounces at mipassoc.org on behalf of Barry Leiba
Sent: Mon 21/01/2008 3:52 PM
To: ietf-dkim at mipassoc.org
Subject: Re: [ietf-dkim] Seriously.



Dave says...
> 1. Multiple From addresses are in the RFC2822 standard, folks. The
> capability was defined in RFC 733 (1977) and has been retained in every
> iteration up to the current RFC2822 revision work.   That means that it
> has gone through repeated review by the email standards community. Why
> in the world would it be appropriate for the DKIM working group to
> debate its legitimacy?
>
> 2. While it is certainly useful to prune obsolete constructs, it is
> dangerous to assume that what a particular segment of the community is
> familiar with is all that ought to be allowed.  Email is a very
> general-purpose tool for human communications.  Human communications is
> a very, very rich space.  Just because on or another person -- or lots
> of them -- do not use a feature does not mean its use can be ignored or
> denied.

Yeah.  I'm speaking here not as DKIM working group chair, nor as DKIM
working group participant, but as a member of the IAB: in that capacity,
I would look VERY skeptically at any attempt to say that DKIM doesn't
have to support something that's in the RFC2822 standard, on the basis
that either (1) "no one uses it" or (2) "it doesn't interoperate well in
the first place".

I'm sympathetic to the idea that we'd like not to spend a lot of time on
an aspect that's pretty much never going to show up... on a "corner
case".  But saying that we can ignore that aspect is just not on.  I
would hope that Lisa or Chris, or both, would send up a DISCUSS if that
happened.

Barry
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20080122/0ae2faf8/attachment-0001.html