Subject: [ietf-dkim] Draft summary of SSP functionality

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 10:09:54 -0800

Folks,

If non-participants are to be asked about the potential use of SSP, it helps 
to have a description of it that is concise, complete and for which there is 
reasonable consensus about the content.  Simply handing non-participants a 
point to the specification is useless for all but the most technical and 
dedicated.

To that end, I've pulled some text from my review, as a candidate.  It's 
intent is not to judge SSP but to describe its salient basis and functions. 
In other words, what is it, rather than is it good, bad or broken?

Obviously I have no expectation that my writing is entirely without judgment, 
so I would like to get some working group review of the text, to see if we can 
agree on text that is factual and useful:

The IETF's DKIM working group has followed its specification of a base method 
for associating a responsible identity to an email, via cryptographic signing,
with a draft, titled DKIM Sender Signing Practices (SSP).  The SSP 
specification describes itself as defining a mechanism "senders may use to
advertise how they sign their outgoing mail, and how verifiers should access
and interpret those results." That is, SSP permits potential DKIM signers to
publish statements about how they use DKIM, and also to publish directions for
DKIM validators (receivers) on how they are to handle a class of received
messages.

The SSP mechanism has a potential signer -- that is, the owner of a domain 
name -- publish an SSP-specific DNS TXT record, in an SSP-specific branch 
under the domain name.  On the receive-side, the domain name under which the 
DNS query is made is taken from the rfc2822.From <addr-spec> portion of an 
address, in a received message.

By associating an organization's verifiable identity to a message, the
reputation of that organization can then be used by a message receiving
engine, for determining message handling, such as whether to deliver the
message to the designated recipient.  This is what DKIM Base permits.

By contrast, SSP seeks to detect misbehaviors, specifically related to
unauthorized use of a domain in an RFC2822.From field <addr-spec>.  SSP does
not seek to deal with other identity fraud, such as in the RFC2822.From
<display-name>, the Subject field, or in the message body, or any use of 
"cousin" domains that can be confused with a target domain.

The current SSP draft provides for two basic modes of use:

    1. Unsigned message.  When a receiver gets a message that is not signed, 
they can query the DNS for an SSP record, associated with the domain name in 
the (first) rfc2822.From field header address.  If that record states that all 
mail with that domain name in the From field is signed, then the recipient can 
assume that the message is problematic.

    2. Signed message.  When a receiver gets a message that is signed, but 
which has the signature's "i=" that is different from the domain name in the 
(first) From field address, perform the SSP query, described in step 1. The 
result of this evaluation is expected to override the reputation assessment of 
the actual signer.

SSP is motivated by a desire on the part of message senders, to inform message 
recipients about constraints on the senders' practices.  The premise is that 
receivers with this additional information will be able to reject a class of 
mail that is not legitimate. The mechanism is approximate, in that a 
legitimate message might begin with a legitimate signature, but then have the 
signature get broken during transit.  When SSP is used, such messages will be 
treated by the recipient as suspect.

Given that adoption of a new mechanism, like DKIM's base signing, takes many 
years, it should be assumed that use of SSP will almost always result in a 
failed DNS query, for every message with a new (un-cached) domain name in the 
 From field.

d/
-- 

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

---

From: Steve Atkins <[email-masked]>
Date: Wed, 5 Dec 2007 10:18:21 -0800

On Dec 5, 2007, at 10:09 AM, Dave Crocker wrote:

> Folks,
>
> If non-participants are to be asked about the potential use of SSP,  
> it helps to have a description of it that is concise, complete and  
> for which there is reasonable consensus about the content.  Simply  
> handing non-participants a point to the specification is useless  
> for all but the most technical and dedicated.
>
> To that end, I've pulled some text from my review, as a candidate.   
> It's intent is not to judge SSP but to describe its salient basis  
> and functions. In other words, what is it, rather than is it good,  
> bad or broken?
>
> Obviously I have no expectation that my writing is entirely without  
> judgment, so I would like to get some working group review of the  
> text, to see if we can agree on text that is factual and useful:

This covers the mechanics of when and how an SSP record may
be queried. I think it also needs mention of what sort of assertions
an SSP record may make, in clear english

For example:

"This sender signs all mail with DKIM"

"This sender DKIM signs every third mail they send, except on  
Tuesdays (local time)".

"This sender requires that recipients discard any mail apparently  
from them that does not have a valid DKIM signature"

"This sender signs some mail with DKIM"

That sort of thing.

Cheers,
   Steve

>
>
>
>
> The IETF's DKIM working group has followed its specification of a  
> base method for associating a responsible identity to an email, via  
> cryptographic signing,
> The SSP mechanism has a potential signer -- that is, the owner of a  
> domain name -- publish an SSP-specific DNS TXT record, in an SSP- 
> specific branch under the domain name.  On the receive-side, the  
> domain name under which the DNS query is made is taken from the  
> rfc2822.From <addr-spec> portion of an address, in a received message.
>
> <display-name>, the Subject field, or in the message body, or any  
> use of "cousin" domains that can be confused with a target domain.
>
>    1. Unsigned message.  When a receiver gets a message that is not  
> signed, they can query the DNS for an SSP record, associated with  
> the domain name in the (first) rfc2822.From field header address.   
> If that record states that all mail with that domain name in the  
> From field is signed, then the recipient can assume that the  
> message is problematic.
>
>    2. Signed message.  When a receiver gets a message that is  
> signed, but which has the signature's "i=" that is different from  
> the domain name in the (first) From field address, perform the SSP  
> query, described in step 1. The result of this evaluation is  
> expected to override the reputation assessment of the actual signer.
>
> SSP is motivated by a desire on the part of message senders, to  
> inform message recipients about constraints on the senders'  
> practices.  The premise is that receivers with this additional  
> information will be able to reject a class of mail that is not  
> legitimate. The mechanism is approximate, in that a legitimate  
> message might begin with a legitimate signature, but then have the  
> signature get broken during transit.  When SSP is used, such  
> messages will be treated by the recipient as suspect.
>
> Given that adoption of a new mechanism, like DKIM's base signing,  
> takes many years, it should be assumed that use of SSP will almost  
> always result in a failed DNS query, for every message with a new  
> (un-cached) domain name in the From field.
>
>
> d/
> -- 
>
>   Dave Crocker
> NOTE WELL: This list operates according to http://mipassoc.org/dkim/ 
> ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 05 Dec 2007 10:18:27 -0800

Dave Crocker wrote:
>    2. Signed message.  When a receiver gets a message that is signed, 
> but which has the signature's "i=" that is different from the domain 
> name in the (first) From field address, perform the SSP query, described 
> in step 1. The result of this evaluation is expected to override the 
> reputation assessment of the actual signer.

Override? No. That is the receiver's decision, and SSP is silent on
that. Some receivers may choose to do that, some may use it as data
in some filtering calculus, others may ignore it altogether. I'm
firmly in the "data" camp which makes it hard for me to understand
why this is such a difficult concept.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 10:36:05 -0800

Michael Thomas wrote:
> that. 

So, you are comfortable with the rest of the text?

d/

-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 10:46:23 -0800

Probably worth distinguishing between the specific assertions that the draft 
current supports, versus the scope of additional assertions that could be 
added to the repertoire.

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Wed, 5 Dec 2007 10:59:28 -0800

On Dec 5, 2007, at 10:46 AM, Dave Crocker wrote:

> Probably worth distinguishing between the specific assertions that  
> the draft current supports, versus the scope of additional  
> assertions that could be added to the repertoire.

I don't think the latter - potential extensions - need be mentioned  
at all, as any extensions will be either private use only or will  
require additional standards work.

But there are, I think, twelve assertions that the current SSP draft  
can make. Listing which of those assertions are valid, and what  
message they are intended to communicate to the receiver, and what  
action the receiver might be expected to take on receiving them would  
be useful plain english[1] to create. If the meanings of those  
assertions change in different query scenarios (valid dkim signature  
vs no valid dkim signature, say) then those need to be enumerated too.

