From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hallam-Baker,
Phillip
Sent: Tuesday, January 22, 2008 11:26 AM
To: Barry Leiba; ietf-dkim(_at_)mipassoc(_dot_)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(_dot_)org on behalf of Barry Leiba
Sent: Mon 21/01/2008 3:52 PM
To: ietf-dkim(_at_)mipassoc(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html