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