I'mnot sure I'm comfortable with your explanation of case 1. You may or
may not consider the party you are authenticating as being trustworthy.
You may not even have enough information to make that decision. The
generic description of this case is that you have a claim of
responsibility from a party and you are authenticating (through the DKIM
query to DNS) that their signature does indeed match (or does not).
If the signature matches then the trustworthiness of the party can be
considered.
With regard to the indicated party having a mail sending policy, I still
maintain that if the sender domain is not the same as the from domain
there is a significant issue and subsequent risk. Because there does not
have to be any trust relationship or authorization indicated by the From
address for the sender adddress, this leads to the potential for cross
domain attacks that would potentially degrade the effectiveness of DKIM
checking by receivers. This is very similar to an issue (one that I have
not seen commonly discussed) that exists for PRA (with regard to sender)
in SIDF.
If there were a way for domain owners to indicate authorized 3rd party
signers (whether sender field or simply 3rd parties) through SSP, this
might be useful. That is, I sign my mail but if you receive mail signed
by (for example) smallbusiness._domainkey.constantcontact.com. IN TXT
and they sign it then that is ok too.
Now we have a clear link between the from field domain authorizing mail
sent by sender field domain which is signed by sender field domain. Does
this address all sender cases? Absolutely not. Does it address some
potentially useful and significant ones.... possibly. Consider a
business which wishes to allow it's law firm to send and sign mail on
it's behalf. This is just a quick example but I thinkit illustrates the
point. We now have a confidence level that sender really is sending on
behalf of from.
Mike
________________________________
From: Hallam-Baker, Phillip [mailto:pbaker(_at_)verisign(_dot_)com]
Sent: Wednesday, January 23, 2008 9:55 AM
To: Siegel, Ellen; MH Michael Hammer (5304);
ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Seriously.
What I am saying in case 1 is that all that matters is that you
have an authenticated claim of responsibility from a party you consider
to be trustworthy.
Whether that corresponds to the sender, from or any other header
is irrelevant for the purposes of edeciding which mail gets passthrough
and which gets sent to the filters. For example, say Google decides to
sign all outbound mail sent through Postini. Google is not the sender,
from or has anything else to do with the message other than they are
saying that it complies with their rate limiting anti-spam control.
The from, sender etc do matter when the indicated party has a
mail sending policy. In that case there is an affirmative statement out
there 'reject all mail that purports to come from me that is not
authenticated as comming from me'. Without a policy the from addresses
are irrelevant in my view.
________________________________
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Siegel,
Ellen
Sent: Tue 22/01/2008 1:40 PM
To: MH Michael Hammer (5304); ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Seriously.
> From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of MH Michael
Hammer
(5304)
>> From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hallam-Baker,
Phillip
>> 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.
If you have an authentic claim of responsibility from a
trustworthy party (as per #1), why should it matter whether that party
is represented by the From: header or the Sender: header? And why, if
the authenticated party in the Sender: field is trustworthy, should it
be required that the From: domain is authenticated directly?
This all seems counter to the idea that reputation is the real
differentiator. You seem to be saying that a trustworthy, authenticated
signature related to the Sender field is worthless, but any
authenticated signature related to the From: field is goodness. Taking
that to its logical conclusion, spam signed with a signature based on
the bogus From: domain will be rated better than valid mail signed with
a well-know, trusted 3rd party signature based on the Sender field.
Using SSP as a backup if your first-level reputation check
yields uncertain results is one thing, but claiming that receivers
should automatically be invoking it any time that a signature fails to
match the originator domain (independently of the trust status of the
existing signature) seems like it's potentially creating more problems
than it's solving.
Ellen
_______________________________________________
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