----- Original Message -----
From: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
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