Subject: RE: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 27 Oct 2004 08:04:23 -0700

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Matthew Elvey

> Generally applicable comments on 3929:
> 1)This scheme would put excessive power in the hands of the few: the 
> Chairs, who are appointed (indirectly) by the elite few who can pay 
> non-trivial sums of money to attend lots of IETF meetings, such sums 
> generally provided by large corporations with entrenched 
> interests. 

I don't think that you really identify the problem here. I think that
you certainly have a point on the cost issue. Even though IETF does not
have a membership cost like OASIS or W3C the cost of attending meetings
is a significant barrier.

But I don't think that the right to participate in NOMCON is that 
significant. NOMCON is deliberately constructed in a way that makes
the return of incumbents all but inevitable. If you choose ten people
at random from an organization the chances that they will agree on
upsetting the status quo is very low.

Its exactly what you expect from a group of academics, its a tenure
system. Its also what you would expect from a group of engineers, an
environment where accountability and deadlines are always secondary
to idealized technical perfection.

I do not beleive that the outcome of MARID would have been any different
under any other chairs.

I do however think that the outcome would have been likely to have 
been better in a system where the group choose its own chairs rather
than having them imposed by the exstablishment. This is not because I
think the chairs would have been different, I suspect that the same
people would have volunteered and I doubt that the election would have
been contested, but the group members would have felt that they have
a stake in the management of the group. People are more likely to accept
decisions made by people they feel they have a stake in choosing - even
when they voted for somebody else.

> MARID specific comment:
> What happened here doesn't seem to be a failure, but rather was a 
> success in the following sense: There was not sufficient maturity in the 
> proposals for a rough consensus to be reached that the proposals were 
> adequate to meet the bare minimum of goals that they needed to meet.  

I disagree. SenderID/SPF is currently in deployment and is working just 
fine in production. Maturity was not the problem. 

I think that there was a mismatch of expectations between people who
thought that the purpose of the group was to agree on a refinement of
an existing specification that had already achieved a very large degree
of industry buy in and those who thought that it was an open forum to
propose their alternative idea.

I have never been in a standards group of the second type that has
succeeded. In every case that a group has suceeded the starting point
has been a specification that was already largely complete.

> The process brought the fact to light that the proposals were 
> inadequate.  Many of us weren't aware of this early on.  3929 
> seems to 
> assume that a failure to reach a rough consensus must mean there's a 
> problem in the process, when in fact it could be in the proposals.

I think that as a practical matter the issue of acceptable IPR terms
should not be discussed at the working group level where the bargaining 
leverage is least.

I found it practically impossible to follow the alledged discussion
of technical issues due to the constant heckling and deliberate
recycling of false positions. The lack of consensus inside the group
did not reflect the solid industry consensus for SPF/SenderID that
had already been established before MARID started.

It may not seem fair but an engineer who is representing the issues
of an ISP with 20 million customers has a rather larger stake in
the outcome than an individual contributor responsible to nobody but 
themselves.

---

From: Markus Stumpf <[email-masked]>
Date: Wed, 27 Oct 2004 21:52:20 +0200

> had already been established before MARID started.

Hmmm ... but the lack of consensus was driven by the patent policy
Microsoft had. Even AOL refrained from supporting Sender-Id.

But the last two days (german) IT news are fill with press reports
that MS will loosen the patent policy and that AOL jumped back in.

... and that the IETF is now supporting Sender-Id? Am I missing something?

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"

---

From: Paul Iadonisi <[email-masked]>
Date: Thu, 28 Oct 2004 03:23:32 -0400

On Wed, 2004-10-27 at 11:04, Hallam-Baker, Phillip wrote:

[snip]

> recycling of false positions.

  Hmm.  Heckling and deliberating recycling of false positions.

  I, as one who participated in some of the last call discussion don't
appreciate your revisionist history, Phil.

  As to the heckling, if you are referring to anti-Microsoft rants,
