date:20071206



On Dec 6, 2007, at 10:36 PM, Scott Kitterman wrote:


On Friday 07 December 2007 00:46, Steve Atkins wrote:


The first step would be a group consensus on what the threats
are ("what SSP is supposed to be for"), or at least a superset of
what most people think.

Anyone? Bueller?


I, for one, feel like we did this in great depth during and before the
requirements development.  My suggestion would be to look to the  
work we've

already done and refresh your memory on the established consenses.


I recall two suggestions from there. Neither were considered in any
depth.

1. Domain forgery. That's not a "threat". It's an intermediate step,  
at most.


2. Phishing.

So that's one.

Got any others?

Cheers,
  Steve

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: threat modeling & use cases (was RE: [ietf-dkim] Tracing SSP's paradigm change

On Friday 07 December 2007 00:46, Steve Atkins wrote:

> The first step would be a group consensus on what the threats
> are ("what SSP is supposed to be for"), or at least a superset of
> what most people think.
>
> Anyone? Bueller?
>
I, for one, feel like we did this in great depth during and before the 
requirements development.  My suggestion would be to look to the work we've 
already done and refresh your memory on the established consenses.  I'm 
assuming this isn't the play the game over until you get the result you want 
game.

Scott K
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] A perspective on what SSP is attempting

Dave Crocker wrote:
> Among the various discussions I've had today, one
> comment about SSP struck me as worth wider consideration:
>
>  SSP is one organization's attempt to tell another
>  what it should do with mail that is from a third
>  organization.

We can always get in trouble with the semantics David.

I would rather view it as an organization's exposure using an world wide 
database (DNS) of its DIM policy on how its domain is being used with DKIM.

Please try to consider this, not saying you have to agree, just please 
do take some of your time to consider these points. I apologize for the 
length, but I hope I can summarize many of the key issues, discussions 
and consensus which included specifically addressing your statement 
above.  Of course, this is all my opinion, but I hope I am on par with 
the major issues and consensus reached.

Consider the following:

  - Organization ABC may desire that its email domain property is
exclusively used only by the organization. There is no
outsourcing,  no clearing house, and it has a company policy
with provisions that mandates domain brand protections
by restricting employee external usage of its domain for
non-company related  communications.

All mail is DKIM signed by the domain. No exception.

  - Organization XYZ may desire that its email domain property is
exclusively used only by the organization and exclusively
with a 3rd party service (3PS) vendor for distributing special
mail as well.  The company policy mandates its domain
brand be protected by restricting employee external usage
of its domain for non-company related communications, and that
all mail with the company domain must be signed by its internal
mail operations or by the exclusive 3PS service vendor.

All mail is DKIM signed by the domain or by the 3PS vendor.
No exception.

  - Such organizations, with the available technology, have a
expectation that implementing this technology would help in
reduction the today's obvious problematic fraudulent usage.
They would prefer that any compliant receiver able to detect
fraudulent usage with 0% false positives, and *classified" it
for rejection.

Now, please consider these two very important points. They are vital 
considerations:

  - Consider that RFC 4871 places a new "responsibility" on the
domain owner for signing mail with DKIM. As such, there is
also inherent and expected equal responsibility on the DKIM
receiver to assist in the disseminating process.

  - The key general industry problem is the handling unauthenticated
x821 anonymous, unsolicited message transactions. If there is no
information about the sender, it is currently difficult, with no
standard protocol, to make any assessment, good or  bad, about
the sender and/or domain.

So what does that mean?

It means, at least for a system like us, and I believe many work in the 
similar manner, if the 2821 session is authenticated, there we skip most 
or all filtering concepts.  DKIM is very likely to fall in this category 
as well.  I believe the main reason is because we have more faith in the 
legitimacy of an x821 authentication based transaction.  That faith is 
increased with local white listing.  There is still methods to detect 
abuse by compromised authenticated users, but for the most part, these 
additional filters are generally skipped or reduced to possibly only AVS 
scanning with authenticated sessions.

So this is mostly about dealing with the anonymous sender.

How do we change the anonymity of the sender?

Well, first we need to decide "who is the sender?"  This seems to be a 
source of contention in this group.

Regardless of who or what is the sender, the commonality is the 
fundamental concept of finding the "anchor" for the discovery process.

We, as a group, decided the established universal entity for the 
authorship of the message is the x822.From address domain and that would 
be the "anchor.".  I believe a main reason is that required by x822 to 
be present, especially when there no other markers, such as a DKIM 
signature, in the message.

We can not guarantee the Sender: address will be there and if we wanted 
to use this, then I believe we are forced back to a x821 design because 
if missing, the only reasonable substitute is the Return-Path:.

  Note: In past SPF/Sender-ID analysis input for the FCC, I
  found for ~80-84% of the time, the following domain
  association holds true in non-list server environments:

x821.MailFrom == x822.From [== x822.Sender if present]

  With such a result, it reflected the potentially higher
  payload overhead with Sender-ID vs SPF operations with
  no payload overhead.

So the From: address is the most reasonable and most practical anchor 
available to today for  an unsolicited, anonymous, including unsigned 
transaction to perform a SSP lookup.

If a do

