Subject: Re: The Value of Reputation (was Re: [ietf-dkim] Re: WG Review: Domain Keys Identified Mail (dkim))

From: Dave Crocker <[email-masked]>
Date: Sun, 01 Jan 2006 14:59:03 -0800

Folks,

Selamat tahun baru.

Unless I have missed something quite basic, the proposed DKIM charter and the
draft DKIM specifications do not include doing work on reputation services.
That many of us expect (and even intend) that one of DKIM's uses be in
reputation services does not mean that we must discuss that topic at any length,
in this venue, at this time.  In fact, reputation services are intentionally
factored out of the DKIM work, except for attending to exactly one question:

      DKIM provides a means of validating an identity that is associated with
message transit.  Do we believe that that validated identity will be helpful for
some variety of email [quality] mechanisms, such as reputation services?  The
answer to this is yes, since there is a long-standing value in having an
validated, accountable identity associated with a document.

Other discussion of reputation services strikes me as extremely important, but
entirely outside the scope of a DKIM working group.

I therefore will ask why folks feel it must be discussed in this venue, at this
time, rather than -- for example -- seeking to make forward progress on the DKIM
technical work?

>    I've noticed a lot of what I call "lip service" about the critical
> role of reputation. To say this differently, many folks seem to think
> you can choose a "reputation system" almost at random, and it's sure
> to improve your signal/noise ratio, "unless you've chosen the wrong one".
> (which, I suppose, is a tautology...)

"Many folk seem to think" is sufficiently broad and tenuous as to make its
validity and utility questionable.  For example, *I* have not seen any
significant basis for this concern among the folks who are trying to do the
actual DKIM technical work and deploy it in real-world operational environments.

As such, it is worth justifying this concern, before spending time addressing it.

>    But, in my view, we have no basis to choose the "right" one unless
> we have a good understanding of what it measures and a workable idea
> of how to "end run" when it falsely rejects good messages.

This sounds suspiciously like "We must understand the entire problem space and
the entire solution space, before we can permit ourselves to make choices about
pieces."

>> I see the cycle as going like this:  We need at least one
>> standardized, moderately-useful system for weakly authenticating
>> the sources of messages.  Once we have that, we have the minimal
>> data that a reputation system will require to be able to start
>> doing something at least mildly useful.
> 
>    A lot depends on what we mean by "weakly authenticating".

Probably correct.  So it is quite useful that we have access to a concrete
specification that embodies the meaning that applies here.

We do not have to guess and we do not have to compare it to other uses of the term.

>    As a practical matter, _many_ folks will prefer sorting through
> 100 spams to losing one good email. I see darn little "market" for
> anything which can't get it 99% right. 

"Many folks" are free to use whatever mechanisms they find helpful.  The point
behind DKIM is that "many folks" believe it to be worth pursuing.

As for judging exactly what the limits of market acceptability are, there are
two problems with attempting to conduct such a discussion here:

    a) standards bodies, including the IETF, have very poor track-records
predicting market acceptability, particularly when the discussion goes beyond
merely assessing the competence of the technology.

    b) there is a substantial constituency of experienced and responsible
development and operations folk who find the DKIM mechanism appealing enough to
be worth pursuing.

   - - - - -

> Global reputation vetting is a hard problem.  To a considerable
> extent, that makes a strong argument for local reputation
> assessment, not for identifying those who cannot be
> reputation-validated as spammers but for giving preferred
> treatment to those who are on some preferred list.  As I
> understand it, that is a major motivation of at least several of
> those who are pushing DKIM.  So far so good.

I believe that local-vs-global is largely orthogonal to the question of whether
to focus on identifying the good actors, versus focusing on identifying the bad
actors.

> The difficulty is that establishment of such a mechanism makes
> it very easy for, e.g., an ISP that wants to "protect its
> customers from spam" and reduce spam traffic on its backbone to
> say "aha, any message that isn't validated/authorized by someone
> whom we recognize is obviously hostile and should be silently

It is often easy for people to make simplistic and incorrect choices in how they
use a mechanism. This does not seem like a very strong argument against creating
the mechanism.

The general form of the concern that appears to be getting expressed here is "an
otherwise-reasonable and useful mechanism is easy to misuse, therefore we need
to consider avoiding making it available (or we need to spend a lot of effort
warning people against their silliness and stupidity.)

In this form, of course, the concern does not seem so reasonable.