those were actual minimal due to the fact that when they appeared, the
guilty posters were roundly chastised by the co-chairs.  What remained
was good reasoned discussion of a specific deployment problem due to IPR
issues.
  As to the so-called 'false positions', I can only reply in disbelief
that you simply assert that those with whom you disagreed were simply
wrong.  Such arrogance.  Arguments were repeated when they were
methodically ignored by those who wanted to sweep the significant
deployment IPR problem under the rug.
  I repeated over and over again that we had three lawyers' opinions
that agreed that the patent license was unacceptable and zero lawyers'
opinions that it was acceptable for a reason.  It was because no one had
directly responded to it.  When you have an argument that carries a lot
of weight that is being ignored, it bears repeating.

-- 
-Paul Iadonisi
 Senior System Administrator
 Red Hat Certified Engineer / Local Linux Lobbyist
 Ever see a penguin fly?  --  Try Linux.
 GPL all the way: Sell services, don't lease secrets

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 Oct 2004 14:58:35 +0200

On Wed, Oct 27, 2004 at 09:52:20PM +0200,
 Markus Stumpf <[email-masked]> wrote 
 a message of 21 lines which said:

> that MS will loosen the patent policy

I do not think that Microsoft announced anything concrete on the
patent front. Does anyone has a reference?

> ... and that the IETF is now supporting Sender-Id? 

