----- Original Message ----- From: "Jim Fenton" <[EMAIL PROTECTED]> To: "Douglas Otis" <[EMAIL PROTECTED]>
>> Regardless of the OA, spam will reflect poorly upon the signing >> domain. Reports of abuse and expectations of who will resolve an >> abuse issue always falls to the signing domain. There will not be >> any "spreading" of responsibility. There is no means to know whether >> the OA is even valid! The identity of the OA depends upon the >> assertion made by the signing domain. > > "Spreading" was perhaps not the right word to use. But the signature is > now coming from a different place, so whom it reflects poorly upon is > now changing. That makes it a fundamentally different thing than key > delegation. Allowing a domain to delegate the ability to sign their > mail and not holding the delegating domain responsible at all seems > undesirable in that it doesn't discourage domains from doing business > with dubious mailing services. Is it possible to view this from a VERIFIER security standpoint based on what is to expected in DKIM-BASE and all possible signatures regardless what is deemed useful or not? After, the verifier is going to be the ultimate "controller" of what gets processed, what get disseminated, filtered, etc. Regardless of the meaning the possible the DKIM-BASE signature protocol has left itself unprotected. As my chart shows in my DSAP proposal (submitted to the IETF), at http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html#anchor14 The verifier is going to see signature(s) or none at all and from its standpoint each has a possibility of 10 different arrangements: 4.2. DSAP Tags: op=<signing-policy>; 3p=<signing-policy>; From the viewpoint of the verifier, when a message is received, there are two basic pieces of signature information to be of interest when analyzing the transaction: o Original Party Signatures (OP) * never expected * always expected * optional o 3rd Party Signatures (3P) * never expected * always expected * optional When the two signature types are combines, the possible policies are listed in this following table: +=================================================================+ | op= | 3p= | Domain Policy Semantics | |=================================================================| | empty | empty | No mail expected | |-----------------------------------------------------------------| | never | never | No signing expected | | never | always | Only 3P signing expected | | never | optional | Only 3P signing optional | |-----------------------------------------------------------------| | always | never | OP signature expected | | always | always | Both parties expected | | always | optional | OP expected, 3P may sign | |-----------------------------------------------------------------| | optional | never | Only OP signing expected | | optional | always | OP expected, 3P expected | | optional | optional | Both parties may sign. | +-----------------------------------------------------------------+ Figure 4: DSAP Message Signing Policies For the sake of progress, if we set aside 3P policies, we are down to 4 possible OP policies: - No Mail Expected by OP (Original Party) - No Signing Expected by OP - Signing always expected by OP - Signaling Optional by OP It doesn't matter who here thinks if any of these make sense or not. Anyone can come up with a scenario of when it does or not make sense. What is more important is that the VERIFIER will see all the possibilities in the potential onslaught of DKIM messages. It would be ideal for the domain to declare what is or not expected in the mail with purported Domain DKIM markings. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