(Another example of such logic is:  "Pornographic pictures are evil, so we must
not make it easy to attach them to email, so let's not create MIME.")

>    But, in practice, we know that those marketplace
> mechanisms often don't work terribly well.

Except for the fact that they work far better at choosing standards than any of
the alternatives...

> Now using DKIM, or a wide variety of other techniques, this way,
> would clearly be abuse of the intent of the methods.  But one of
> the things we all should have learned by now is that a
> technology that can be abused almost certainly will be abused.

We've learned much more than that.  We have learned that there is an infinite
range of abuses possible (and usually likely.)  We have learned that we are not
very good at protecting people against their own silliness and stupidity.  We
have learned that we are not very good at predicting which abuses people will
prefer.  And so on...

Therefore we SHOULD have learned that our obligation is to write clear
specifications for understandable mechanisms that do useful things.

*That* focus, rather than one that worriess about myriad psychosocial
hypotheticals, has proved far more constructive for IETF work.

> It seems to me that, were DKIM to succeed, we would run a
> significant risk of seeing the Internet fragmented into
> DKIM-approval camps (with the non-DKIM-users left out of all of
> them).

1. You might be right, but I can't tell, because I do not see a) the logic
sequence that starts with the fear you express and leads clearly to the
conclusion, and b) the basis for certitude that the fragmentation will occur.

2. How is this different from the "fragmentation" that separates those with MIME
support from those without, or the "fragmentation" that separates those with TCP
selective acknowledgment support, from those without, or... any other
fragmentation that distinguishes among supporters of enhancements from those not
(yet) supporting it?

> Again, this is not an argument against chartering a WG.  It
> might be an argument for insisting that such a WG explain, as
> part of proposing something for standardization, how obvious
> abuses of it are to be avoided or repelled.

My "obvious" is probably not your "obvious".  This will lead to lots of extra
work, debating what is "obvious".

This seems to suggest a policy requirement for all IETF work, that it anticipate
and document "obvious" abuses and specify the means of avoiding them.

This feels more like a bureaucratic barrier to productive work, than a useful
adjunct to the technical specifications work that the IETF tries to perform.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Douglas Otis <[email-masked]>
Date: Mon, 02 Jan 2006 17:39:39 -0800

> validated, accountable identity associated with a document.

This statement of obtaining a valid accountable identity only applies to
the base DKIM draft, but does not extend to the SSP draft.  

> specification that embodies the meaning that applies here.

With respect to chartering and the WG output expectations...

The base DKIM draft depends upon a domain offering a public key used to
validate the signature. (Good) 

On the other hand, the SSP draft offers an authorization for an email-
address within the From header. (Bad)  This authorization has already
been construed in the SSP draft itself as providing accountability.
This identity defines where complaints are to be registered.   This SSP
draft also greatly alters email use by not permitting normal practices
without the same dangerous open-ended policies as seen with SPF. (Very
bad.)

> development and operations folk who find the DKIM mechanism appealing enough to

The base DKIM draft does not depend upon the SSP draft.  There are
other means to establish the expectation of there being a signature
present without changing accountability (burden-shifting).  This other
means better protects recipients from fraud as well.  This other means
requires less overhead.  SSP can not be justified. 

> use a mechanism. This does not seem like a very strong argument against creating

There is already mechanisms in place ready to misuse email-address
authorization -as-if- authenticated.  There should be an expectation
based on previous experiences that such an authorization scheme can
become a form of coercion when treated as a source identifier.  This
does not require guess work.

> conclusion, and b) the basis for certitude that the fragmentation will occur.

By shifting the burdens imposed by reputation block-lists onto the
email-address domain owner, controlling abuse would then rests upon a
hapless entity.  The ability to obtain a domain name and safely share
services are placed in peril.  The fragmentation (as coercion) will
likely occur when larger domains find the results of this burden-
shifting being in their interest.  

> fragmentation that distinguishes among supporters of enhancements from those not

At least with MIME, the risk was not with respect to unfairly being held
accountable.  

-Doug

---

From: Mike Wolf <[email-masked]>
Date: Mon, 2 Jan 2006 21:25:41 -0500

I would be very interested in participating in a new working group or
mailing list that concentrates on reputation services that can build on the
excellent work done so far in the DKIM group.  I am also involved in another
standards effort amongst the posts of the world called the Electronic
Postmark and could see the local post office in each country potentially
playing a positive role as a reputation / accreditation service that has
some real legal teeth if we can bring these groups together.

How do we start a new WG or list that focuses on reputation?

Mike Wolf
PeerConnect, Inc.

