Subject: [ietf-dkim] NEW ISSUE: replace use of term "suspicious"

From: Dave Crocker <[email-masked]>
Date: Sun, 09 Dec 2007 09:42:03 -0800

With the use of language like "suspicious", SSP is making value judgement on 
messages that do not satisfy SSP's criteria, even though those message well 
might be entirely legitimate.

The specification needs to use a label that is is a neutral, technical 
description of the state, rather than a value judgment on legitimacy.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 10 Dec 2007 08:26:56 +0100

Dave Crocker wrote:

> With the use of language like "suspicious", SSP is making value
> judgement on messages that do not satisfy SSP's criteria, even
> though those message well might be entirely legitimate.

Weasel words instead of "suspicious" would be an intentional lie.

The problem is the "even though", the "first author" concept is
utter dubious, unrelated to (2)822(upd), and claims that "first
author" is always the same as "originator" would be a perfidy.

 Frank

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Dec 2007 11:57:22 -0800

> Weasel words instead of "suspicious" would be an intentional lie.

My suggestion is to remove "suspicious" and replace it with the
actual state of SSP itself. For example strict-violation or all-violation
or nxdomain-violation (or whatever). This removes the subject nature
of "suspicion" and its resulting idiosyncratic definition.

       Mike

---

From: Jon Callas <[email-masked]>
Date: Tue, 11 Dec 2007 11:47:33 -0800

> author" is always the same as "originator" would be a perfidy.

How about something like "SSP Exception"? Metaphorically, it works  
well with the programming use of the word exception.

	Jon

---

From: Hector Santos <[email-masked]>
Date: Tue, 11 Dec 2007 15:27:38 -0500

Jon Callas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 

I personally like

   Negative and Positive Classification.

It some what fits the SMTP negative and positive response codes semantics.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 11 Dec 2007 23:11:50 +0100

Jon Callas wrote:

> How about something like "SSP Exception"?

I'm fine with almst all proposals so far, including to keep
"suspicious" as is.  Please no weasel words like "annotated"
or anything that's much longer than "strict fail".  

If you think that "first author" could make it into the RFC
there will be what I'd call "false positives", and then it
could be good to use a more neutral term.

If "first author" is replaced by "PRA" (the [2]822 concept,
not necessarily this acronym) then "suspicious" is fine.

Isn't "strict fail" a harsher judgement than "suspicious" ?
I don't see why Dave doesn't like "suspicious", a suspect
can be innocent, a "strict fail" can't, or can it ?

 Frank

---

From: "J D Falk" <[email-masked]>
Date: Wed, 12 Dec 2007 20:54:27 -0500

>>> judgement on messages that do not satisfy SSP's criteria, even
though
>>> those message well might be entirely legitimate.
>> 
> My suggestion is to remove "suspicious" and replace it with the actual
> state of SSP itself. For example strict-violation or all-violation or
> nxdomain-violation (or whatever). This removes the subject nature of
> "suspicion" and its resulting idiosyncratic definition.

+1

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Dec 2007 12:17:48 -0800

> well with the programming use of the word exception.

+1.

I think that ithe term is terse, technically accurate, socially neutral and 
likely to be easy to remember.  That makes it a good choice.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Dec 2007 09:10:49 -0800

>>> though those message well might be entirely legitimate.
...
> well with the programming use of the word exception.

Folks,

In the hope of trying to close some of the "easy" Issues, would folks comment 
on this specific proposal, or otherwise post comments seeking closure of the 
Issue?

Thanks.

d/
-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Sun, 16 Dec 2007 09:18:54 -0800

On Dec 16, 2007, at 9:10 AM, Dave Crocker wrote:

> In the hope of trying to close some of the "easy" Issues, would  
> folks comment on this specific proposal, or otherwise post comments  
> seeking closure of the Issue?

"SSP exception" works for me, and is better than "suspicious",  
regardless of capitalization.

Cheers,
   Steve

---

From: [email-masked] (Wietse Venema)
Date: Sun, 16 Dec 2007 12:49:13 -0500 (EST)

+1.

	Wietse

---

From: Hector Santos <[email-masked]>
Date: Sun, 16 Dec 2007 13:56:41 -0500

Dave Crocker wrote:
> In the hope of trying to close some of the "easy" Issues, would folks 
> comment on this specific proposal, or otherwise post comments seeking 
> closure of the Issue?
> 

-1.

I actually thought Jon was joking around.

With all due respect to Jon,  an exception is generally used when you 
don't have any real controls over your software or system faults.  Its a 
highly debated concept that can create its own unknown exceptions.

