MH Michael Hammer (5304)
MHammer at ag.com
Tue Jan 22 09:21:09 PST 2008
>From: ietf-dkim-bounces at mipassoc.org
[mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Hallam-Baker,
>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.
>There are two questions that you can answer with a DKIM like
I would phrase the questions slightly differently
>1) Is there an authentic claim of responsibility from a trustworthy
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
>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.
>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.
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.
> 1. Multiple From addresses are in the RFC2822 standard, folks.
> capability was defined in RFC 733 (1977) and has been retained
> iteration up to the current RFC2822 revision work. That
means that it
> has gone through repeated review by the email standards
> in the world would it be appropriate for the DKIM working
> debate its legitimacy?
> 2. While it is certainly useful to prune obsolete constructs,
> dangerous to assume that what a particular segment of the
> familiar with is all that ought to be allowed. Email is a
> general-purpose tool for human communications. Human
> a very, very rich space. Just because on or another person --
> of them -- do not use a feature does not mean its use can be
Yeah. I'm speaking here not as DKIM working group chair, nor as
working group participant, but as a member of the IAB: in that
I would look VERY skeptically at any attempt to say that DKIM
have to support something that's in the RFC2822 standard, on the
that either (1) "no one uses it" or (2) "it doesn't interoperate
the first place".
I'm sympathetic to the idea that we'd like not to spend a lot of
an aspect that's pretty much never going to show up... on a
case". But saying that we can ignore that aspect is just not
would hope that Lisa or Chris, or both, would send up a DISCUSS
NOTE WELL: This list operates according to
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ietf-dkim