On 1/2/06, Barry Leiba <[email-masked]> wrote:
>
> > Selamat tahun baru.
>
> Bonne année to you too.
>
> I agree with Dave sometimes, and disagree sometimes.  For this note,
> I agree with everything he says.  I have a few things to add (though
> as I went through it trying to add more, I realized how unnecessary
> that was).
>
> > Unless I have missed something quite basic, the proposed DKIM charter
> > and the draft DKIM specifications do not include doing work on
> reputation
> > services.
>
> Just to add one to this:
> Yes, that is correct.  And if the WG be chartered and if I be a co-chair,
> I will certainly declare any discussion of it to be out of scope.  That
> doesn't mean it can't come up here and there, as part of other
> discussions,
> but we must not focus on it, taking time from the work to hand.
>
> I, as do others, believe that some sort (or sorts) of reputation service
> will be important, and should be developed.  I see several ways to
> approach it:
> 1. Recharter this WG after its primary work is done.
> 2. Start one or more new WGs for this, beginning the chartering process
> as the DKIM work nears completion.
> 3. Work on some reputation services separately -- as I believe will happen
> in any case -- and bring some of them to the IETF after some
> experimentation.
>
> I think (1) is probably NOT the right way, but both (2) and (3) will work
> well.
>
> >> to improve your signal/noise ratio
>
> I don't think "many" people seriously think that, and hyperbole isn't
> useful
> here.  Most participants here (and I base this on what people have said)
> think
> a *well designed* system will be very useful.  That's why we should wait
> until
> we've finished some of the other discussions that pend here, so that we
> may
> take the time to design the reputation system(s) well.
>
> Actually, I have a good bit to say about this particular item in a paper
> I'm writing for CEAS [and so here's a shameless plug for CEAS, the
> Conference
> on Email and AntiSpam, and an urging to all to consider writing papers for
> it: http://ceas.cc, and click on "2006 Call for Papers"].  The bottom line
> is that the answer varies, and whatever infrastructure we have has to have
> the flexibility to support the varying needs of different customers and
> groups.
>
> > This seems to suggest a policy requirement for all IETF work, that it
> > anticipate and document "obvious" abuses and specify the means of
> > avoiding them.
> >
> > This feels more like a bureaucratic barrier to productive work, than a
> > useful adjunct to the technical specifications work that the IETF tries
> > to perform.
>
> The suggestion seems so "obviously" reasonable that it's hard to imagine
> why we shouldn't do it.  And yet, as Dave points out, it could just pull
> the reins tight on all IETF work.
>
> Our focus has to be on making sure the specifications are clear.  We can
> (and we do) talk about some things we do NOT support and that you should
> NOT do... but, "obviously", we can't possibly cover all the "don't"s, and
> attempts to will fail, and will bring the process down with them.
>
> Barry
>
> --
> Barry Leiba, Pervasive Computing Technology  ([email-masked])
> http://www.research.ibm.com/people/l/leiba
> http://www.research.ibm.com/spam

---

From: John Levine <[email-masked]>
Date: 3 Jan 2006 02:52:56 -0000

>mailing list that concentrates on reputation services that can build
>on the excellent work done so far in the DKIM group.

Oh, good.  The IAR subgroup in the ASRG has been languishing for ages
waiting for people to pick up on the reputation question.  It belongs
in the ASRG rather than an IETF group because, unless I've missed some
recent developments, we have only the vaguest idea what a reputation
system would actually do.

The technical details of publishing domain reputation data are pretty
simple.  You could do it through DNS, e.g., if you want to look up
dubious.com in a reputation system called reputationservice.org, you'd
do a DNS query on dubious.com.reputationservice.org, and it'd return,
well, something, a numeric rating as an A record or a description as a
TXT record perhaps.  Or if you want to query with HTTP, it's just as
easy, fetch http://reputationsystem.org/dubious.com and the server
hands you back a MIME-wrapped block of something.

It's figuring out what the something is that's hard, and that's what
we've got to work on.  See http://asrg.sp.am/subgroups/iar.shtml

R's,
John

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 03 Jan 2006 08:16:15 +0100

Douglas Otis wrote:

> dangerous open-ended policies as seen with SPF. (Very bad.)

Define "open-ended":  I've no idea what you're talking about,
or rather if it's NEUTRAL you're wrong.  And for your favourite
"pure DKIM" I'd like to know what it's good for:

As an example, what exactly could say Ironport do with it ?
Organize senderbase more efficiently, would that be all, or
what else is the purpose of your "pure DKIM" ?

This "pure DKIM" needs some convincing reasons why senders
and receivers should bother to implement it, "helps to create
white lists" isn't good enough from my POV, but probably I
just miss some of your points.
                               Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 3 Jan 2006 11:25:49 -0800