This is certainly false. IETF supports nothing since the disbanding of
the MARID Working Group (the new Microsoft Internet-Draft has not even
been published by IETF, probably because it was submitted after the
cutoff - http://www.ietf.org/meetings/cutoff_dates_61.html).

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 28 Oct 2004 07:14:54 -0700 (PDT)

> patent front. Does anyone has a reference?

What they said is that they will (have already?) modify their 2nd patent 
application so it is not so broad and does not cover RFC2821 identities
and SPF classic - 
http://news.zdnet.com/2100-9588_22-5426045.html
"The software giant said Monday that it has rewritten Sender ID--a 
 specification for verifying the authenticity of e-mail with Internet 
 Protocol records--to address criticisms of the spec's earlier incarnation. 
 Among other changes, Microsoft removed language in its pending patents
 for SenderID that could have included claims to Sender Permitted From, 
 or SPF, a widely used system for e-mail authentication that was merged 
 with Microsoft's CallerID for Email to create Sender ID, according to 
 Microsoft's Ryan Hamlin."

(P.S. I'm going to contact the author of that article to fix the last
 paragrapth and not mislead people to think that IETF has granted any
 status to the documents - in fact new senderid spec has not even been
 published as a draft yet)

There was nothing anywhere about them changing their license agreement
and they appear to have no plans for that (rumors are that some Microsoft
employes who have participated in MARID did ask to get different license
agreement that would work better for F/OSS software but that request has 
been declined at Microsoft at the very highiest level).

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: wayne <[email-masked]>
Date: Thu, 28 Oct 2004 16:41:46 -0500

> fine in production. Maturity was not the problem. 

SPF-classic is currently widely deployed.  SenderID, and the new
SPF-classic, however, are not deployed.  What little information about
the performance of SenderID indicates that it is probably not as
reliable as old SPF-classic.

Maturity certainly was a problem.  

> has been a specification that was already largely complete.

That is exactly what MARID did.  We tried to create SenderID.  Things
only moved forward in fits and starts when SenderID moved closer to
SPF-classic. 

-wayne

---

From: James Couzens <[email-masked]>
Date: Fri, 29 Oct 2004 09:44:09 -0700

> > fine in production. Maturity was not the problem. 

SenderID != SPF.  Please don't associate the two.  This entire merging
of technologies was such a horribly stupid idea.  Can someone remind me
why we took a perfectly progressive, active and supported technology
that was OPEN and FREE and decided to take it out back and beat the
living tar out of it?  Oh thats right "we" didn't make that decision.
Funny how that works.

> Maturity certainly was a problem.  

I would consider DK before SenderID, its most certainly more mature and
it also hasn't spent the last ~6 months beating around the proverbial
bush debating stupid software patents.

Cheers,

James

James Couzens,
Programmer
                        ^                            ( ( (      
      ((__))         __\|/__        __|+|__        '. ___ .'    
       (00)           (o o)          (0~0)        '  (> <) '    
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

---

From: Andrew Newton <[email-masked]>
Date: Fri, 29 Oct 2004 16:45:13 -0400

> bush debating stupid software patents.

I don't know what you mean by "debating", but you might want to take a 
closer look at the IPR disclosures page.

-andy

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 29 Oct 2004 14:33:05 -0700 (PDT)

> closer look at the IPR disclosures page.

Andrew, you should know quite well by now that just IPR is not enough and 
until we actually see the licese the patent issue is still there.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Fri, 29 Oct 2004 17:19:47 -0400

> until we actually see the licese the patent issue is still there.

Are we talking about the same thing?  Did I dismiss any patent claims 
in my statement above?

-andy

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 29 Oct 2004 14:56:05 -0700 (PDT)

Original: 

| On Oct 29, 2004, at 12:44 PM, James Couzens wrote:
|
| > I would consider DK before SenderID, its most certainly more mature and
| > it also hasn't spent the last ~6 months beating around the proverbial
| > bush debating stupid software patents.
| 
| I don't know what you mean by "debating", but you might want to take a
| closer look at the IPR disclosures page.
|
| -andy

My answer (corrected spelling, missing word):

| Andrew, you should know quite well by now that just IPR disclosure
| is not enough and until we actually see the license the patent
| issue is still there.

Andrew Newton's answer to above:
 
> Are we talking about the same thing? 

Yes we're talking about same thing. You seem to have applied that for
WG to deal with patents most important is the IPR and then the debate
and issue is over. Its actually been backwards - we knew from the start
the IPR is there but the debate was not about the existance of the IPR,
but about the license. 

Now some in IETF might say that IPR disclosure already provides information
about what kind of license it would be (i.e free for all, etc) but it 
appears that disclosure in the IPR document is not enough and until we
actually see the license, the WG can't be sure how much of an issue the 
patent is and this may result in intense debates at the very crucial point 
of the WG's work cycle.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Fri, 29 Oct 2004 18:00:13 -0400

> patent is and this may result in intense debates at the very crucial 

No, we're not talking about the same thing.

In the statement above, James used the word "debating".  And when I 
said "I don't know what you mean by 'debating'", I meant that I didn't 
understand the use of the word "debating" in his sentence since it 
seemed to have applied to "stupid software patents" ( and not stupid 
software patent licenses as you seem to have further honed in upon ).  
However, if "stupid software patents" are the issue then I have 
suggested a closer look at the IPR disclosures page given James' words 
of "I would consider DK before SenderID".  Or in other words, there is 
a patent covering DomainKeys.

-andy

---

From: wayne <[email-masked]>
Date: Fri, 29 Oct 2004 17:26:15 -0500

> closer look at the IPR disclosures page.

While I have problems with software patents in general, I realize that
is not an issue that should be dealt with in an IETF WG.

The Yahoo Domainkeys patent license is available at:
http://antispam.yahoo.com/domainkeys-license-01

While I have not reviewed it closely, it is my understanding that it
has no conflicts with either Free/Open Source Software, nor
proprietary software.  *This* was the issue that caused so much
problems here.  (Well, that and various unresolved technical problems
with the PRA.)

-wayne

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 Oct 2004 15:46:38 -0700

On Fri, 2004-10-29 at 09:44, James Couzens wrote:

> SenderID != SPF.  Please don't associate the two.

I agree.  How does one establish a mix of divergent approaches?  A chain
of trust is broken when each node checks a different mailbox-domain.  It
is also seems inappropriate to misapply a record intended for a
different mailbox-domain.  Handing multiple accountable identities is
daunting, especially when a change in convention between administrative
domains makes spoofing easy.  Correlating the mailbox-domain checked and
then displayed becomes another matter.

Regardless of the mailbox-domain checked, leaving authorization normally
open-ended overcomes present problematic header conventions.  Only
institutions dealing with a phishing problem would have an incentive to
tackle closing the authorization list.  Changing from an address-list to
a name-list overcomes exploits invited by an open-ended authorization
list as well, as this would imply a separate entity is utilized for
reputation. 

-Doug

---

From: "Alan DeKok" <[email-masked]>
Date: Fri, 29 Oct 2004 19:39:38 -0400

Douglas Otis <[email-masked]> wrote:
> How does one establish a mix of divergent approaches?  A chain
> different mailbox-domain.

  I agree completely.

  We should start with fields which have simple, well-known semantics
such as EHLO, and then work our way to fields which have complex,
poorly understood semantics.

> Handing multiple accountable identities is daunting, especially when
> a change in convention between administrative domains makes spoofing
> easy.

  If we ensure that the MTA's are individually accountable, and that
each message is authenticated and tracked through the system, then
spoofing becomes much more difficult.

  SMTP is not currently such a system.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 29 Oct 2004 18:07:16 -0700

On Fri, 2004-10-29 at 16:39, Alan DeKok wrote:
> > is also seemingly inappropriate to misapply a record intended for a

The goal should be directed toward ensuring security and responding to
apparent breaches.  Reputation should be based upon the response to
notifications and must directed to the entity able to take immediate
action. To ensure these notifications are not based upon spoofed
identifications, this identity should also be directly validated. 
Spammers are good at injecting noise into an abatement effort. Security
is the challenge, as breaching security is the common enabler for much
of the spam. 

> spoofing becomes much more difficult.

By separating the accountable entity from a mail-channel description,
individual MTA administrators are revealed.  By taking this approach,
the mailbox-domain compared to a mail-channel description becomes less
critical, as the mail-channel is not assessed for a reputation.

The mail service provider could protect themselves by asserting the
large customer's domain when sending their mail. 

>   SMTP is not currently such a system.

It could be with a deceptively simple change.

-Doug

---

From: John Levine <[email-masked]>
Date: 30 Oct 2004 15:36:29 -0000

>SPF-classic is currently widely deployed.

People have published a lot of SPF-classic records in DNS, but I wouldn't
confuse that with deployment.

The amount of mail going through SPF tests is still small, and only a few
aggressively wacky sites block mail that fails SPF.

-- 
John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711
[email-masked], Mayor, http://johnlevine.com, 
Member, Provisional board, Coalition Against Unsolicited Commercial E-mail

---

From: wayne <[email-masked]>
Date: Sat, 30 Oct 2004 14:20:54 -0500

> confuse that with deployment.

I am not confusing the two.  Yeah, it is much easier to check how many
people are publishing SPF records than checking them, but that doesn't
mean that you can't get clues to the latter.

> aggressively wacky sites block mail that fails SPF.

Ok, let me ask you:

How do you know that "the amount of mail going through SPF test is
still small"?

What do you define as "small"?

How "small" is spf testing compared to other things, such as various
DNSBL checks, or SpamAssassin usage, or whatever?

-wayne

---

From: Daniel Senie <[email-masked]>
Date: Sat, 30 Oct 2004 17:34:09 -0400

>aggressively wacky sites block mail that fails SPF.

With the release of SA3.0, this is likely changing. We're not willing to do 
SPF checks during the SMTP transaction due to concerns over mailing list 
handling (mishandling) we've already seen in some early SPF deployments, 
but we are starting to use SPF checks in SpamAssassin, and expect to 
continue to do so.

We've also started publishing some SPF records again (we'd stopped when we 
found several sites using the SPF records in ways that broke mailing lists).

Dan

---

From: Daniel Senie <[email-masked]>
Date: Sat, 30 Oct 2004 17:34:09 -0400

Dan

---

From: John Levine <[email-masked]>
Date: 31 Oct 2004 04:15:02 -0000

>With the release of SA3.0, this is likely changing.

Small amount of mail tested, or few wacky sites?  Both, I suppose.

If people really are doing tests of SPF or Sender ID or other similar
schemes, I'd be most interested in hearing about the results,
particularly numbers of how much legit mail is tagged valid or
invalid, how much spam is tagged valid or invalid, and how spammers
are adapting/ Ciphertrust says they've seen more spam than good mail
pass SPF checks.  That doesn't surprise me, but their numbers were so
small that I'd like to see some confirmation.

---

From: Paul Iadonisi <[email-masked]>
Date: Sun, 31 Oct 2004 01:06:51 -0500

On Sun, 2004-10-31 at 00:15, John Levine wrote:

[snip]

> and how spammers
> pass SPF checks.

   I hope you're not implying that that's a bad thing.

---

From: "Paul S. Brown" <[email-masked]>
Date: Sun, 31 Oct 2004 10:52:10 +0000

> small that I'd like to see some confirmation.

I've got an SPF setup running at the moment - not a high traffic site - around 
4k messages per day.

The results I'm seeing are something like:

85% - No Record
5% - Hard Fail - Breached record 
10% - SoftFail

Of the hard fails none are legit - I'm actually bouncing on hard fail.

So far, all of the SoftFails have been eBay Phishes - I have my system set up 
to make sure that softfails get through, but get hammered through every evil 
that SpamAssassin and DSPAM can do to them.

Now, granted that I have SPF as a last layer behind a couple of DNSBLs, 
numerous header and body checks and Greylisting, but I'd have expected 
something to have managed to get through that was handled in a non-optimal 
manner - so far nothing.

P.
-- 
If Mind over Matter is a Matter of Course
 Does it Matter if Nobody Minds?

---

From: Koen Martens <[email-masked]>
Date: Sun, 31 Oct 2004 11:44:55 +0100

> small that I'd like to see some confirmation.

For what it's worth, we've been running an end user support system for
spf for about 3 weeks now. We have had about 4 requests from people who
had their mail blocked by spf checking sites (and wrongly, as our
subsequent investigations showed). That's out of a 30-40 requests coming
in in total.

I myself have been checking spf for months now, and never had someone
complain about not getting through. Granted, email is not my core
business and volume is relatively low. Most spam is stopped by other
checks anyway. SPF is not an anti-spam solution.

Koen

-- 
K.F.J. Martens, Sonologic, http://www.sonologic.nl/
Networking, embedded systems, unix expertise, artificial intelligence.
Public PGP key: http://www.metro.cx/pubkey-gmc.asc
Wondering about the funny attachment your mail program
can't read? Visit http://www.openpgp.org/

---

From: James Couzens <[email-masked]>
Date: Sun, 31 Oct 2004 04:29:46 -0800

> list as well, as this would imply a separate entity is utilized for

. o O Mmmmmm... I wonder just how it was possible that something like
the KISS principle was completely cast aside instead opting to do the
exact opposite.  

I do not know about you, but if I was put in charge of getting a penguin
and a misappropriated series of window frames in a room to chat about
implementing a technology of which the window frames seem incapable of
intelligently dealing with IPR claims to (and without involving their
Media/FUD machine every time), I would try to keep things as simple as
possible.  

There exists a very amusing /. post which had a would be chat involving
client's whose names represented the various parties with vested
interest in the outcome of this WG's efforts.  I'm not going to post it
here but its exceptionally amusing, and unfortunately a very accurate
representation of the events that took place here.  Hopefully we won't
see a repeat of this in the future. 

Cheers,

James

-- 
James Couzens,
Programmer
                                                     ( ( (      
      ((__))         __\|/__        __|-|__        '. ___ .'

---

From: wayne <[email-masked]>
Date: Sun, 31 Oct 2004 07:11:34 -0600

> Small amount of mail tested, or few wacky sites?  Both, I suppose.

You are the one that made the claim "The amount of mail going
through SPF tests is still small, and only a few aggressively wacky
sites block mail that fails SPF."

Surely, you have data to back up your claim.

I have some data that related to your claim, but first I want you to
answer the following questions:

-wayne

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 31 Oct 2004 09:45:36 -0500

> small that I'd like to see some confirmation.

After DNSBLs, SPF is my most successful spam filter.  Here's my 
latest mail report (# of messages rejected/reason).

7951	550 User unknown.
6182	517 HELO mismatch
1310	502 ESMTP command error
1171	511 Blocked by www.spambag.org : Blocked
839	517 Sender Policy Framework error
81	551 DNS lookup failure
74	558-500-sam:558 500 Message rejected by recipient's mail filter (BCC).
67	Connection timed out
35	500 Microsoft virus refused.
22	550-The headers in this message contain improperly-formatted binary…
21	513 Relaying denied.
21	550-This message contains improperly-formatted binary content…
20	550-This message contains text that uses unnecessary base64…
14	517 Syntax error.
<= 10	79 errors for 44 types

SPF blocks ten times more spam than the next most common spam filter.  Also, 
a fairly good portion of the "HELO mismatch" rejects would've probably been 
caught by the SPF checks too.

I have occasional reports of false positives, but they were related to other 
causes.  No false positives reported for SPF.

---

From: James Couzens <[email-masked]>
Date: Sun, 31 Oct 2004 07:01:31 -0800

> causes.  No false positives reported for SPF.

I'm curious about your "error".  These are FAIL, SOFTFAIL, UNKNOWN,
ERROR or ?.  I'd appreciate any clarification you can specify here.

Cheers,

James

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 31 Oct 2004 10:18:53 -0500

> ERROR or ?.  I'd appreciate any clarification you can specify here.

I reject FAIL and SOFTFAIL.  I accept UNKNOWN and ERROR.

---

From: Paul Iadonisi <[email-masked]>
Date: Sun, 31 Oct 2004 10:36:17 -0500

On Sun, 2004-10-31 at 07:29, James Couzens wrote:

[snip]

> see a repeat of this in the future. 

  Unfortunately, with the apparent power-grab of RFC3929, I think we're
likely to see much, much worse.
  I was skeptical of those who said that many see the IETF as losing its
relevance.  I fear that if RFC3929 moves beyond experimental status,
then that will come true very quickly, if it's not already.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Sun, 31 Oct 2004 17:52:27 +0100

Paul Iadonisi writes:
>   Unfortunately, with the apparent power-grab of RFC3929, I think 
>   we're likely to see much, much worse.

«In no way should this experiment or any future BCP for this small 
number of cases take precedence over the IETF's normal mode of 
operation.»

So, basically, if we can't agree on the mailing list, 3929 
experimentally suggests trying a different way.

Some power grab.

Arnt

---

From: John Levine <[email-masked]>
Date: 31 Oct 2004 17:34:33 -0000

>> and how spammers are adapting/ Ciphertrust says they've seen more
>> spam than good mail pass SPF checks.

>   I hope you're not implying that that's a bad thing.

No, of course not.  But it reminds us that anyone who thinks he's
going to block a lot of spam merely by rejecting mail that fails SPF
or any other sender/IP check is likely to be disappointed.  It may
block some now, but spammers have reminded us that they'll adapt.

---

From: Paul Iadonisi <[email-masked]>
Date: Sun, 31 Oct 2004 15:18:53 -0500

On Sun, 2004-10-31 at 11:52, Arnt Gulbrandsen wrote:

[snip]

> Some power grab.

  Elsewhere in the RFC it is an acknowledged risk that an individual can
game the system with this approach.  That's enough of red flag for me.

---

From: Sam Varshavchik <[email-masked]>
Date: Sun, 31 Oct 2004 19:19:18 -0500

> block some now, but spammers have reminded us that they'll adapt.

And, when they do, the methods used to fight them will adapt also.