Jim Fenton wrote:
Charles Lindsey wrote:
On Sat, 28 Mar 2009 01:09:29 -0000, Jim Fenton <fenton(_at_)cisco(_dot_)com>
wrote:
2. It has been noted that a domain might have different reasons for
signing a message. It might, for example, sign a message on behalf of a
mailing list manager operating in that domain. When Author Signature is
based on a d= comparison alone, any signature from the same domain as
the author is assumed to be a signature representing the original
introduction of the message into the mail stream. That may or may not
be an important distinction, but I'm pointing out that information is
lost and I'm not sure we have enough experience to say that we don't
need it.
I don't think that is quite right. Suppose foo.example has declared that
it signs everything, with strength "Discardable". Then four possibilities
arise:
From: someone(_at_)foo(_dot_)example
From:someone(_at_)foo(_dot_)example
Valid signature from foo.example Absent/broken signature from
foo.example
ACCEPT DISCARD
From someone(_at_)bar(_dot_)example From
someone(_at_)bar(_dot_)example
Valid signature from foo.example Absent/broken signature from
foo.example
??????? ????????
The first two cases are obvious. The second two are Jim's example. What to
do?
The second two cases are not my example. Concern #2 in my message has
to do with messages where the signing address is a different address in
the same domain as the From address. The correct test case is:
From someone(_at_)foo(_dot_)example
Valid signature from ietf-examples(_at_)foo(_dot_)example
Let's also use "all" instead of "discardable" as the test case because
it's the harder problem to solve. As you point out, the mailing list
should be acting on the Discardable practice rather than trying to send
the message to the list.
Let's say that ietf-examples(_at_)foo(_dot_)example is a mailing list that
re-signs
mail sent to the list (or it could be a forwarder or similar agent).
foo.example's mail server gets a message from an address in the same
domain, someone(_at_)foo(_dot_)example, that has no Author Signature or has a
broken one. In accordance with the domain's policy, it subjects the
message to additional scrutiny because of the "all" practices and lack
of an Author Signature. The message passes this test and is sent to the
mailing list manager.
At this point, the mailing list manager would normally sign the
message. Let's examine this with the i= and d= choices:
Using i= as the basis for Author Signature, the list can sign the
message, and the eventual verifier/assessor that does an ADSP check will
see that it (still) lacks an Author Signature since
ietf-examples(_at_)foo(_dot_)example does not match
someone(_at_)foo(_dot_)example(_dot_)
Using d= as the basis for Author Signature, if the list signs the
message, an eventual verifier/assessor will erroneously see that
signature as an Author Signature, and therefore might not give the
message the desired treatment. Another option would be for the mailing
list manager not to sign this message, which means it needs to do a
special case not to sign messages if they're from the same domain and
lack an Author Signature. This is certainly possible, but would be more
challenging if the MTA manages many domains. I also think it's the
wrong place to solve the problem.
It's up to the WG to decide whether this is a problem that deserves a
solution or whether it's too much of a corner case to bother with
(mailing list manager with users in the same domain that uses
ADSP=all). I do not like the idea of "just change someone's domain" or
"just change the list's domain" because it has always been DKIM's goal
to operate with existing addresses.
Hopefully this clarifies the test case so that this can be evaluated fairly.
Well, I'm afraid not because they appears to be different motives.
You indicate the goal is basically to make this a plug and play
technology and thats totally conflictive with any, and I mean any,
mail integrity technology. I don't think you can have it both ways.
What you are asking, I think, is the same old question that we put
forth what 2? 3? years? ago?
Why would you care if a original signature was broken as long
as it was fixed up with a resigning (by a GOOD GUY presumingly)?
In other words, the source of the signing was not the problem. As long
as it was a good guy, trusted, why should it matter if the author
signature was redone by middle ware?
The motive of one side, thats ok. The other side saying - no, its not ok!
As I see it, that was the dilemma in all this.
In my view, any technology that is relaxed, like a DKIM=ALL policy is
inherently prone to problems. So I don't see why we should expect any
less.
Sure, you or the chairs don't want to rehash some of these, but I
think we need clear concise policy language, and that might mean the
following:
1) Change DISCARDABLE to a policy attribute. Don't make it a mutually
exclusive concept.
2) Offer simple policies that MATCH current expected reality:
DKIM=UNKNOWN|ALL|ANY [, DISCARDABLE]
UNKNOWN is the default policy (implicit or explicit)
ALL is always sign with AUTHOR SIGNATURE
ANY is always sign by AUTHOR SIGNATURE or D= or I= only
DISCARDABLE would be an attribute that provides technical
authority by the domain to the receiver to discard any
fault in the signature. In other words, the author domain
has no tolerance for DKIM signing failure and expects
the mail to be discarded because they are not assuming
responsibility for it.
So if people want to rubber stamp this ADSP and ignore all these key
concerns, well, its your ball.
For me, I am a bottom line person. Do it right. I think the above is a
simple compromise and addresses what we are talking about. In all
this, we can't ignore that the Author Domain wishes are and it pretty
strange to me that they will sign mail only, dump it to some unknown
arena and don't care its broken and/or resigned by others. Very odd
consideration when you are taking about mail integrity concepts.
Finally, we still need to use the reputation, local or remote
assessors, that isn't remove from any of this. But we are trying to
use reputation was a way to solve this question versus simple
self-asserting policies.
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html