On Jan 2, 2006, at 11:16 PM, Frank Ellermann wrote:

> Define "open-ended":

A set needs a definition for grouping.  In email, the obvious  
distinction for this grouping would be acceptance versus rejection,  
based upon an identifier being found in a set.  For SPF this would be  
an IP address list, and for SSP this would be signatures.  When  
acceptance requires the identifier be contained within the set, this  
could be described as Closed.  When acceptance does not require the  
identifier be contained within a set, this could be described as  
Open.  For example, depending upon the qualifiers, the empty set  
could be either Open or Closed.

For SPF the qualifiers are:
  "+" Pass  (Open)
  "-" Fail  (Closed)
  "~" SoftFail (Open)
  "?" Neutral (Open)

For SSP the qualifiers are:
  "~"  Signs some (Open)
  "-"  All signed & allow other signatures. (Open)
  "!"  All signed. (Closed)
  "."  Never sends mail. (Closed)
  "^"  Check User specific policy (deferred)

> I've no idea what you're talking about, or rather if it's NEUTRAL  
> you're wrong.

When an email-address domain owner is held accountable for abuse  
permitted by their "authorization" record, then whatever that is  
allowed as a result would impact upon their reputation.  When  
subsequently having their messages blocked by a faction of receiving  
MTAs, recovery would be difficult.  Those wishing to avoid such  
problems (coerced) would then be required to implement a "Closed"  
acceptance set.  Those authorizations defined here as "Open" expose  
the email-address domain owner to substantial risk of being unfairly  
held accountable, even though "Open" allows normal email practices.

Indications being displayed to the recipient that highlight messages  
found within a set of identifiers will likely mislead the majority of  
recipients.  Any "within the set of identifiers" indication would  
likely increase a success rate of fraud.  Bad actors can achieve this  
requirement the same as the good actors.  It would be very dangerous  
to expect the recipient would be able to recognize good actors from  
the bad based upon what is displayed by the MUA.

> And for your favourite "pure DKIM" I'd like to know what it's good  
> for:

The base DKIM draft offers a more stable identification of email  
sources, as opposed to the client IP addresses.  In the case of  
"phishing" attacks, only a minority of recipients even see the email- 
address, but instead see the "display-name".  To effectively abate  
these exploits, the content of the message must be examined for  
deceptive links and information that purport to be from a "phished"  
site.  Having a stable identifier upon which to compare valid  
messages from those that are invalid, these fraudulent messages can  
be blocked which a much lower false positive rate.  This effort must  
_not_ depend upon the From email address.  Making the From email- 
email address restriction disrupts how email is normally used, but  
relying upon the more stable DKIM source identifier does not create  
this disruption.

MUA can also make good use of a stable DKIM source identifier to  
recognize prior correspondents.  Highlighting those source  
identifiers as belonging to a prior correspondent would be a safe  
indication shown to the recipient, and would not depend upon their  
ability to recognize or even see the email-address.

> As an example, what exactly could say Ironport do with it?

If "binding advise" were added to the signature as described within  
the dkim-options draft, then a binding that assures the entire domain  
is always signed would allow refusal of non-signed messages.  This  
would not require looking up label trees of each email-address  
received, where the vast majority of the DNS lookups would not be  
cached.  This would require the repetition of several DNS lookups for  
each message.  The "binding" strategy avoids this overhead and avoids  
the misused "authorization" record.

> Organize senderbase more efficiently, would that be all, or what  
> else is the purpose of your "pure DKIM"?

Adding the Opaque-Identifier to the signature would also permit the  
detection of inter-domain spoofing without any email-address  
constraints being made by the MSA.  The Opaque-Identifier also offers  
a means to deal with abusive message replays.  This would not be  
"pure" DKIM perhaps, but it would not be an email-address  
authorization scheme either.  SSP is Sender-ID in a different suit.

> This "pure DKIM" needs some convincing reasons why senders and  
> receivers should bother to implement it, "helps to create white  
> lists" isn't good enough from my POV, but probably I just miss some  
> of your points.

Once MUAs offer the ability to recognize prior correspondents,  
especially those considered critical to the recipient, then not  
having just the base DKIM implemented would be a major short-coming  
in the eye's of most consumers that desire "safe" assurances.  SSP  
can never ever offer a safe assurance.   With DKIM used in  
conjunction with the MUA at the request of the recipient, there would  
be a _safe_ means to abate much of the fraud that seem all too  
rampant.  SSP can _not_ play a safe role in this endeavour however.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Jan 2006 19:39:40 +0000

