----- Original Message -----
From: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
I believe that the basic disconnect here is that the protocol
"protects" anything. The running assumption that I've seen the
most support for is that the protocol *informs" other entities
of the way the domain behaves, and the protocol consumer
may or may not use that information in conjunction with other
information to "protect" their incoming mail feed. Thus
requirements that presumes that the sender knows the mail
transit topology seem rather incongruous with an
information service about the sender itself.
I agree Mike, But I don't think there has been any suggestion, not in SSP,
not in DSAP and definitely not by me, to suggest a signer has control of
verifier local policies. However, I would suggest it its in the best
interest of both parties that each are consistent with the protocol
expectations. The verifier does not want to receive junk as much as the
signer doesn't want the verifier to get unauthorized domain mail.
To me, DKIM-BASE defines your 1st vs. 3rd policy requirements and there is
fix limited number of them based on the possible 1st vs. 3rd party
arrangements.
There are 10 of them. These 10 policies defined in DSAP has covered every
discussion so far required 1st vs. 3rd party. It would be seem to me that
these 10 policies be analyzed and to determine if we want to water them down
because they don't fit some requirement.
Unless I missed some, there are only 10 possible policies:
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. |
+-----------------------------------------------------------------+
Again, some of these may not make sense and we can water it down to fit some
"real life" requirements. But you can't generate anything more than the
above. The above are the SSP Axioms.
Anyway, that's what I think.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html