Eliot Lear wrote:
Hector,
So much for getting the "easy issues" out of the way. :-)
Bingo. We are wasting time on what I think is an extraordinary
superficial issue. Jim's original term "Suspicious" was defined within
the document, and did not in itself mean that the message was a forgery
- just that extra care is needed. I wonder whether there really is a
developer who would be confused by the term and not know what to do. If
so, please explain why you are confused by the text.
Eliot
I agree with you. I don't think developers, including us, will have much
of an issue with "suspicious" or even exception. So for me, I
have no qualm with closing this issue. We know what we can or can not
do and the "words" isn't going to change that.
That said, I do recognize the dichotomy here and would I think I
understand why David raised the issue.
My opinion:
From my viewpoint, I personally do not have a subjective concern for
SSP and view it as directly tied to the DKIM-BASE protocol consistency
implementation "requirements." I always felt SSP would be key part for
DKIM's wide adopted success (not just high profile isolated
implementations). Thus separating it, IMO, was going to cause some
rather complex wide-adoption engineering implementation barriers. FWIW,
we have very little interest in DKIM without a SSP framework.
So for me, I see it more as black and white with no gray. The only gray
is the imperfections of the DKIM protocol - not SSP. SSP is
indeterminate in the gray areas of DKIM-BASE. However, they are
interrelated because SSP can help in minimizing the gray areas of DKIM-BASE.
The point of the illustrating the boundary conditions in the other
thread was to highlight where SSP helps validate the DKIM protocol with
100% non-repudiation, meaning the mail was received in the framework it
was expected and no one is disputing it. It illustrates the hard
results - the pure violations and pure compliance of DKIM-BASE. It also
shows unless hard choices or assumptions are made, it shows why the
"BROKEN TO NO-SIGNATURE" DKIM-BASE mandate can be problematic.
So to me, it is either a true or false check - no exception.
In short, if you asking me why one can be "confused" by this, I say,
lets not make it any more difficult for SMTP receivers and DKIM
verifiers. Lets just describe it as it is. No beating around the bush.
I wouldn't use suspicious or not suspicious because that is a
"subjective" conclusion on bad vs good intentions. All should be part
of the same considerations. So I would work along the line of what Jim
has suggested - compliance and that applies to both good or bad. So for
all the steps, I would use more direct semantics like:
.. the message does not violate the domain signing policy|practice,
and the algorithm terminates. The transaction SHOULD be given
positive classification.
.. the message violates the domain signing policy|practice,
and the algorithm terminates. The transaction SHOULD be given
a negative classification.
To me, this does two things:
1) Straight to the point - it either satisfies or violates SSP,
with terms most levels of people interested in this
would understand or be able to follow.
2) Helps prepare augmented technology (filters, message handlers,
heuristic systems, etc) with terms people concentrated in these
areas would understand or follow.
But since I can see how "suspicious" can cover both ideas, I have no
problem keeping it as such. As we all know, receivers are going to
train or code their ware to make it work for operators who may want to
use this extra DKIM/SSP information about a message. But at the same
time, we can't presume everyone are just going to invest in adding what
is undoubtedly a very complex protocol and not expect a payoff.
So I hope my input here, and that is all it is, input, helps to make
sure it doesn't makes things worst - and that includes those don't
implement it or legacy system and begin to become targets themselves
with a worst case scenario that the domain reputation is now harmed.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html