That's a useful thing to do in any case, to clarify what everyone  
believes the current draft means, but once it's done I suspect it can  
be converted to the short summary needed for this document.

Cheers,
   Steve

[1] Excluding meaningless or ill-defined terms such as "Suspicious"

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 5 Dec 2007 16:46:27 -0500

On Wednesday 05 December 2007 13:09, Dave Crocker wrote:
> Folks,
>
> If non-participants are to be asked about the potential use of SSP, it
> helps to have a description of it that is concise, complete and for which
> there is reasonable consensus about the content.  Simply handing
> non-participants a point to the specification is useless for all but the
> most technical and dedicated.
>
Since you've already stated you think SSP is useless, please don't muddy the 
waters with writing more stuff for us to review that serves no purpose other 
than disctraction.

Let's focus on getting the spec done and sweat the marketing later.

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Wed, 05 Dec 2007 17:27:57 -0800

Perhaps we need a better introduction in the specification, then.  The
text below isn't worded from the standpoint of a document introduction,
but it might help fill the vacuum created when the normative text in the
introduction gets moved elsewhere.

Comments below...

Dave Crocker wrote:
> helps to have a description of it that is concise, complete and for
> which there is reasonable consensus about the content.  Simply handing
> non-participants a point to the specification is useless for all but
> the most technical and dedicated.
>
> It's intent is not to judge SSP but to describe its salient basis and
> functions. In other words, what is it, rather than is it good, bad or
> broken?
>
> The IETF's DKIM working group has followed its specification of a base
> method for associating a responsible identity to an email, via
> cryptographic signing, with a draft, titled DKIM Sender Signing
> Practices (SSP).  The SSP specification describes itself as defining a
> mechanism "senders may use to advertise how they sign their outgoing
> mail, and how verifiers should access and interpret those results."
> That is, SSP permits potential DKIM signers to publish statements
> about how they use DKIM, and also to publish directions for DKIM
> validators (receivers) on how they are to handle a class of received
> messages.
>
> domain name -- publish an SSP-specific DNS TXT record, in an
> SSP-specific branch under the domain name.  On the receive-side, the

It's not really an SSP-specific branch, but an SSP-specific label under
the DKIM key management branch.

> engine, for determining message handling, such as whether to deliver
> the message to the designated recipient.  This is what DKIM Base permits.
>
> unauthorized use of a domain in an RFC2822.From field <addr-spec>. 
> SSP does not seek to deal with other identity fraud, such as in the
> RFC2822.From <display-name>, the Subject field, or in the message
> body, or any use of "cousin" domains that can be confused with a
> target domain.

That's one way to look at it.  I would describe it, instead of "detect
misbehaviors, ..." as "provide guidance to DKIM verifiers regarding
messages lacking a valid DKIM signature on behalf of the message's author."
> signed, they can query the DNS for an SSP record, associated with the
> domain name in the (first) rfc2822.From field header address.  If that
> record states that all mail with that domain name in the From field is
> signed, then the recipient can assume that the message is problematic.
>
> name in the (first) From field address, perform the SSP query,
> described in step 1. The result of this evaluation is expected to
> override the reputation assessment of the actual signer.

s/different from the domain name/different from the/  if you want to
match the current SSP draft.  Where did you get the second sentence? 
The term "reputation" occurs exactly once in the draft and it isn't
saying this.

>
> SSP is motivated by a desire on the part of message senders, to inform
> message recipients about constraints on the senders' practices.  The
> premise is that receivers with this additional information will be
> able to reject a class of mail that is not legitimate. The mechanism
> is approximate, in that a legitimate message might begin with a
> legitimate signature, but then have the signature get broken during
> transit.  When SSP is used, such messages will be treated by the
> recipient as suspect.

Rejecting messages is just one possible result.  Placing that first
emphasizes it, in my opinion inappropriately.  What you fail to mention
is that there are domains who would like precisely this to happen:  if
their message gets broken, even inadvertently in transit, they want it
rejected.
> (un-cached) domain name in the From field.

