----- Original Message ----- From: "Michael Thomas" <[EMAIL PROTECTED]>
> at: > http://mtcc.com/standards/draft-ietf-dkim-ssp-requirements-00.txt > > until it shows up in the draft repository. Full disclaimer, this has > been put together in a very small amount of time, sifting through > a huge amount of mail on the list. Michael, I reviewed it. Great work. I can personally appreciate the effort you put into it. Thanks! Before this gets lost in any of comments below, I wish to take this opportunity to publically apologize to you for being impatience and for any rudeness shown by me. Sorry. As one "Author of Software," I have a small checklist of functional design requirements that needs to be satisfied. I put a check on the ones reg-00 has directly or indirectly addresses or touches base with. Required Functional Support Items: [X] No Mail expected domain policy [?] No Signature expected domain policy [X] 1st party signature expected domain policy [X] Exclusive Signature domain policy [X] 3rd party signature allowed domain policy [_] 3rd party Strip/Replace domain policy [X] Allow Domain Signer list Optional Functional Support Items: [X] Highest Hashing Method Available domain attribute Overall, I think it covers most of everything. The 3rd party strip/replace has to do more with Middle Ware issues. The question is whether we provide some functional guidelines for Middle Ware authors to help become more "DKIM-Friendly" to help with the survivability of the message? This is also related to #9 item as I discussed below in my 2) Chicken vs. Egg comment. Specific comments: 1) Null Practice A "null" practice is not clearly defined. It is first used or introduced as it was already defined. 7. If the Discovery process would be shortened by publication of a "null" practice, the protocol SHOULD provide a mechanism to publish such a practice. We need a hard core declaration that either a signature is expected or not expected. This is different from being "neutral", the idea that is a widespread consensus that relaxed policies create unstable states, it is still a concept that still needs to be allowed to be defined for increase the acceptability and adoption of DKIM-BASE, i.e. a migration concept. >From an implementations standpoint, it comes down to a matter of saying that if there is a signature present with a NEUTRAL policy present,then it better be valid (higher score for failure). But if there isn't a signature, then the implementation will simply punt and move the email to the next stage if any. The only harm here is the DOMAIN itself. He is the one flirting with danger when verifiers see that a NEUTRAL policy is always failure in the DKIM signature verification process. Understand? I vote to keep the idea, but if removed, I will not argue against it. It just puts more strain in the adoptability area. i.e, forcing organizations to decide a lot quicker which probably ok by me. 2) Chicken vs. Egg problem 9. The Protocol MUST NOT be required to be invoked if a valid first party signatures is found. This #9 item has no reason to exist. As long as the end results are the same, there is no need to dictate how an implementation is done. I vote to remove it. It has no relationship to what you are trying to do here with "functional" requirements. What if my implementation is such that it does invoke the protocol at all times before the verification process begins? Am I now in violation of the standard SSP protocol? No. As long as the same end results are achieved, it shouldn't matter. But in my case, it is done in a more optimal and more efficient matter. Look at it this way, change it to: 9. The Protocol MUST allow to be invoked before the verification process takes place. You see? This also dictates design implementation too. The end result is really the same, but one can argue (meaninglessly) that allowing an invocation of the protocol before a verification is done is more efficient. So I vote to remote this one. Overall Mike, Great job! -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