Athbhlian faoi mhaise. (Bit late but whatever...:-)

>>> dangerous open-ended policies as seen with SPF. (Very bad.)

Aaaaargh! Please don't!

Why not read and comment on the threats draft instead? You'll feel
much better, really.

Stephen.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 03 Jan 2006 13:46:14 -0800

John Leslie wrote:

>Nathaniel Borenstein <[email-masked]> wrote:
>  
>
>>On Dec 24, 2005, at 4:09 PM, Douglas Otis wrote:
>>
>>    
>>
>>>Reputation remains the only solution able to abate the bulk of abuse.
>>>      
>>>
>>... I think most of us pretty much agree about the critical role of
>>reputation.
>>    
>>
>
I completely agree that reputation has a critical role (although
accreditation is important in many situations, as Phill has pointed out,
and should not be ignored).  However, I have come to believe that there
is a great deal of subtlety below the surface of any good reputation system:

- Preventing abusers from "gaming the system" to get good scores
- Preventing attackers from damaging the reputations of others
- Defending the reputation system against legal actions from those who
feel they have been hurt
- Making it all work within the law, considering privacy laws, restraint
of trade, and so forth, considering that the laws governing this vary by
jurisdiction

For this reason, I don't think the operation of reputation systems
themselves should be defined by IETF; different users will have
different needs.  However, standard protocols for communicating with
reputation systems will be needed, and this is a very important area for
IETF to address.  Transaction rates for lookups will be high, and
careful protocol design is needed.  The use of standard protocols in
this area will allow clients to pick a suitable reputation service, and
to change services without changing their infrastructure.  Both
reporting and query protocols will need to be defined.

Much of this applies to accreditation services as well, although there
are some different requirements (negotiating an accreditor to use
between sender and recipient/verifier, for example).

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 3 Jan 2006 15:34:32 -0800

>>>> dangerous open-ended policies as seen with SPF. (Very bad.)

This was related to comments suggesting removal of SSP draft from the  
charter.  What problem is created in providing a definition of  
terminology?

> Why not read and comment on the threats draft instead? You'll feel  

I _did_ respond to the threat draft, but neither reading the threat  
draft, nor the lack of response by _anyone_ else to this draft does  
not raise a level of comfort.  Please note the question raised with  
respect to section 3.2.2. "Identity-Related Fraud" has remained  
unanswered.

http://mipassoc.org/pipermail/ietf-dkim/2005q4/001571.html

SSP was introduced rather than produced out of open discussions.  SSP  
goes well beyond establishing the base DKIM draft.  The next steps  
should be to decide how DKIM can best be applied.  SSP presupposes an  
email-address authorization scheme is needed, beneficial, and safe to  
either assert or display.  As there has not been much consideration  
given for the secondary effects or the reconsideration of blatant  
assumptions, the statements in a threat review seem to have been made  
without any desire to defend the justifications used for the SSP  
mechanism.  At least Frank is willing to discuss these related issues.

There are at least two factors at play that may be hindering this  
process.  There is almost a rote method for dealing with email abuse  
which discerns tell-tale characteristics of abusive messages not  
prevented by a block-list.  There is also the security community with  
an almost a rote method of combining identifiers with polices.  When  
a hammer is your only tool, everything looks like a nail.  The  
imagined solution is the application of an anonymous sender's policy  
applied to _some_ email-address found within the message.  This  
overlooks a few serious problems.  The anonymous sender can be a bad  
actor making their own policy.  The good actors will find themselves  
constrained by the complexity created by restrictive policies for an  
email-addresses that lead to open-ended policies.

The bulk of abuse will be abated through the application of  
reputation in various forms.  The identifiers used in this process  
must be relatively strong to ensure a fair system.  The authorization  
strategy invites the use of an extremely weak identifier (perhaps  
seen as a tell-tale sign).  There are no safe assurances possible as  
a result of the application of the SSP policy. : (

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 03 Jan 2006 22:42:01 -0800

> http://mipassoc.org/pipermail/ietf-dkim/2005q4/001571.html

Thanks for your comments, Doug; I too wish there had been more
discussion at this point, but the chartering discussion took
precedence.  I haven't responded yet (owing primarily to the holidays),
but plan to do so very soon.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Jan 2006 15:47:51 +0000

Hi Doug,

> charter.  What problem is created in providing a definition of

Ok then: define "define", but just not here:-)

Seriously, there will be a time when the group should be focusing on
the policy stuff, but its just not yet. For now we ought be focusing
on the threats draft.