This is a true statement, but not something that I think needs to be in
an introduction to the technology.  There are lots of things that result
in failed DNS queries (IPv6 AAAA requests come to mind), and that
doesn't seem to be a problem.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Wed, 05 Dec 2007 18:38:34 -0800

>> domain name -- publish an SSP-specific DNS TXT record, in an SSP-specific
>> branch under the domain name.  On the receive-side, the domain name under
>> which the DNS query is made is taken from the rfc2822.From <addr-spec>
>> portion of an address, in a received message.
> 
> It's not really an SSP-specific branch, but an SSP-specific label under the
> DKIM key management branch.

What does it mean to have an SSP-specific label that is not an SSP-specific
branch?

>> unauthorized use of a domain in an RFC2822.From field <addr-spec>. SSP
>> does not seek to deal with other identity fraud, such as in the 
>> RFC2822.From <display-name>, the Subject field, or in the message body,
>> or any use of "cousin" domains that can be confused with a target domain.
>> 
> 

You don't think that a status label of "suspicious" implies a focus on
misbehaviors?

-base is careful to say that there is no semantic to be taken from the absence
of a valid signature.  -ssp is explicitly for the purpose of creating
semantics about the absence of any signature or an acceptable signature.

As for "detecting" versus "providing guidance" these focus on very different
levels, which I guess I think are are complementary. The former is higher
level, IMO, while the latter is more about the mechanism.  The text discusses
things in terms of their basic thrust.  There is a conceptual difference
between the nature of the use of DKIM signing versus SSP.

>> they can query the DNS for an SSP record, associated with the domain name
>> in the (first) rfc2822.From field header address.  If that record states
>> that all mail with that domain name in the From field is signed, then the
>> recipient can assume that the message is problematic.
>> 
>> which has the signature's "i=" that is different from the domain name in
>> the (first) From field address, perform the SSP query, described in step
>> 1. The result of this evaluation is expected to override the reputation
>> assessment of the actual signer.
> 

If I did the specified edit properly, that produces:

     When a receiver gets a message that is signed, but
     which has the signature's "i=" that is different from the
     in the (first) From field address...

I assume the point of the edit is to include full addresses.

On reading the result, I'm inclined to suggest "...signature's i= value that
is different..."

> match the current SSP draft.  Where did you get the second sentence? The
> term "reputation" occurs exactly once in the draft and it isn't saying
> this.

Do envision a reasonable scenario where a receiver has adopted SSP and
conforms to it, but does not have the stated sender enforcement request
override the reputation assessment for a signer?  Note that this either
implies or explicitly violates the request of the SSP domain owner.

Could you provide some examples of such scenarios?

>> premise is that receivers with this additional information will be able
>> to reject a class of mail that is not legitimate. The mechanism is
>> approximate, in that a legitimate message might begin with a legitimate
>> signature, but then have the signature get broken during transit.  When
>> SSP is used, such messages will be treated by the recipient as suspect.
> 

The section 2.9 text "a Verifier may decide the message should be accepted on
the basis of other information beyond the scope of this document" at first
seems to support your view, but I think a bit of reflection changes that.

While the text explicit notes that rejection is not the only action that can
be taken, the language actually assumes that it will be typical and that an
outcome other than rejection is, frankly, exceptional.

Some of this depends on just how pragmatic and honest we want to be in stating
what the goals of SSP publishers actually are and what the likely practices of
receivers who adopt SSP will be.

If the summary is to achieve the goal of meaningfully help others to
understand the "nature" off SSP then the text needs to have more than
mathematical purity of diplomatically and formally careful specification
language.  It needs to broach issues of motives and expected uses.

> their message gets broken, even inadvertently in transit, they want it 

I think that some of these concerns get taken care of by expanding the text to
explicitly list the range of assertions that Steve Atkins suggested.

>> Given that adoption of a new mechanism, like DKIM's base signing, takes
>> many years, it should be assumed that use of SSP will almost always
>> result in a failed DNS query, for every message with a new (un-cached)
>> domain name in the From field.
> 
> This is a true statement, but not something that I think needs to be in an
> introduction to the technology.

