Rolf E. Sonneveld wrote:
Scott Kitterman wrote:
It's not at all clear to me that the answer to that question is
in any way related to the work of the working group. What would
we design differently if the answer was yes (or no)?
Let me try to explain. If the identity of the list contributor is of any
value to the receiver of an MLM-distributed message, then it is
important to (try to) preserve the original DKIM signature across an MLM
redistribution of the message (if at all possible). If however the
identity of the list contributor is of no value whatsoever, we should
not bother about preserving the original DKIM signature.
This is why I believe that the current GOOD CITIZEN centric approach
is very hard to resolve without addressing the "BAD CITIZEN" model
first or at the very list, the GOOD CITIZEN model should not come at
the expect at diminishing the high beneficial value of the BAD CITIZEN
model.
It is a conflict an engineering philosophy and I believe once we
acknowledge one can not exist without the other, this issue with
continue in perpetuity.
What you speak of is about trust, something something about the
message that allows you to believe it is OK?
Consider the contrary question, what is it about the message that
makes you NOT TRUST the message?
Lets say that we some how invented a way to RESTORE THE INTEGRITY OF
THE ORIGINAL SIGNATURE so its no longer a factor and I changed my MUA
or online mail web interface to support and present all four ideas:
5322.FROM domain
5322.DKIM signing domain (d=)
5322.ADSP as a function of 5322.FROM domain
5322.LIST-ID domain
and I'm going to add a 5th new idea here (data point) called LDSP
(List Domain Signing Policy)
5322.LDSP as a function of 5322.LIST-ID domain.
Idea #1:
If the 5322.ADSP result is DISCARDABLE, the DOMAIN is making a public
policy statement:
NO ONE CAN SIGN MAIL FOR US. ONLY WE CAN SIGN MAIL.
This is called a 1st party signing only policy.
The question is why would you (speaking in general) ignore this very
powerful data point if you see your list message is signed by the list
and not by the domain? The original signature is intact. But the
policy said only they sign mail - no one else.
Doesn't that say there is someone WRONG, not GOOD, about this message?
even with an original valid signature intact?
Idea #2
Lets say you trust all mail coming from this list because it is signed
by the list domain. You feel reasonable secured it is valid GOOD
message when it is signed by the list and also if any, the original
domain signature is intact.
But what if the DKIM signature domain is not signed by the list? What
it is a 3rd party, for example?
From: <louie(_at_)FROM-DOMAIN(_dot_)COM>
DKIM-Signature: d=FROM-DOMAIN.COM
DKIM-Signature: d=OTHER-RESIGNER.COM
List-Id: <listadmin(_at_)LIST-DOMAIN(_dot_)COM>
Would you have a lower trust of this message? Would it still matter
if the original signature is valid but the list signature is valid but
resigned by some other unknown domain?
Idea #3:
Let say that we have this new LDSP (List Domain Signing Policy)
protocol which is a small change to ADSP by instead of anchoring off
the 5322.From domain, LSDP anchors off the 5322.List-ID domain.
Let say that LIST-DOMAIN.COM has a LDSP policy of:
DKIM=DISCARDABLE
which says:
LIST-DOMAIN.COM is the only domain that can sign list messages
coming from this list. No one else is expected to sign as a
3rd party.
Would you still trust this list even when there is an explicit LDSP
policy exposing to the world that it has an exclusive and restrictive
1st party signing policy?
So basically, all I am saying that regardless of how its down, there
is always the issue of not getting what is expected and before you can
even trust a list-id or from domain, you need to factor everything all
the failing about it.
If you trust a LIST-ID domain, thats that mean that only it can sign
mail? What happens when its some other domain?
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html