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(_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