Why?  A factually correct statement about performance and utility of a
technology is typically considered to be a reasonable part of a summary for it.

> There are lots of things that result in failed DNS queries (IPv6 AAAA
> requests come to mind), and that doesn't seem to be a problem.

Your comment suggests that a lengthy discussion is needed about the nature and
import of particular protocol behaviors.  For now I will leave it at noting
that patterns of DNS query failure have a long history of being considered to
be important.

At base, you seem to be suggesting that statements about overhead and failures
isn't all that important.  My view is that it is necessary to know such things
in order to formulate a proper opinion about the mechanism.

d/
-- 

   Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 05 Dec 2007 23:32:38 -0600

If what you say is true then we should shore up the Introduction. 
Failing that, I propose that we focus working group time on working 
group deliverables.  This isn't one of them.

Arvel

Dave Crocker wrote:
> intent is not to judge SSP but to describe its salient basis and 
> judgment, so I would like to get some working group review of the text, 
> to see if we can agree on text that is factual and useful:

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 06 Dec 2007 01:39:07 -0600

Ok, took the bait, couldn't resist, sorry :)

 > misbehaviors?.

I know you didn't ask me this, but (sorry), if we decide to change 
"Suspicious" to something else then we might as well go fully P.C. and 
change it to "a message of interest."  We've all seen the police on the 
news before:  "Yes, the suspect was detained for questioning... Uh, 
<looks around to see if anyone caught that>, I meant, the person of 
interest was detained..."  If anyone thinks what I've just said is silly 
then perhaps you can see why much of this dancing back and forth on 
egg-shells is just getting a bit boring.  I've got a dictionary. 
Suspicious is the right word.  I'm inclined to leave it.  But if we 
change it, please don't use "a message of interest."  I think they'll 
kill me for that in Texas.

 > Do [you] envision a reasonable scenario where a receiver has
 > adopted SSP and conforms to it, but does not have the
 > stated sender enforcement request override the reputation
 > assessment for a signer?  Note that this either implies
 > or explicitly violates the request of the SSP domain owner.

I know you didn't ask me this question either (sorry) but what I can 
easily imagine is a scenario in which a receiver has adopted SSP and 
conforms to it, but decides to set it aside in the presence of a valid 
signature from an entity that it trusts.

 > Could you provide some examples of such scenarios?

You didn't ask me, but yes, I can.

(a) My software has a global white list feature.  That white list 
contains any number of identities from which validly signed messages are 
trusted.  When encountered, no SSP.

(b) My software allows individual users to maintain their own address 
books.  The domain of any entry therein can be configured as a trusted 
identity.  When validly signed messages arrive from such identities 
bound for said users, no SSP.

(c) My software includes call outs to a certification service.  Use of 
the service is predicated upon trust in the certifier.  When validly 
signed messages arrive from identities which the certification service 
says it's in love with, no SSP.

(d) Although this isn't completely fleshed out yet I hope my software 
will someday have a transparent framework for using any domain-based 
reputation service.  Use of such services are predicated upon trust in 
the service provider.  When validly signed messages arrive, etc. etc.

Compared to many on this list, I'm a relative idiot in the software 
business.  Imagine what somebody with a real brain might be able to come 
up with.

Arvel

---

From: Hector Santos <[email-masked]>
Date: Thu, 06 Dec 2007 03:42:17 -0500

> business.  Imagine what somebody with a real brain might be able to come 

Please don't say that.  You're are not alone.  We have completely 
different mindsets and disciplines here, and sometimes "never the twain 
shall meet."

People like us, and I honestly don't want to suggest you agree with me, 
are very keen to see how this all fits.  The hope is that our 
engineering is rich enough so that we can recognize the risk associated 
with over simplification and also appreciate the operations, 
administrators, "controllers" and "keepers" of the network point of view 
as well.