You also ought accept that making the same "not ssp" point in a million
ways doesn't make it a new point. We all know that you don't like
ssp. There's no need to tell us again. I say this on the basis that
the charter text that Russ has now, is what'll get approved or not.
I just don't see it changing again in the way you'd like.

But, when its time to focus on what to do about policy (largely
after last call on the base draft), then many of the points you
raise will be on-topic and won't be distracting the group from
its main goal.

> I _did_ respond to the threat draft, 

I realise and appreciate that. The comment was more directed to the
rest of the folks discussing this with you over and over.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 4 Jan 2006 09:11:46 -0800

On Jan 4, 2006, at 7:47 AM, Stephen Farrell wrote:

> Seriously, there will be a time when the group should be focusing  
> on the policy stuff, but its just not yet. For now we ought be  
> focusing on the threats draft.

There are a fair number of claims being made in the threat draft  
regarding SSP that are not justified.  These issues have been largely  
ignored.  There have been concerns raised regarding the secondary  
effects of the authorization scheme that also have bee largely ignored.

> You also ought accept that making the same "not ssp" point in a  
> million ways doesn't make it a new point.

Much of the threat review is premised upon assumptions of protections  
offered by the SSP mechanism.  What concern do you have regarding the  
unfair treatment and disruptions the SSP mechanism permits.  When  
someone attempts to discuss the merits of these concerns, why  
introduce malarkey about everyone already knowing.  What points are  
you willing to concede?  What points are not correct in your view?

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 04 Jan 2006 18:13:26 +0100

Stephen Farrell wrote:

> there will be a time when the group should be focusing on
> the policy stuff, but its just not yet. For now we ought be

s/now/tomorrow/ after the WG is chartered... ;-)  I think I've
now got Doug's terminology of "closed" vs. "open", it 's like
"open interval" vs. "closed interval" for real numbers.

In that case it's wrong / esoteric / dubious (pick what you
like) for sets of IPs, because there's only a finite number of
IPs.  We don't need "open intervals" or the "axiom of choice"
to construct say three sets FAIL, PASS, and DUNNO covering all
IPs, with each IP in precisely one of these three sets.

> You also ought accept that making the same "not ssp" point
> in a million ways doesn't make it a new point.  We all know
> that you don't like ssp.  There's no need to tell us again.

Yes, but he might be up to something real.  Keith _also_ said
that we might need a new "opaque-id".  William specified a new
"submitter" for spf2.0/submit, compatible with the "submitter"
in the [draft-katz-submitter] RfC, but completely independent
of PRA.

Maybe they (Doug / Keith / William) see something that we still
fail to see.  That I fail to see it is no big surprise, because
I think that the Return-Path should do the trick.  But that
does not help for DKIM + SSP, DKIM cannot use the Return-Path.

This "opaque-id" could be a new general concept, some kind of
an improved crypto-PRA-cum-Message-ID, with DKIM as its first
serious application.

Well, I see where this might be "off topic" starting tomorrow.
But if they (Doug / Keith / William) are right I seriously
hope that it's ready before the future DKIM WG tries to tackle
SSP.  And I hope that Keith will be the editor of this obscure
beast, because so far I always understood what he talks about,
while Doug often and William sometimes are beyond me.

> The comment was more directed to the rest of the folks
> discussing this with you over and over.

If what he says about SPF is wrong / dubious I've to challenge
it, and I also don't see any "open-endedness" in SSP so far:

Every domain is free to send no mail, and to publish this as
"v=spf1 -all" or nullmx or what else.  It's also free to say
that it only uses certain routes, or always uses some kind of
signature, etc., and to publish this decision in a policy.

If that hurts users they can vote with their feet.  Bye, Frank

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Jan 2006 17:43:54 +0000

This is not a thread about ssp. Its about staying on topic.

Douglas Otis wrote:
> regarding SSP that are not justified.  

And where that's the case, then we do have to address it. I guess
the best bet is to let Jim respond to your comments, which he's said
he'll do.

 > These issues have been largely

To the extent that that gives rise to specific issues with the threats
draft, its on-topic. Much of the discussion is premature though since
we (hopefully) will be chartered to address policy issues later this
year.

(*) But I have to admit I suspect you of continually trying to drag all
conversations back to your main point, and am therefore very reluctant
to engage on generic statements like your last sentence above.

>> million ways doesn't make it a new point.
->
> offered by the SSP mechanism.  

I expect that that'd be disputed and think "much" is overstated at
least.

 > What concern do you have regarding the
> unfair treatment and disruptions the SSP mechanism permits.  