"SSP Exception"  makes you think of what it means.  Is it a "Fault?" 
Exception to what?  SSP policy?  Algorithm?  Or we talking about the 
domain taking "exception" to the idea someone is messing around with its 
mail?.  "I take exception to Mr. Bad Guy trying to exploit my mail?" 
or that the domain screwed up and had created a Exception.

I don't particularly like Suspicious, but it is specific and much more 
to the point and closer to the negative "classification" ideas we are 
trying to attach, and what is being conveyed - that something is wrong. 
And IMO, it can be understood by a much more wider audience than just 
programmers.

-- 
Sincerely

Hector Santos, CTO

---

From: Michael Thomas <[email-masked]>
Date: Sun, 16 Dec 2007 11:48:40 -0800

> comment on this specific proposal, or otherwise post comments seeking 
My suggestion is to just to take the exception/violation reason. For
example, "all-exception", "strict-exception", "nxdomain-exception"
and the like. A single word even if it's value-neutral gives the wrong
impression that all exceptions/violations/suspicion should be given
the same weight. Just saying what it is that went wrong doesn't
do that.

       Mike

---

From: <[email-masked]>
Date: Sun, 16 Dec 2007 22:02:52 -0500

Please mark issue closed as exception denotes just that

-----Original Message-----
From: [email-masked] on behalf of Dave Crocker
Sent: Sun 12/16/2007 12:10 PM
To: DKIM WG
Subject: [ietf-dkim] Issue 1530 - replace use of term "suspicious"

...

Folks,

Thanks.

d/
-- 

   Dave Crocker

---

From: <[email-masked]>
Date: Sun, 16 Dec 2007 22:12:50 -0500

The word denotes failure of a rule 
in rule based systems you have a decision tree with EITHER pattern match OR exception to pattern match
SSP at a glance appears to be a rule based policy engine. Exception as opposed to Suspicious emphasizes that.
Receivers can base their policy on SSP in a similar manner.

Suspicious is a description of an exception that may or may not be accurate.
thanks,
Bill Oxley

-----Original Message-----
From: [email-masked] on behalf of Hector Santos
Sent: Sun 12/16/2007 1:56 PM
To: [email-masked]
Cc: DKIM WG
Subject: Re: [ietf-dkim] Issue 1530 - replace use of term "suspicious"

-1.

-- 
Sincerely

Hector Santos, CTO

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Dec 2007 20:04:21 -0800

Bill,

> Receivers can base their policy on SSP in a similar manner.

Your definition of exception is a bit more constrained than called for within 
the profession:

   <http://en.wikipedia.org/wiki/Exception_handling>

   <http://www.answers.com/topic/exception-handling?cat=technology>

> Suspicious is a description of an exception that may or may not be accurate.

Suspicious is not so much a "description" as a quality opinion.

d/

-- 

   Dave Crocker

---

From: Jim Fenton <[email-masked]>
Date: Sun, 16 Dec 2007 21:34:09 -0800

> the same weight. Just saying what it is that went wrong doesn't

+0.5

Agree that a name change is in order, and that we need more than a
binary 1/0 result.

But "exception" makes it sound like a kernel panic or something.  Hector
had some alternative interpretations of "exception" too.  My
suggestion:  "non-compliant"/"compliant".

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sun, 16 Dec 2007 21:38:49 -0800

> the same weight. Just saying what it is that went wrong doesn't

The current issue was to replace one term with another.  That's a simple 
string substitution.

It appears that you are raising different issue, namely to replace one term 
with multiple terms.

While I do see that you used 'exception' as the base term, I think you're 
raising a bigger -- in other words, somewhat different -- issue than I had 
intended.

At the least, your change would require more re-working of how things are phrased.

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Mon, 17 Dec 2007 04:53:51 -0500

> suggestion:  "non-compliant"/"compliant".

Another possibility is to play off Mike's 5016 "DKIM Signing complete" 
semantics:

   SSP Complete

      All expected conditions were met, including no SSP
      record available. However, to be SSP Complete, it
      MUST be also "DKIM Signing Complete" per 5016.

      The main highlight is that the DKIM and/or DKIM/SSP
      transaction CAN NOT be repudiated.

   SSP Incomplete

      Not all expected conditions were met. NXDOMAIN or
      SSP record available, but a known error|non-compliant
      condition has been detected.  A DKIM Signing Complete
      might have been reached, but it failed the SSP process.

      The main highlight is that the DKIM/SSP transaction
      CAN BE repudiated.

Something along those lines might work.

-- 
Sincerely

Hector Santos, CTO

---

From: Douglas Otis <[email-masked]>
Date: Mon, 17 Dec 2007 09:56:27 -0800

On Dec 16, 2007, at 9:34 PM, Jim Fenton wrote:

> Michael Thomas wrote:
>>
>> My suggestion is to just to take the exception/violation reason.  
>> For example, "all-exception", "strict-exception", "nxdomain- 
>> exception" and the like. A single word even if it's value-neutral  
>> gives the wrong impression that all exceptions/violations/suspicion  
>> should be given the same weight. Just saying what it is that went  
>> wrong doesn't do that.
>
> +0.5
>
> But "exception" makes it sound like a kernel panic or something.   
> Hector had some alternative interpretations of "exception" too.  My  

Mike's breakdown provides a finer granularity of states.  Policy  
exceptions happen all the time with things like SELINUX without it  
being a panic or crash.  The specification should not attempt to  
combine various states "as-if" they were just one state.  Experience  
will dictate how each state is best handled.  While a message might be  
fully compliant, there can be many reasons a message might be found  
"non-compliant".  These reasons could be termed "*-exceptions".

+1 on Mike's suggestion, and +.5 on Jim's.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Mon, 17 Dec 2007 10:00:42 -0800

> suggestion:  "non-compliant"/"compliant".

   My original suggestion was "violation" which still works with nxdomain
   and other states. I could live with exception though.

		Mike

---

From: Damon <[email-masked]>
Date: Mon, 17 Dec 2007 17:52:45 -0500

Take your pick:
http://thesaurus.reference.com/browse/exception

I don't have a problem with "exception" in this case. I believe that
it describes what is happening accurately.

Regards,
Damon Sauer

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 18 Dec 2007 15:55:05 +0100

Jim Fenton wrote:

> My suggestion:  "non-compliant"/"compliant".

If "non-compliant" is actually a "Resent-* as
specified in 2822upd with a twist" (signature
didn't survive it), then that's rather strong.

Why not FAIL ?  FAIL is short, neutral, and
some folks are used to the idea that FAIL is
a defined term.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 18 Dec 2007 09:13:30 -0800

On Dec 18, 2007, at 6:55 AM, Frank Ellermann wrote:

> If "non-compliant" is actually a "Resent-* as specified in 2822upd  
> with a twist" (signature didn't survive it), then that's rather  
> strong.

Any changes to message content might cause a signature to be invalid.   
An invalid signature may cause a message to appear "exceptional" when  
messages from the domain are asserted as "all" being signed.  As with  
any retrofit, exceptions _must_ be permitted.

> Why not FAIL ?  FAIL is short, neutral, and some folks are used to  
> the idea that FAIL is a defined term.

"FAIL" says little about an underlying cause.  Was the signature  
valid, but "on-behalf-of" a header other than "From", or by a  
different domain, when "strict" had been asserted by the From domain?   
A breakdown of causes with respect to actual "exceptions" would help  
clarify the different causes that _will_ legitimately exist.

-Doug

---

From: Hector Santos <[email-masked]>
Date: Tue, 18 Dec 2007 12:24:04 -0500

> it describes what is happening accurately.

I think that will all depends on who is reading it.

To me, an exception is not an ordinary event that one expected.  Since I 
  believe SSP is just validating the expected signing behavior as 
described by the domain, it is either a TRUE or FALSE condition - no 
exception.

Checking for NXDOMAIN is a safe result to check for.  Checking to see if 
its a given POLICY matches what is actually shown in the message, is a 
safe result to check for.   I don't see those as exceptions.

Now, if one can't make heads or tails of a SSP check, then maybe that 
can be viewed as an exception - because something happen you didn't expect.

Here's the thing:  The fact you and others had to look it up, means a 
lot here. Most people are not going to be wanting to have their 
dictionary or thesaurus around when they read these RFCs.   The fact 
there are a "take your pick" untold semantics for exception tells ya it 
will probably cause one to scratch their head than now.

I say being "Specific is Terrific!"

As Frank suggested, PASS or FAIL is just as good.  Most people don't 
need a dictionary for that.

I suggested SSP Complete, maybe good if you understand 5016.

I also suggested negative/positive classification, and this has a 
industry wide understanding and it is already in place for this type of 
work.  SMTP uses positive/negative response code and classifications 
ideas.  Spam Assassin already uses positive/negative classification as 
well as other heuristic based systems.  Odds are good you will find more 
neural networks or fuzzy logic systems play a role, if not already.

Jim's non-compliant/compliant is also straight to the point. But not 
sure it helps in laying the ground work to handling results.

While "exception" can work for me personal, I don't see it as a good 
candidate for replacing suspicious.   We might as will say "SSP Fault" 
or "SSP Failure".

My pennies of course.

-- 
Sincerely

Hector Santos, CTO

---

From: Damon <[email-masked]>
Date: Tue, 18 Dec 2007 12:49:50 -0500

> candidate for replacing suspicious.   We might as will say "SSP Fault"

