[ietf-dkim] Seriously.

[MH Michael Hammer (5304)]

>From: ietf-dkim-bounces at mipassoc.org
[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Hallam-Baker,
Phillip
>Sent: Tuesday, January 22, 2008 11:26 AM
>To: Barry Leiba; ietf-dkim at mipassoc.org
>Subject: RE: [ietf-dkim] Seriously.
>

>I think this whole discussion (and most on the list) come from a
failure to consider DKIM in the context of a system.
>
 
Agreed
 
>There are two questions that you can answer with a DKIM like
specification:
>
 
I would phrase the questions slightly differently
 
>1) Is there an authentic claim of responsibility from a trustworthy
party?
 
Can I authenticate a claim of responsibility from a party (that party
may or may not be trustworthy but I can authenticate they are making the
claim)?
 
>2) Is there an authentic claim of origin from an identified party?
>
 
Is the identified party the originator of the message and can I
authenticate them as such?
 
>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.
 
Agreed
 
>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.
 
Agreed except that the Sender field should not be used unless it is in
the same domain as (authenticated) From. 
 
Mike

________________________________

	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/82685e0b/attachment.html