Re: threat modeling & use cases (was RE: [ietf-dkim] Tracing SSP's paradigm change



On Dec 6, 2007, at 9:31 PM, J D Falk wrote:


Steve Atkins wrote:

There's a long discussion to be had there, which starts with me  
asking

"Well, what's your threat model?" and would ideally follow with "So,
given this framework, what is your attack tree, and how does SSP help
thwart it?", but when I've tried to have that discussion in the past
it's not gone anywhere productive


At the meeting on Tuesday, I suggested that one way to settle the  
d= vs.
i= debate would be to document the many overlapping yet divergent  
likely
use cases -- and was promptly asked to do so.  Hooray for  
volunteerism!


I think the threat modeling may be yet another instance where we're  
all

taking past each other because we have different threats in mind
, so (unless there's stringent objection) I'm going to include
threats/concerns in that document as well.


The first step would be a group consensus on what the threats
are ("what SSP is supposed to be for"), or at least a superset of
what most people think.

Anyone? Bueller?

Cheers,
  Steve

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

threat modeling & use cases (was RE: [ietf-dkim] Tracing SSP's paradigm change

2007-12-06 Thread J D Falk

Steve Atkins wrote:

> There's a long discussion to be had there, which starts with me asking
> "Well, what's your threat model?" and would ideally follow with "So,
> given this framework, what is your attack tree, and how does SSP help
> thwart it?", but when I've tried to have that discussion in the past
> it's not gone anywhere productive

At the meeting on Tuesday, I suggested that one way to settle the d= vs.
i= debate would be to document the many overlapping yet divergent likely
use cases -- and was promptly asked to do so.  Hooray for volunteerism!

I think the threat modeling may be yet another instance where we're all
taking past each other because we have different threats in mind, so
(unless there's stringent objection) I'm going to include
threats/concerns in that document as well.

Right now I'm on a flight back to Colorado, then on vacation for a few
days, so the questions for this project will show up next week.  Feel
free to send me any additional thoughts in the meantime.

Your most humble servant,

--
J.D. Falk
Receiver Products
Return Path 

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change

2007-12-06 Thread John Levine

>I'm sympathetic to this perspective.  I think we have two broad
>groups here.  One believes that SSP has utility and one believes that
>it doesn't.

I wouldn't object to a version of SSP that stuck to publishing
senders' practices, and I doubt anyone else would either.
Unfortunately, the current draft is about 1/4 sender practices and 3/4
other stuff.  It's the other stuff that's the problem.


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] A perspective on what SSP is attempting

On Thu, 06 Dec 2007 18:22:00 -0800 Dave Crocker <[EMAIL PROTECTED]> wrote:
>Among the various discussions I've had today, one comment about SSP struck 
me 
>as worth wider consideration:
>
>  SSP is one organization's attempt to tell another
>  what it should do with mail that is from a third
>  organization.

If you mean from as in 2822.From, then no.  If you mean from as in 
delivered by MTA operated by an entity not controlled the 2822.From domain 
owner, then sure.

I'd say suggest rather than tell, since we all know senders can't tell 
receivers what to do, but generally, that's exactly the point.

Scott K
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Re: Tracing SSP's paradigm change

On Thu, 6 Dec 2007 16:12:05 -0800 Steve Atkins <[EMAIL PROTECTED]> wrote:
>
>On Dec 6, 2007, at 4:08 PM, Frank Ellermann wrote:
>
>> Steve Atkins wrote:
>>
>>> part of the push to try and build a next generation SPF
>>
>> No push in that direction on any SPF or IETF list I know,
>> in fact discussing 2822 originator header fields on SPF
>> lists would be on the border to "off topic" (excl. PRA
>> for various and known reasons).
>>
>> A "part of the push" sounds like more than one or two
>> contributors, are you talking about Doug's TBR draft ?
>> That's IMO no SPF-TNG, it might be a kind of SMTP-TNG.
>
>I was referring to SSP, which is trying to be the next SPF
>(and, in strict mode, is identical in functionality to a subset of
>SPF).
>
What subset of SPF is that?  I'm intimately familiar with SPF and I'm not 
following you.

Scott K
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] A perspective on what SSP is attempting

Among the various discussions I've had today, one comment about SSP struck me 
as worth wider consideration:


 SSP is one organization's attempt to tell another
 what it should do with mail that is from a third
 organization.

c/
--

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

[ietf-dkim] Re: Issue tracker URL

2007-12-06 Thread Eliot Lear

Arvel asked a very good question:
 
> Eliot, could you tell me the URL to the issue tracker.  I've lost it
> and having a hard time finding where this is posted.
>

Sure.  It's https://rt.psg.com.  Login is ietf password is ietf.

Eliot
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Re: Issue #1512: Re: making SSP useless in one short step

2007-12-06 Thread John L


In that case, what is the SSP result when a message does not contain a
valid Originator Signature, and the Originator Domain has a policy of "all"?


"not compliant"


The whole business about third-party signatures is a DKIM-based
mechanism to decide what to say in that case.  If the verifier sees
another signature that they "like", the result is "not Suspicious".


If the recipient sees another signature it likes, it's not going to do
an SSP lookup at all, so I don't see any value in giving recipients 
directions for a situation that won't happen.


R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Re: Tracing SSP's paradigm change

2007-12-06 Thread Frank Ellermann

Steve Atkins wrote:

> I was referring to SSP, which is trying to be the next SPF
> (and, in strict mode, is identical in functionality to a
>  subset of SPF).

SSP is farer away from SPF than PRA.  SPF is about SMTP, not
not originator header fields, and it's about backscatter,
not phishing, an SPF PASS means something even it's from an
unknown stranger, an SSP PASS from unknown strangers means
nothing.  SSP and SPF are very different.  SSP and PRA might
share some functionality, with different weak spots.  PRA has
of course all weak spots of SPFs adding its own.  

SSP has the "first author" when the terminology is fixed, as
Dave proposed it.  At that point I always stop thinking, the
"first author" is just too odd for my tastes - like the idea
that a mailing list could simply *replace* an existing Sender
header field.  I guess I wrote that more than often enough
here, the WG wants to try it anyway, let's see what happens.

 Frank

___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

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

2007-12-06 Thread Jim Fenton

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:
> 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:
>> 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:
>
> ___
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
>
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] NEW ISSUE: suspicious terminology

2007-12-06 Thread Jim Fenton

John Levine wrote:
>> 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."
>> 
>
> 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.
>   
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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Re: Issue #1512: Re: making SSP useless in one short step

2007-12-06 Thread Jim Fenton

John Levine wrote:
>> Which is a long winded version of that third party signatures are
>> completely orthogonal to SSP. "All" should just mean "I sign all of
>> my mail". No more, no less.
>> 
>
> +1
>
> R's,
> John
>
> PS: Mike and I agree on something! Alert the media!
>   

In that case, what is the SSP result when a message does not contain a
valid Originator Signature, and the Originator Domain has a policy of "all"?

The whole business about third-party signatures is a DKIM-based
mechanism to decide what to say in that case.  If the verifier sees
another signature that they "like", the result is "not Suspicious".

-Jim
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Re: Tracing SSP's paradigm change



On Dec 6, 2007, at 4:08 PM, Frank Ellermann wrote:


Steve Atkins wrote:


part of the push to try and build a next generation SPF


No push in that direction on any SPF or IETF list I know,
in fact discussing 2822 originator header fields on SPF
lists would be on the border to "off topic" (excl. PRA
for various and known reasons).

A "part of the push" sounds like more than one or two
contributors, are you talking about Doug's TBR draft ?
That's IMO no SPF-TNG, it might be a kind of SMTP-TNG.


I was referring to SSP, which is trying to be the next SPF
(and, in strict mode, is identical in functionality to a subset of
SPF).

Cheers,
  Steve

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Re: Tracing SSP's paradigm change

2007-12-06 Thread Frank Ellermann

Steve Atkins wrote:

> part of the push to try and build a next generation SPF

No push in that direction on any SPF or IETF list I know,
in fact discussing 2822 originator header fields on SPF
lists would be on the border to "off topic" (excl. PRA
for various and known reasons).  

A "part of the push" sounds like more than one or two
contributors, are you talking about Doug's TBR draft ?
That's IMO no SPF-TNG, it might be a kind of SMTP-TNG.

 Frank

___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change



On Dec 6, 2007, at 11:40 AM, Michael Thomas wrote:


Steve Atkins wrote:

On Dec 6, 2007, at 9:29 AM, Michael Thomas wrote:

Steve Atkins wrote:

On Dec 6, 2007, at 8:57 AM, Michael Thomas wrote:

Dave Crocker wrote:

Michael Thomas wrote:
And as far as I can tell, you alone seem to be carrying this  
torch
here. Changing what we agreed on with rfc5016 should require  
a very
high barrier. I see little if any support, let alone broad  
consensus

that we got it wrong.


  You still didn't respond: did you read 5016 before it was  
issued?
  In fact I know that you did because you gave a lot of very  
detailed
  feedback. And this was not one of the thing you commented on  
at the

  time, so charges of "paradigm change" ring rather hollow.

So, you missed the postings by Levine and Atkins?  (Perhaps  
some others were on "my" side of this topic, but these two  
were at least quite explicit.


  I didn't read them as supporting your reading. Let them speak  
for
  themselves. There are a lot of things being discussed, after  
all.

I broadly agree with most of Dave's concerns...


Believe it or not, I agree with some of Dave's too. But that isn't
the issue at hand. The specific issue is whether *any* DKIM  
signature
from *any* domain should be sufficient to qualify for "strict" or  
"all".

Do you agree with that or not?

In a well-designed protocol based on DKIM, yes I'd agree that a
validly DKIM signed message should not provoke an SSP query.


(Michael removes the relevant comment here, let me re-add it).


But that's not the protocol we have.


I agree, in principle, with Dave's view that a valid DKIM
signature should not provoke additional DNS queries
for self-published policies.

However I do not believe that SSP does not require
that, from my reading of the current drafts.




  This is rather astonishing, and then you go on to say:

I think RFC 5016 shows a lack of understanding of DKIM (or is  
choosing

not to consider some important features of DKIM), and is
part of the push to try and build a next generation SPF on
an inappropriate base authentication technology.


  Gee thanks, I am new on this block I guess.

  In any case, the problem that I'm having with a lot of the nay- 
sayers

  is that it is purely destructive rather than constructive feedback.
  The feedback is always of the nature of this is wrong, not what will
  correct the problem. When I raise issues, I suggest a change to make
  the spec better. If you don't suggest concrete changes to the draft,
  it's really sort of hard to take you or anybody else seriously.
  Frankly if you think this is just a piece of junk, I really don't
  understand why you or Dave or John waste your time.


RFC 5016 isn't based on a clear articulation of what threat
SSP is supposed to defend against. It's also based on the
misconception that if a sender DKIM signs a mail then it
will still be signed on receipt (I understand that you know
that that isn't the case, but a lot of the document appears to
be based on simply ignoring that fact). It's a good solid
description of what a protocol should look like, and many
of the points it does bring up are good ones - but it's
based on false assumptions.

Given that, any suggested changes aren't going to be
wordsmithing, they're going to be wholesale rewrites
which will both be rejected by the document owner and
cause yet more aggravation, noise and personal attacks
here (the level of discourse is so coarse that everyone,
myself included, is letting their frustration leak through
into the discussion). What's the point? My goal is not
to annoy people, it's to improve the quality of the global
email infrastructure.

If you want to work on an analysis of SSP, based on an
honest evaluation of the weaknesses of DKIM on which
it's based, a clear articulation of the threat it intends to
thwart and a real analysis of the actual threat model and
the ways in which SSP can alleviate it, and the harmful
side effects that doing so may have on email in general
then that would be a useful document for the group to
put together and a good use of time.

Minor wordsmithing of an existing document based on
invalid lemmas may improve that documents clarity, but
doesn't seem like the most useful use of time.

Cheers,
  Steve

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change


Steve Atkins wrote:

Steve, were you not involved in the lengthy threat analysis 
discussions and production of RFC 4686?


The vast majority of that discusses threats against DKIM
in particular, primarily a rehash of the normal attacks
against PKI and DNS.

What I'm talking about is "the general threat that SSP is
intended to counter", which is a completely different,
and mostly unrelated thing (though I suspect that part
of the attack tree would involve the issues discussed
there). I've not seen that discussed in any clear, let
alone formal, manner, I don't think.


Well, I hate to be accuse of being respectful, but I disagree.

There has been at least 2+ years of long discussions on nearly every 
security aspect, every one regarding SSP, including its relationship 
with DKIM.


Every item was discussed, debated and argued. I even wrote a IETF I-D 
called DSAP that addressed nearly everything we are talking about here 
with a primary focus on the security threats. I wrote detailed outlines 
and provided boundary charts that provided the possible scenarios and 
events based on the possible results for DKIM plus SSP. There was an 
appreciation by many people for these analysis charts.


If one chooses to ignore people, deemed it not formal, not worthy or not 
qualified your input, or maybe you just finally recognizing it, fair 
enough. But it is really unfair suggest to everyone it never happen, nor 
the time and energy wasn't put in.


Since the very first SSP draft, the top concerns

   - Redundant SSP lookups
- including when it is applied.
   - What does "Exclusive" mean?
   - Types of policies
   - 3rd party signatures - how to control it

They were discussed, over and over and over again many times. 
Unfortunately, it appears, although with the compromises made by both 
camps, the finer points still haven't been resolved.


The other significant conflictive problem:

- Reputation vs SSP

The out of scope concept continues to rears its head.  Some people felt 
there was an undermining going with SSP, that it would never work, but 
lets see where it goes. But it was like reputation was the ultimate way 
to do it, hence no need to use SSP was the basic philosophy you felt in 
the air.


--
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

Issue #1513, (was: Re: [ietf-dkim] Draft summary of SSP functionality)

2007-12-06 Thread Stephen Farrell


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

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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




Michael Thomas wrote:

  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.



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
  Brandenburg InternetWorking
  bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change


Steve Atkins wrote:


On Dec 6, 2007, at 9:29 AM, Michael Thomas wrote:


Steve Atkins wrote:

On Dec 6, 2007, at 8:57 AM, Michael Thomas wrote:

Dave Crocker wrote:

Michael Thomas wrote:

And as far as I can tell, you alone seem to be carrying this torch
here. Changing what we agreed on with rfc5016 should require a very
high barrier. I see little if any support, let alone broad consensus
that we got it wrong.


  You still didn't respond: did you read 5016 before it was issued?
  In fact I know that you did because you gave a lot of very detailed
  feedback. And this was not one of the thing you commented on at the
  time, so charges of "paradigm change" ring rather hollow.

So, you missed the postings by Levine and Atkins?  (Perhaps some 
others were on "my" side of this topic, but these two were at least 
quite explicit.


  I didn't read them as supporting your reading. Let them speak for
  themselves. There are a lot of things being discussed, after all.

I broadly agree with most of Dave's concerns...


Believe it or not, I agree with some of Dave's too. But that isn't
the issue at hand. The specific issue is whether *any* DKIM signature
from *any* domain should be sufficient to qualify for "strict" or "all".
Do you agree with that or not?



In a well-designed protocol based on DKIM, yes I'd agree that a
validly DKIM signed message should not provoke an SSP query.


  This is rather astonishing, and then you go on to say:


I think RFC 5016 shows a lack of understanding of DKIM (or is choosing
not to consider some important features of DKIM), and is
part of the push to try and build a next generation SPF on
an inappropriate base authentication technology.


  Gee thanks, I am new on this block I guess.

  In any case, the problem that I'm having with a lot of the nay-sayers
  is that it is purely destructive rather than constructive feedback.
  The feedback is always of the nature of this is wrong, not what will
  correct the problem. When I raise issues, I suggest a change to make
  the spec better. If you don't suggest concrete changes to the draft,
  it's really sort of hard to take you or anybody else seriously.
  Frankly if you think this is just a piece of junk, I really don't
  understand why you or Dave or John waste your time.

Mike
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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


Dave Crocker wrote:



Michael Thomas wrote:
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.



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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change

2007-12-06 Thread Douglas Otis



On Dec 6, 2007, at 9:29 AM, Michael Thomas wrote:
The specific issue is whether *any* DKIM signature from *any* domain  
should be sufficient to qualify for "strict" or "all".


Do you agree with that or not?


This question appears to miss the point.  When examining the domain of  
the From, a valid signature by that domain on behalf of _any_ header  
should be sufficient to comply with a "strict" assertion.  The only  
exception need would be for restricted keys.  As Originating Signature  
is defined, this is not the case.


Dave's comment was about DKIM offering evidence of a domain's  
responsibility.  This concept has been missed by the current  
definition for Originator Signature.  Messages that are not signed or  
signed by different domains would be a separate issue.  The "all"  
assertion requires _at least a valid_ signature acceptable to the  
verifier.  At least the definition for "all" is correctly at the domain.


-Doug
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change



On Dec 6, 2007, at 10:30 AM, Hector Santos wrote:


Steve Atkins wrote:

Bill Oxley observed across threads "When it comes to discussing
SSP I hear a lot of noise with very little reason to implement or use
except in a few specific cases like highly phished sites."
There's a long discussion to be had there, which starts with me
asking "Well, what's your threat model?" and would ideally follow
with "So, given this framework, what is your attack tree, and how
does SSP help thwart it?", but when I've tried to have that  
discussion

in the past it's not gone anywhere productive


Steve, were you not involved in the lengthy threat analysis  
discussions and production of RFC 4686?


The vast majority of that discusses threats against DKIM
in particular, primarily a rehash of the normal attacks
against PKI and DNS.

What I'm talking about is "the general threat that SSP is
intended to counter", which is a completely different,
and mostly unrelated thing (though I suspect that part
of the attack tree would involve the issues discussed
there). I've not seen that discussed in any clear, let
alone formal, manner, I don't think.

Cheers,
  Steve

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change

2007-12-06 Thread Arvel Hathcock


... but this working group has  people who are prepared to spend
a lot of time to shout down those they disagree with, leading to an
unproductive and unprofessional environment. I find the lack of
courtesy and professionalism here unpleasant enough that I tend
not to get involved much, even though I see very poor design
decisions being made.


I wish to sincerely apologize to everyone in this WG if I have 
contributed to an unprofessional/unproductive environment. Lately, I 
think a good argument could be made that I have.


Arvel


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change


Steve Atkins wrote:


Bill Oxley observed across threads "When it comes to discussing
SSP I hear a lot of noise with very little reason to implement or use
except in a few specific cases like highly phished sites."

There's a long discussion to be had there, which starts with me
asking "Well, what's your threat model?" and would ideally follow
with "So, given this framework, what is your attack tree, and how
does SSP help thwart it?", but when I've tried to have that discussion
in the past it's not gone anywhere productive


Steve, were you not involved in the lengthy threat analysis discussions 
and production of RFC 4686?


There are two sides to the coin here and it really serves no justice at 
to point to rehash it all, who's at fault, who's the bad guy, good guy, 
etc.


For the record, there has been many questionable decisions made and when 
they were highlighted, they were either pushed aside, ignored or 
shunned. So it is really an humorous irony to see whats going on now.


--
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

Re: [ietf-dkim] Tracing SSP's paradigm change

On Thursday 06 December 2007 13:11, Steve Atkins wrote:
> On Dec 6, 2007, at 9:58 AM, Scott Kitterman wrote:
> > On Thursday 06 December 2007 12:49, Steve Atkins wrote:
> >> In a well-designed protocol based on DKIM, yes I'd agree that a
> >> validly DKIM signed message should not provoke an SSP query.
> >>
> >> But that's not the protocol we have.
> >>
> >> I think RFC 5016 shows a lack of understanding of DKIM (or is
> >> choosing
> >> not to consider some important features of DKIM), and is
> >> part of the push to try and build a next generation SPF on
> >> an inappropriate base authentication technology.
> >
> > I think you aren't understanding the purpose of SSP at all.
> >
> > If any random signature from any domain obviates the SSP, what
> > possible use is
> > SSP?
>
> Bill Oxley observed across threads "When it comes to discussing
> SSP I hear a lot of noise with very little reason to implement or use
> except in a few specific cases like highly phished sites."
>
> There's a long discussion to be had there, which starts with me
> asking "Well, what's your threat model?" and would ideally follow
> with "So, given this framework, what is your attack tree, and how
> does SSP help thwart it?", but when I've tried to have that discussion
> in the past it's not gone anywhere productive

Personally, I think that exact question has been asked many times and answered 
with great specificity many times.  I agree that those who disliked SSP at 
the start of the working group still disagree on this.  

Personally, I think only the highly phished sites that really care about 
forgery will publish highly restrictive SSP records and so I think Bill and I 
actually agree.  

The choice in my mind is whether something like SSP is decided in secret among 
large highly phished senders and large receivers or if we are going to have a 
standardized approach that all can use IF they wish.  As has recently been 
said, no one is forcing anyone to use SSP.  Those who don't like it are 
perfectly free to ignore it.

What I see going on is a desire to change SSP into something completely 
useless, and then based on this change, declaring it useless.

Scott K
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change

2007-12-06 Thread Wietse Venema

Scott Kitterman:
> On Thursday 06 December 2007 12:49, Steve Atkins wrote:
> 
> > In a well-designed protocol based on DKIM, yes I'd agree that a
> > validly DKIM signed message should not provoke an SSP query.
> >
> > But that's not the protocol we have.
> >
> > I think RFC 5016 shows a lack of understanding of DKIM (or is choosing
> > not to consider some important features of DKIM), and is
> > part of the push to try and build a next generation SPF on
> > an inappropriate base authentication technology.
> >
> I think you aren't understanding the purpose of SSP at all.
> 
> If any random signature from any domain obviates the SSP, what possible use is
> SSP?

SSP is good for senders to announce what mail they sign. That's
the non-controversial part. 

Wietse
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change



On Dec 6, 2007, at 9:58 AM, Scott Kitterman wrote:


On Thursday 06 December 2007 12:49, Steve Atkins wrote:


In a well-designed protocol based on DKIM, yes I'd agree that a
validly DKIM signed message should not provoke an SSP query.

But that's not the protocol we have.

I think RFC 5016 shows a lack of understanding of DKIM (or is  
choosing

not to consider some important features of DKIM), and is
part of the push to try and build a next generation SPF on
an inappropriate base authentication technology.


I think you aren't understanding the purpose of SSP at all.

If any random signature from any domain obviates the SSP, what  
possible use is

SSP?


Bill Oxley observed across threads "When it comes to discussing
SSP I hear a lot of noise with very little reason to implement or use
except in a few specific cases like highly phished sites."

There's a long discussion to be had there, which starts with me
asking "Well, what's your threat model?" and would ideally follow
with "So, given this framework, what is your attack tree, and how
does SSP help thwart it?", but when I've tried to have that discussion
in the past it's not gone anywhere productive

Cheers,
  Steve

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change

On Thursday 06 December 2007 12:49, Steve Atkins wrote:

> In a well-designed protocol based on DKIM, yes I'd agree that a
> validly DKIM signed message should not provoke an SSP query.
>
> But that's not the protocol we have.
>
> I think RFC 5016 shows a lack of understanding of DKIM (or is choosing
> not to consider some important features of DKIM), and is
> part of the push to try and build a next generation SPF on
> an inappropriate base authentication technology.
>
I think you aren't understanding the purpose of SSP at all.

If any random signature from any domain obviates the SSP, what possible use is 
SSP?

Scott K
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

RE: [ietf-dkim] Signal to noise ratio

2007-12-06 Thread Bill.Oxley

 
When it comes to discussing SSP I hear a lot of noise with very little
reason to implement or use except in a few specific cases like highly
phished sites. My 2 cents
Thanks,

Bill Oxley
Messaging Engineer
Cox Communications

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Atkins
Sent: Thursday, December 06, 2007 12:17 PM
To: DKIM WG
Subject: Re: [ietf-dkim] Tracing SSP's paradigm change


On Dec 6, 2007, at 8:57 AM, Michael Thomas wrote:

> Dave Crocker wrote:
>> Michael Thomas wrote:
>>> And as far as I can tell, you alone seem to be carrying this torch
>>> here. Changing what we agreed on with rfc5016 should require a very
>>> high barrier. I see little if any support, let alone broad consensus
>>> that we got it wrong.
>
>   You still didn't respond: did you read 5016 before it was issued?
>   In fact I know that you did because you gave a lot of very detailed
>   feedback. And this was not one of the thing you commented on at the
>   time, so charges of "paradigm change" ring rather hollow.
>
>> So, you missed the postings by Levine and Atkins?  (Perhaps some  
>> others were on "my" side of this topic, but these two were at  
>> least quite explicit.
>
>   I didn't read them as supporting your reading. Let them speak for
>   themselves. There are a lot of things being discussed, after all.

I broadly agree with most of Dave's concerns...

>
>> I guess they don't know much about the topic or anti-abuse  
>> recipient operations behavior, so it's probably ok to keep this an  
>> individual ad hominem dismissal.
>
>   Saying that you need broad consensus to change the documented
>   consensus is hardly an ad hominem dismissal.
>
>> I've tried to recruit postings by some other anti-abuse folks who  
>> have expressed strongly negative opinions, but they have declined,  
>> indicating that they try to avoid being abused, and do not see any  
>> indication of interest in serious discussion about this in this  
>> group.
>>  From the style of quite a few postings on the list, can you blame  
>> them?
>
>   Ah, the silent majority. Still silent after all these years.

... but this working group has  people who are prepared to spend
a lot of time to shout down those they disagree with, leading to an
unproductive and unprofessional environment. I find the lack of
courtesy and professionalism here unpleasant enough that I tend
not to get involved much, even though I see very poor design
decisions being made.

It's unavoidable to some degree - any mention of "antispam" tends
to bring the noisy kooks out of the woodwork - but it's not going to
lead to a well-engineered, useful protocol.

Cheers,
   Steve

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Re: NEW ISSUE: suspicious terminology

2007-12-06 Thread Arvel Hathcock


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.


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

Arvel

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change

On Thursday 06 December 2007 12:17, Steve Atkins wrote:

> ... but this working group has  people who are prepared to spend
> a lot of time to shout down those they disagree with, leading to an
> unproductive and unprofessional environment. I find the lack of
> courtesy and professionalism here unpleasant enough that I tend
> not to get involved much, even though I see very poor design
> decisions being made.

I'm sympathetic to this perspective.  I think we have two broad groups here.  
One believes that SSP has utility and one believes that it doesn't.  Trying 
to produce a design by committee that attempts to split the difference is 
suboptimal.

Personally, I'm getting sick of the attacks on the concept and utility of SSP 
at this point in the game.  I really wish people would focus on making it as 
good as it can be and then we'll see what we end up with.  

I'm having a hard time not believing that some people are intentionally trying 
to undermine SSP development.  

I agree that some poor design decisions are getting made and have less 
interest than I used to in trying to invest my time in fixing it (and no, I'm 
not going to expend the time to go into details).

Scott K
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change



On Dec 6, 2007, at 9:29 AM, Michael Thomas wrote:


Steve Atkins wrote:

On Dec 6, 2007, at 8:57 AM, Michael Thomas wrote:

Dave Crocker wrote:

Michael Thomas wrote:

And as far as I can tell, you alone seem to be carrying this torch
here. Changing what we agreed on with rfc5016 should require a  
very
high barrier. I see little if any support, let alone broad  
consensus

that we got it wrong.


  You still didn't respond: did you read 5016 before it was issued?
  In fact I know that you did because you gave a lot of very  
detailed
  feedback. And this was not one of the thing you commented on at  
the

  time, so charges of "paradigm change" ring rather hollow.

So, you missed the postings by Levine and Atkins?  (Perhaps some  
others were on "my" side of this topic, but these two were at  
least quite explicit.


  I didn't read them as supporting your reading. Let them speak for
  themselves. There are a lot of things being discussed, after all.

I broadly agree with most of Dave's concerns...


Believe it or not, I agree with some of Dave's too. But that isn't
the issue at hand. The specific issue is whether *any* DKIM signature
from *any* domain should be sufficient to qualify for "strict" or  
"all".

Do you agree with that or not?



In a well-designed protocol based on DKIM, yes I'd agree that a
validly DKIM signed message should not provoke an SSP query.

But that's not the protocol we have.

I think RFC 5016 shows a lack of understanding of DKIM (or is choosing
not to consider some important features of DKIM), and is
part of the push to try and build a next generation SPF on
an inappropriate base authentication technology.

Cheers,
  Steve
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] -overview and -deployment html and pdf versions


now available at:

   

d/
--

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

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




Michael Thomas wrote:
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.



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
  Brandenburg InternetWorking
  bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change




Michael Thomas wrote:

I broadly agree with most of Dave's concerns...


Believe it or not, I agree with some of Dave's too. But that isn't
the issue at hand. 



It isn't?  You were asking a more narrow question?

And what if Steve's "broadly" happens to include the particular that you say 
this exchange involves?  Is there some reason you didn't seek to find that out?


d/
--

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

Re: [ietf-dkim] Tracing SSP's paradigm change


Steve Atkins wrote:


On Dec 6, 2007, at 8:57 AM, Michael Thomas wrote:


Dave Crocker wrote:

Michael Thomas wrote:

And as far as I can tell, you alone seem to be carrying this torch
here. Changing what we agreed on with rfc5016 should require a very
high barrier. I see little if any support, let alone broad consensus
that we got it wrong.


  You still didn't respond: did you read 5016 before it was issued?
  In fact I know that you did because you gave a lot of very detailed
  feedback. And this was not one of the thing you commented on at the
  time, so charges of "paradigm change" ring rather hollow.

So, you missed the postings by Levine and Atkins?  (Perhaps some 
others were on "my" side of this topic, but these two were at least 
quite explicit.


  I didn't read them as supporting your reading. Let them speak for
  themselves. There are a lot of things being discussed, after all.


I broadly agree with most of Dave's concerns...


Believe it or not, I agree with some of Dave's too. But that isn't
the issue at hand. The specific issue is whether *any* DKIM signature
from *any* domain should be sufficient to qualify for "strict" or "all".
Do you agree with that or not?

Mike
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change



On Dec 6, 2007, at 8:57 AM, Michael Thomas wrote:


Dave Crocker wrote:

Michael Thomas wrote:

And as far as I can tell, you alone seem to be carrying this torch
here. Changing what we agreed on with rfc5016 should require a very
high barrier. I see little if any support, let alone broad consensus
that we got it wrong.


  You still didn't respond: did you read 5016 before it was issued?
  In fact I know that you did because you gave a lot of very detailed
  feedback. And this was not one of the thing you commented on at the
  time, so charges of "paradigm change" ring rather hollow.

So, you missed the postings by Levine and Atkins?  (Perhaps some  
others were on "my" side of this topic, but these two were at  
least quite explicit.


  I didn't read them as supporting your reading. Let them speak for
  themselves. There are a lot of things being discussed, after all.


I broadly agree with most of Dave's concerns...



I guess they don't know much about the topic or anti-abuse  
recipient operations behavior, so it's probably ok to keep this an  
individual ad hominem dismissal.


  Saying that you need broad consensus to change the documented
  consensus is hardly an ad hominem dismissal.

I've tried to recruit postings by some other anti-abuse folks who  
have expressed strongly negative opinions, but they have declined,  
indicating that they try to avoid being abused, and do not see any  
indication of interest in serious discussion about this in this  
group.
 From the style of quite a few postings on the list, can you blame  
them?


  Ah, the silent majority. Still silent after all these years.


... but this working group has  people who are prepared to spend
a lot of time to shout down those they disagree with, leading to an
unproductive and unprofessional environment. I find the lack of
courtesy and professionalism here unpleasant enough that I tend
not to get involved much, even though I see very poor design
decisions being made.

It's unavoidable to some degree - any mention of "antispam" tends
to bring the noisy kooks out of the woodwork - but it's not going to
lead to a well-engineered, useful protocol.

Cheers,
  Steve

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] NEW ISSUE: suspicious terminology


John Levine wrote:
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."


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.


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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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


Dave Crocker wrote:

Michael Thomas wrote:

Dave Crocker wrote:

 Do envision a reasonable scenario where a receiver has adopted SSP and
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.


  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
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change


Dave Crocker wrote:



Michael Thomas wrote:

And as far as I can tell, you alone seem to be carrying this torch
here. Changing what we agreed on with rfc5016 should require a very
high barrier. I see little if any support, let alone broad consensus
that we got it wrong.




  You still didn't respond: did you read 5016 before it was issued?
  In fact I know that you did because you gave a lot of very detailed
  feedback. And this was not one of the thing you commented on at the
  time, so charges of "paradigm change" ring rather hollow.

So, you missed the postings by Levine and Atkins?  (Perhaps some others 
were on "my" side of this topic, but these two were at least quite 
explicit.


  I didn't read them as supporting your reading. Let them speak for
  themselves. There are a lot of things being discussed, after all.

I guess they don't know much about the topic or anti-abuse recipient 
operations behavior, so it's probably ok to keep this an individual ad 
hominem dismissal.


  Saying that you need broad consensus to change the documented
  consensus is hardly an ad hominem dismissal.

I've tried to recruit postings by some other anti-abuse folks who have 
expressed strongly negative opinions, but they have declined, indicating 
that they try to avoid being abused, and do not see any indication of 
interest in serious discussion about this in this group.


 From the style of quite a few postings on the list, can you blame them?


  Ah, the silent majority. Still silent after all these years.

Mike
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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




Michael Thomas wrote:

Dave Crocker wrote:

 Do envision a reasonable scenario where a receiver has adopted SSP and
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
  Brandenburg InternetWorking
  bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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


Dave Crocker wrote:

 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?


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

Re: [ietf-dkim] Tracing SSP's paradigm change




Michael Thomas wrote:

And as far as I can tell, you alone seem to be carrying this torch
here. Changing what we agreed on with rfc5016 should require a very
high barrier. I see little if any support, let alone broad consensus
that we got it wrong.



So, you missed the postings by Levine and Atkins?  (Perhaps some others were 
on "my" side of this topic, but these two were at least quite explicit.)


I guess they don't know much about the topic or anti-abuse recipient 
operations behavior, so it's probably ok to keep this an individual ad hominem 
dismissal.


I've tried to recruit postings by some other anti-abuse folks who have 
expressed strongly negative opinions, but they have declined, indicating that 
they try to avoid being abused, and do not see any indication of interest in 
serious discussion about this in this group.


From the style of quite a few postings on the list, can you blame them?

d/

--

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

[ietf-dkim] NEW ISSUE: suspicious terminology

2007-12-06 Thread John Levine

>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."

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 PROTECTED], Primary Perpetrator of "The Internet for 
Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change


Dave Crocker wrote:


The use of SSP for signed messages creates a series of functional 
interactions that SSP's use on unsigned messages does not.


Dave. Did you read rfc5016 before it was issued? It's not like this
was a closed opaque process.

And as far as I can tell, you alone seem to be carrying this torch
here. Changing what we agreed on with rfc5016 should require a very
high barrier. I see little if any support, let alone broad consensus
that we got it wrong.

Mike
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

2007-12-06 Thread Tony Finch

On Wed, 5 Dec 2007, Dave Crocker wrote:
>
> How would you describe what they do do?

Sendmail and (recent versions of) Postfix never add a Sender: field to the
header. Exim (by default) adds a Sender: field corresponding to the
authenticated sender if this is different from the From: field, which is
what 822 and 2822 and 4409 suggest. Traditional Unix MUAs don't bother
showing the Sender: field, but Microsoft Outlook is quite keen on it.
Therefore in our environment messages from role addresses tend to show up
in Outlook as "from person on behalf of role" which is annoying. I'm
inclined to give up on adding Sender: fields as specified and instead use
non-standard annotations in the Received: fields to record the
authenticated sender (as in this message).

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
FITZROY SOLE LUNDY FASTNET: WESTERLY 7 TO SEVERE GALE 9, PERHAPS STORM 10
LATER IN SOLE, LUNDY AND FASTNET. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. RAIN
THEN SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

On Thursday 06 December 2007 07:12, Charles Lindsey wrote:
> On Wed, 05 Dec 2007 14:18:09 -, Scott Kitterman
>
> <[EMAIL PROTECTED]> wrote:
> > On Wednesday 05 December 2007 08:53, John Levine wrote:
> >> >How would doing this work change what verifiers do after the RFC is
> >> > deployed?
> >>
> >> Probably not much, but it will help rein in unwarranted expectations
> >> by senders that publishing SSP will affect what happens to their mail.
>
> Exactly. Verifier implementors who do not read the document carefully
> enough (Shock! Horror! they wouldn't to that would they!) will see all
> those "Verifiers MUST" statements and deduce that they are obliged to
> follow them exactly. Which will discourage them from trying innovative and
> imaginative techniques which might, in the long term, lead to impprved
> filtering of 'suspicious' (or even 'not so suspicious') messages.
>
> And let me remind you that this thread started exactly because Dave
> Crocker (who maybe should know better) misread those "MUST"s in exactly
> that way. If even the people on this list can mis-read the draft, then
> that is a clear indication that its wording needs to be reviewed even
> though it does, when read carefully, say the right thing.

I agree that he chose to read them that way.

> > It sounds like a lot of work to say the same thing to me.  I don't think
> > increasing the quantity and type of ways that the draft says it doesn't
> > mandate what receivers will do is a value added use of anyone's time.
>
> Extra work that results in implementors making fewer mistakes is NEVER a
> waste of time.

Agreed, but I don't think that's the case here.

> FYI, here is the wording that I suggested again. It isn't necessarily a
> pure addition, since it might enable some other less obvious statements of
>
> the situation to be taken out:
> > "This document describes processes for what verifiers are expected to do
> > in order to achieve what the signers intend.
> >  But these descriptions are not Normative since there is no compulsion on
> > verifiers to follow those processes exactly as described, or even at all.
> > Therefore, use of the terms "MUST" and "SHOULD" in these descriptions
> > merely indicate the steps verifiers need to take if they want to claim
> > adherence to the particular set of processes described here."

I don't think that really changes much.  

-1

Scott K
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

2007-12-06 Thread Charles Lindsey

On Wed, 05 Dec 2007 14:18:09 -, Scott Kitterman
<[EMAIL PROTECTED]> wrote:

On Wednesday 05 December 2007 08:53, John Levine wrote:

>How would doing this work change what verifiers do after the RFC is
> deployed?

Probably not much, but it will help rein in unwarranted expectations
by senders that publishing SSP will affect what happens to their mail.

Exactly. Verifier implementors who do not read the document carefully
enough (Shock! Horror! they wouldn't to that would they!) will see all
those "Verifiers MUST" statements and deduce that they are obliged to
follow them exactly. Which will discourage them from trying innovative and
imaginative techniques which might, in the long term, lead to impprved
filtering of 'suspicious' (or even 'not so suspicious') messages.

And let me remind you that this thread started exactly because Dave
Crocker (who maybe should know better) misread those "MUST"s in exactly
that way. If even the people on this list can mis-read the draft, then
that is a clear indication that its wording needs to be reviewed even
though it does, when read carefully, say the right thing.

It sounds like a lot of work to say the same thing to me. I don't think
increasing the quantity and type of ways that the draft says it doesn't
mandate what receivers will do is a value added use of anyone's time.

Extra work that results in implementors making fewer mistakes is NEVER a
waste of time.

FYI, here is the wording that I suggested again. It isn't necessarily a
pure addition, since it might enable some other less obvious statements of
the situation to be taken out:

"This document describes processes for what verifiers are expected to do
in order to achieve what the signers intend.
But these descriptions are not Normative since there is no compulsion on
verifiers to follow those processes exactly as described, or even at all.
Therefore, use of the terms "MUST" and "SHOULD" in these descriptions
merely indicate the steps verifiers need to take if they want to claim
adherence to the particular set of processes described here."

--
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl

Email:[EMAIL PROTECTED]: 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

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