We agree on most things... and this isn't one of them ;-)

I believe a better word for what you are describing is an anomaly -
which can lead to an exception. But exceptions can be specifically and
purposefully placed whereas anomalies cannot (as far as I know).
 Maybe it is just the word the "Blue Screen Of Death" uses that everyone hates.
However, I still believe the using the word "exception" would be accurate.

My point in providing the thesaurus link was that I didn't believe
that this should take up too much of our time.
Semantics - Pick a word or make one up, let's get on with more important things.

Regards,
Damon Sauer

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 18 Dec 2007 20:06:11 +0100

Douglas Otis wrote:

> "FAIL" says little about an underlying cause.

In the context of SSP "FAIL" would mean whatever the SSP spec. says
it means.  Like SPF FAIL means what RFC 4408 says, it's very simple
to show that this could be nobody's fault at all - "clueless user"
arranged 1123 5.3.6(a) forwarding to an 821-emulating RFC 4408 hop
is no "failure", normal users aren't supposed to know such details.

Besides it still works if the next hop uses "reject" as a "receiver
policy", arguably that could also work for any "SSP FAIL", or the
proverbial "odd IP on Tuesdays FAIL".

Traditional forwarding is anyway doomed since 1123 was published,
it will only get worse with the transition to "IPv6 only" senders.

> A breakdown of causes with respect to actual "exceptions" would
> help clarify the different causes that _will_ legitimately exist.

Is it "legit" if a "resending MUA" breaks Alice's DKIM signature ?

What if Alice signed that her mail had no Resent-* header fields,
is that "legit" ?  Bob can't get it right in the latter case, he'd
be forced to <eai> make another plan </eai>.  

 Frank

---

From: <[email-masked]>
Date: Tue, 18 Dec 2007 20:00:38 +0000

Sorry for joining the debate a bit late. My $.02 are below

 > some folks are used to the idea that FAIL is

I think FAIL actually has a stronger connotation than non-compliant. To me non-compliant just says it didn't comply with the published policy. It is a factual statement of the outcome of comparing this policy to the piece of data you have in front of you. FAIL doesn't feel either as neutral or as factually descriptive as that (key word there being feel, other people may have an entirely different feeling for that term).
If the concern is that people won't understand that Suspicious is a defined term and will bring their own connotative filter is that likely to be less true for FAIL?

_________________________________________________________________
Get the power of Windows + Web with the new Windows Live.
http://www.windowslive.com?ocid=TXT_TAGHM_Wave2_powerofwindows_122007

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 18 Dec 2007 21:32:07 +0100

<[email-masked]> wrote:

> I think FAIL actually has a stronger connotation than non-compliant.
[...]
> If the concern is that people won't understand that Suspicious is a
> defined term and will bring their own connotative filter is that
> likely to be less true for FAIL?

I've just checked how RFC 4408 solved this, it uses "Fail" (etc.) in
double quotes, and has a separate subsection for each of the *seven*
result codes - now here's something where SSP can do better, *seven*
is hilarious ;-)

Using upper case was no option, the 2119 keywords (MUST etc.) are
already upper case, some critical SPF terms like MAIL FROM and HELO
also use upper case (inherited rom 2821), and adding more upper case
terms would be unreadable.

SSP could use "Whatever" in double quotes, at the moment it uses
a title case Suspicious without double quotes.   For some value of
"Whatever", not necessarily "Fail" - but I think it will end up as
"hardfail" in the Authentication-Results RFC.

 Frank

---

From: Steve Atkins <[email-masked]>
Date: Tue, 18 Dec 2007 12:53:15 -0800

> "hardfail" in the Authentication-Results RFC.

+1 for "Whatever" as the descriptive term.

Cheers,
   Steve

---

From: Hector Santos <[email-masked]>
Date: Tue, 18 Dec 2007 16:04:09 -0500

> +1 for "Whatever" as the descriptive term.

hahahahaha!

So much for getting the "easy issues" out of the way. :-)

-- 
Sincerely

Hector Santos, CTO

---

From: Eliot Lear <[email-masked]>
Date: Wed, 19 Dec 2007 07:27:55 +0100

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

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 19 Dec 2007 10:16:30 -0000

> so, please explain why you are confused by the text.

How about "irregular"?

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Thu, 20 Dec 2007 11:20:04 -0500

> so, please explain why you are confused by the text.

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

---

From: Jon Callas <[email-masked]>
Date: Thu, 20 Dec 2007 10:24:48 -0800

>> so, please explain why you are confused by the text.

Irregular is also good.

I don't have any problem with "suspicious," myself, but I understand  
why some people have concerns. That's why I suggested "exception,"  
which isn't a pejorative. "Irregular" is also non-pejorative.

	Jon