Neat trick. I nearly fell for it:-)

I have no concerns about ssp that I'd state more than 100 times.

The point is that you should recognise that you've not convinced people
of your main point and therefore you really ought to stick to specific
issues where you may or may not convince us. The war is lost, but you
might win a battle or two as we go on.

 > When
> someone attempts to discuss the merits of these concerns, why  introduce 
> malarkey about everyone already knowing.  

"malarkey?" Sheesh!

I doubt a review of postings to this list would single me out that
way. And if you believe that people paying attention to this list
are enlightened by repetition then I suspect you're mistaken. My
guess is that they'll stop reading your posts, never mind spend
time considering what you're trying to say.

 > What points are  you willing
> to concede?  What points are not correct in your view?

See (*) above.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 4 Jan 2006 11:20:40 -0800

On Jan 4, 2006, at 9:13 AM, Frank Ellermann wrote:

> Stephen Farrell wrote:
>
>> there will be a time when the group should be focusing on the  
>> policy stuff, but its just not yet. For now we ought be focusing  
>> on the threats draft.
>
> s/now/tomorrow/ after the WG is chartered... ;-)  I think I've now  
> got Doug's terminology of "closed" vs. "open", it 's like "open  
> interval" vs. "closed interval" for real numbers.
>
> In that case it's wrong / esoteric / dubious (pick what you like)  
> for sets of IPs, because there's only a finite number of IPs.  We  
> don't need "open intervals" or the "axiom of choice" to construct  
> say three sets FAIL, PASS, and DUNNO covering all IPs, with each IP  
> in precisely one of these three sets.

How does a limit in the number of IP address effect this definition?   
While many wish to weigh acceptance criteria to divide results into  
multiple groups, the concern was regarding what is being permitted in  
terms of acceptance.  This acceptance may be judged harshly in binary  
terms.  Either the authorization blocks abuse or it doesn't.  With  
respect to the terminology, _any_ qualifier that was labeled as  
"Open" permits acceptance of abuse.

>
>> The comment was more directed to the rest of the folks discussing  
>> this with you over and over.
>
> If what he says about SPF is wrong / dubious I've to challenge it,  
> and I also don't see any "open-endedness" in SSP so far:

SPF and SSP will have similar problems.  With SPF, you have pointed  
out the RFC1123 5.3.6(a) issue that may cause those concerned with  
the resulting disappearance of messages to use the '?' qualifier,  
which is fairly common.  With SSP, the disruption in delivery of  
messages is even more pronounced.  Even posting messages to this list  
will be lost when a 'Closed' qualifier is used.  DKIM can not hope to  
dictate how identifiers are used by the receiving MTA administrator  
as they struggle to find the means to exclude spam.  Care must be  
taken to avoid the obvious unintended uses of authorization.  With  
the exception of a "Closed" qualifier, all the other qualifiers are  
largely meaningless and perhaps greatly misleading.  Any indication  
of even being within a "Closed" set of identifiers is also likely  
misleading.

> "v=spf1 -all" or nullmx or what else.  It's also free to say that  
> it only uses certain routes, or always uses some kind of signature,  
> etc., and to publish this decision in a policy.

There have already been cases where a major ISP use coercion by  
deleting _some_ messages without _some_ type of authorization.  Even  
from other providers with otherwise good reputations.  This freedom  
is somewhat illusory when a sender must worry about whether messages  
are accepted, or simply vanish because DSN are also contingent upon  
the authorization.  : (

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 4 Jan 2006 15:02:07 -0500

On 01/04/2006 14:20, Douglas Otis wrote:

I really hate it that we are debating SPF on the DKIM list, but it seems 
unavoidable...

> which is fairly common.  

This is completely contrary to my experience.  Because I use shared MTAs, 
almost all e-mails I send have an SPF NEUTRAL (?) result.  In about a year 
and a half of doing this, I've had exactly 3 e-mail messages rejected (not 
disappeared by the way) and they were all the result of configuration errors 
on the distant end (2 of the 3 thanked me for pointing out their error).  As 
far as I know, I've had NONE disappear.

So, even if you start out with the premise the SSP is like SPF (I don't think 
that's right either), nothing that follows in the original e-mail is correct.

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 04 Jan 2006 20:14:51 +0000

Douglas Otis wrote:
> 
> On Jan 4, 2006, at 9:43 AM, Stephen Farrell wrote:
> 
>>> What concern do you have regarding the unfair treatment and  
>>> disruptions the SSP mechanism permits.
>>
> You have no concerns?  

Please turn off your rhetoric generator. Its a bit stuck:-)

 > Can you provide a generalization of the  concern