At the end of day, to me, like you, it is very simple. DKIM and SSP were 
very simple concepts to begin with and the "mess" began when we began to 
separate the two, and it should be noted, the two PRO and CON camps 
simply need came to an agreement. There were outside ambitions that were 
clearly out of scope - mixing in reputation.

That does not suggest mixing in reputation was wrong.  It means it 
should of been the original focus if this was what people wanted to 
concentrate on.  As it was, there were entities that went on their 
separate ways and created reputation based systems bypassing any IETF 
working group engineering.

So yes, we if want to be talking reputation systems, fine, thats great, 
lets remain focus with that design and work it out.

But SSP is not about reputation and if we want to complete SSP, we need 
to separate and stop with the muddying the water with reputation 
considerations.

 From a implementation standpoint, they both still fits together as you 
clearly pointed out in your Software feature A, B and C, and hopefully 
D.   That is common sense - to me. :-)

-- 
Sincerely

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

---

From: John Levine <[email-masked]>
Date: 6 Dec 2007 16:26:51 -0000

>change it to "a message of interest."

How about changing it to something descriptive like "not SSP
validated"?  That's what it is, after all.

We're much better off describing what the software does rather than
implying what we the recipient might think about it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 06 Dec 2007 08:42:23 -0800

> Could you provide some examples of such scenarios?

Yes, trivially. Look at the way Spamassassin works. It grades various
message features numerically where positive is spammy and negative is
hammy. Were Spamassassin to incorporate SSP information, I would expect
that -- just like their use of DNSBL's -- SSP might be like:

SSP_STRICT_FAIL = 4
SSP_ALL_FAIL = 2
SSP_UNKNOWN = 0

Where you need to get to 5 to be declared spam. A 4 score is usually
a death sentence for a message, but not necessarily. An all fail means
essentially that the message better be on its best behavior.

Spamassassin actually tunes these numbers using their message corpus
to get acceptable false negative/false positive rates. Lots of other
spam filters work essentially the same way. That is, they don't count
on silver bullets whatsoever. SSP used in this way is *exactly* the
right kind of information that a spam filter wants: more, and
*reliable* (fsvo reliable), information so that can make a better
estimate.

	Mike

PS: note that this is the reason I'm dubious to hostile to the addition
     of the new "disposition" stuff in the SSP record. I don't think it
     provides anything new or useful, and in fact leads to the
     possibility of silly states like strict/pass.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Thu, 06 Dec 2007 08:57:28 -0800

Michael Thomas wrote:
>> conforms to it, but does not have the stated sender enforcement ...
> 
> Yes, trivially. Look at the way Spamassassin works...
> 
> SSP_STRICT_FAIL = 4
> SSP_ALL_FAIL = 2
> SSP_UNKNOWN = 0

That's the problem with a vague spec.  I didn't mean to ask for a description 
of how this might be done, but a discussion of the likelihood it would.

To use your example, where 5 declares spam, why is the configuration likely to 
set STRICT to 4 rather than 10 or 100, given the semantics of Strict?

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 06 Dec 2007 09:03:04 -0800

Dave Crocker wrote:
> That's the problem with a vague spec.  I didn't mean to ask for a 
> description of how this might be done, but a discussion of the 
> likelihood it would.

   Well, Pat Peterson has already chimed in here. And I know that the
   SA guys already incorporate DKIM, so I'd say that the chances are
   pretty high that they will. Or are you asking me or other people to
   document this with PRD's to your satisfaction?

   FWIW: I have hacked SA to do exactly this, so there is even an
   existence proof.

> To use your example, where 5 declares spam, why is the configuration 
> likely to set STRICT to 4 rather than 10 or 100, given the semantics of 
> Strict?

   Why does this matter? It's an implementation detail. You only asked
   whether people would use SSP that way. The answer is a resounding yes.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 06 Dec 2007 09:06:48 -0800

> implying what we the recipient might think about it.

or better is unknown, strict/fail, all/fail. _what_ practice didn't
pass muster is useful since they aren't all saying the same thing.
I think this also related to issue 1513 I raised.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 06 Dec 2007 09:43:30 -0800