> that you have?

I could. Though I wouldn't make a generic comment if I could
make a much more easily understood specific remark. But just
because I could type something doesn't make it useful to do
so now. So I won't.

>> ...And if you believe that people paying attention to this list  are 
>> enlightened by repetition then I suspect you're mistaken. My  guess is 
>> that they'll stop reading your posts, never mind spend  time 
>> considering what you're trying to say.
> 
> A lack of activity on the list suggests many things.  

Your response is irrelevant to the statement above. But I still hope
you got the message. I guess we'll see.

> Generalizations  
[...deleted - please do read the subject...]

Stephen.

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 04 Jan 2006 12:40:35 -0800

(Reducing distribution to just ietf-dkim)

On 2006-01-03 13:46, Jim Fenton wrote:

> different needs.

Trying to define what is intrinsically a social policy using purely 
technological means pretty much always fails -- and generates a lot of 
pointless arguments along the way.

Nobody with any real-world mail operations experience wants a 
not-yet-chartered working group to tell them how or when to apply 
reputation, so any attempt to do so will fail miserably.  But, that 
failure doesn't need to drag DKIM down with it.

Can we just agree that DKIM may be used as an input to site-specific 
reputation systems and MOVE ON already?

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Douglas Otis <[email-masked]>
Date: Wed, 4 Jan 2006 11:53:39 -0800

> I have no concerns about ssp that I'd state more than 100 times.

You have no concerns?  Can you provide a generalization of the  
concern that you have?

>
>> When someone attempts to discuss the merits of these concerns, why  
>> introduce malarkey about everyone already knowing.
>
> "malarkey?" Sheesh!

Perhaps "malarkey" was not being culturally sensitive.  I was not  
attempting to be condescending; just the opposite.  My apologies. : )

> time considering what you're trying to say.

A lack of activity on the list suggests many things.  Generalizations  
have the effect of not delving into merits.  Before proceeding head  
long, it would be good to have these issues clearly illuminated.   
There seems to be a general assumption that authorization offers a  
means of protection.  There also seems to be a general assumption  
that employing the policy of the sender is appropriate.  There also  
seems to be a general assumption that "open-ended" authorizations are  
"okay".  There also seems to be a general assumption the email-domain  
owner can be held accountable.  Perhaps it would be good to highlight  
the assumptions used to arrive at these conclusions.

There is an alternative means to ensure better protection against  
fraud that is controlled by the recipient.  There is also a means to  
establish expectations for the presence of signatures without  
authorizations.  The alternatives avoid the disruptions an  
authorization scheme may impose.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 4 Jan 2006 13:59:21 -0800

On Jan 4, 2006, at 12:02 PM, Scott Kitterman wrote:
>> SPF and SSP will have similar problems.  With SPF, you have  
>> pointed out the RFC1123 5.3.6(a) issue that may cause those  
>> concerned with the resulting disappearance of messages to use the  
>> '?' qualifier, which is fairly common.
>
> This is completely contrary to my experience.  Because I use shared  
> MTAs, almost all e-mails I send have an SPF NEUTRAL (?) result.

This is agreeing open-ended authorizations are not uncommon?  SSP  
also relies upon this open-ended method for similar reasons.   For as  
long as a domain has not become the target of abuse, why would there  
be a problem?  When used as an identifier, as purported by Sender-ID  
for example, protection of one's email-address domain's reputation  
relies more upon luck and not design.  Moving closer to using  
"closed" authorizations will likely also require adoption of the PRA  
header selection algorithm or waiting for some rather major changes  
to occur. : (

> So, even if you start out with the premise the SSP is like SPF (I  
> don't think that's right either), nothing that follows in the  
> original e-mail is correct.

Are you suggesting the email-address domain owner providing the  
authorization will never be held accountable for the type of  
authorization they use?  It is not surprising to see a strong desire  
by providers to shift the burden of reputation onto the email-address  
domain owner, but this is not fair for many reasons.

What protection does an "open-ended" authorization provide the  
recipient?  How could this be considered safe?  Even assuming a  
"Closed" authorization were used, this also relies upon the visual  
examination of the email-address, which is often not shown to the  
recipient.  Is there an assumption that the MUA must be altered to  
take advantage of the DKIM signature?  If that is the case, why not  
use recognition rather than authorizations, as this offers far  
greater safety.

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 5 Jan 2006 07:39:46 -0500

I think we've wandered pretty far afield here and I'm not going to follow.  
Don't take my lack of response for agreement.

Scott K