Michael Thomas wrote:
>> likely to set STRICT to 4 rather than 10 or 100, given the semantics 
>> of Strict?
> 

What an interesting perspective.  The degree of weight that gets used for this 
feature is merely an implementation detail, rather than a fundamental test of 
the mechanism's utility.

For reference I asked a different question than you chose to hear, but I think 
we have sufficiently demonstrated that this exchange cannot be productive.

d/
-- 

   Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 06 Dec 2007 11:47:53 -0600

> implying what we the recipient might think about it.

I think that's fine.  This issue isn't a show-stopper in my opinion.

Arvel

---

From: Michael Thomas <[email-masked]>
Date: Thu, 06 Dec 2007 11:31:03 -0800

Dave Crocker wrote:
> What an interesting perspective.  The degree of weight that gets used 
> for this feature is merely an implementation detail, rather than a 
> fundamental test of the mechanism's utility.

   I can't speak for Spamassassin, I'm not one of their developers
   and I don't know the intricacies of how they choose values. It
   appears that you're just trying to be argumentative here since
   you've seemingly dismissed the larger point that anti-spam filters
   rarely use individual pieces of information as a silver bullet.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 06 Dec 2007 11:43:00 -0800

>   rarely use individual pieces of information as a silver bullet.

You think it is argumentative that, for example, a protocol element that 
directs a recipient to Reject mail will typically be adhered to and that 
conforming to SSP but not adhering to that explicit request is unlikely?

This sort of heuristic approach to protocol specification and interpretation 
usually has a poor outcome in Internet-scale services.

d/

ps. Another question that has solidly emerged is whether you can discuss this 
topic without ad hominems.

-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 06 Dec 2007 19:52:34 +0000

Dave Crocker wrote:
>
> You think it is argumentative that, for example, a protocol element
> that directs a recipient to Reject mail will typically be adhered
> to and that conforming to SSP but not adhering to that explicit
> request is unlikely?

This seems to be a discussion of issue 1513 [1], in fact
raised by Mike, and where the two of you may in fact agree (while
doing a great job of appearing to disagree:-)

Stephen.

[1] https://rt.psg.com/Ticket/Display.html?id=1513

---

From: Jim Fenton <[email-masked]>
Date: Thu, 06 Dec 2007 17:03:38 -0800

> implying what we the recipient might think about it.
Seems a little circular to me.  "not SSP validated" might also be
interpreted as, "we haven't applied SSP to this message", even though we
know that SSP doesn't really "validate" messages at all.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 06 Dec 2007 17:08:47 -0800

Good point, Arvel and Scott K.  I'm happy to participate in a discussion
of the Introduction, but not a separate non-deliverable.

-Jim

Arvel Hathcock wrote:
>> handing non-participants a point to the specification is useless for
>> all but the most technical and dedicated.
>>

---

From: Michael Thomas <[email-masked]>
Date: Fri, 07 Dec 2007 08:41:17 -0800

> know that SSP doesn't really "validate" messages at all.

What's wrong with "Fails the SSP X test" for x = all,strict? That is
what is happening. Adding "suspicion" only muddies the waters as
it's a value judgment. Let the filter writers and other consumers of
SSP make that value judgment, and then we don't have to come
to an agreed upon -- and mostly likely very idiosyncratic -- meaning
of the word.

I'll again state that I don't understand the seeming aversion to more
than one bit for the outcome of the SSP test. It's like trying to shoehorn
all of SMTP's response codes into 200 ok and 500 fail. It's far more
useful to enumerate the actual reasons for success and failure from a
developer standpoint because I want to take different actions based
on why and what something passed/failed.

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 07 Dec 2007 08:57:03 -0800

> What's wrong with "Fails the SSP X test" for x = all,strict? That is

By way of looking for a single "word", albeit an unfortunately geeky one, how 
about Strict-Fail?

> all of SMTP's response codes into 200 ok and 500 fail.

The codes have grown slowly.  It's called crawling before walking.  Always a 
good idea, before walking for the first time.

d/

-- 

   Dave Crocker