Subject: MARID to close

From: Ted Hardie <[email-masked]>
Date: Wed, 22 Sep 2004 09:31:26 -0700

After an assessment of the current state of the MARID working group, 
its charter, and its milestones, the working group chairs and Area 
Advisor have concluded that the MARID working group should be 
terminated.

The group was originally chartered with a very tight time frame, with 
the expectation that a focused group of engineers would be able to 
produce in relatively short order a standard in the area of 
DNS-stored policies related to and accessible by MTAs.  The group has 
had no lack of energy.  From the outset, however, the working group 
participants have had fundamental disagreements on the nature of the 
record to be provided and the mechanism by which it would be checked. 
Technical discussion of the merits of these mechanisms has not swayed 
their proponents, and what data is available on existing deployments 
has not made one choice obviously superior. Each represents 
trade-offs, and the working group has not succeeded in establishing 
which trade-offs are the most appropriate for this purpose.  These 
assessments have been difficult in part because they have been moved 
out of the realm of pure engineering by the need to evaluate IPR and 
licensing related to at least one proposal in the light of a variety 
of licenses associated with the deployed base of MTAs. 

Efforts to reach consensus by compromise and by inclusion have been 
attempted on multiple occasions.  Despite early hopes of success 
after each such attempt, post-facto recycling of technical issues 
which these efforts should have closed has shown that the group 
remains divided on very basic issues.  The working group chairs and 
Area Advisor are agreed that the working group has no immediate 
prospect of achieving its primary milestone:

Aug 04   Submit working group document on MTA Authorization Record in DNS to PS

Rather than spin in place, the working group chairs and Area Advisor 
believe that the
best way forward is experimentation with multiple proposals and a 
subsequent review of deployment experience.  The working group chairs 
and Area Advisor intend to ask that the editors of existing working 
group drafts put forward their documents as non-working group 
submissions for Experimental RFC status. Given the importance of the 
world-wide email and DNS systems, it is critical that IETF-sponsored 
experimental proposals likely to see broad deployment contain no 
mechanisms that would have deleterious effects on the overall system. 
The Area Directors intend, therefore, to request that the 
experimental proposals be reviewed by a focused technology 
directorate. This review group has not yet been formed but, as with 
all directorates, its membership will be publicly listed at 
http://www.ietf.org/u/ietfchair/directorates.html once it has been 
constituted. 

Concluding a group without it having achieved its goals is never a 
pleasant prospect, and it is always tempting to believe that just a 
small amount of additional time and energy will cause consensus to 
emerge.  After careful consideration, however, the working group 
chairs and area advisor have concluded that such energy would be 
better spent on gathering deployment experience.

				regards,
					Ted Hardie
					co-Area Director, Applications

---

From: wayne <[email-masked]>
Date: Wed, 22 Sep 2004 13:10:25 -0500

> Advisor have concluded that the MARID working group should be

*heavy sigh*

I think this is a mistake.

I agree that this is currently no consensus, but I do not think that a
rough consensus is out of reach.

I think there are several things that could be done to bring
consensus.

First off, IPR issues can not be ignored.  This was a recognized
problem since before the interim meeting and was discussed at that
meeting.  The failure of the AD and co-chairs to make sure that these
problems were resolved many months ago is an astounding failure.  I
personally feel that Ted Hardie (AD) is very much responsible for this
failure as Ted actively tried to sweep this problem under the rug
instead of solve it.

Secondly, the co-chairs/AD allowed this working group to try and
create a standard, instead of standardizing existing practices.  It is
far easier to reach a rough consensus on what people *ARE* doing that
what people *SHOULD BE* doing.  Even if you don't like what people are
doing, it is very useful to give clear descriptions of what is being
done.

Thirdly, the co-chairs/AD only allowed one proposal to advance.  They
put all the eggs in one basket and now that basket is smashed.  This
has caused people to fight against each other in order to get that one
spot for advancement.  For the 2822.From: identity, only the patent
encumbered PRA was considered, greatly increasing the problems of
licensing.  For the 2821.HELO identity, it was CSV only, instead of
both CSV and SPF-classic's HELO checking.  For the 2821.MAILFROM
identity, *nothing* was advanced, even though it is what a majority of
the input documents dealt with and what a vast majority of the
deployed code uses.

>                                The working group chairs and Area
> Advisor are agreed that the working group has no immediate prospect of
> achieving its primary milestone:
>

Actually, the marid-protocol I-D seems to have a rough consensus to
me.  This *is* an MTA Authorization Record in DNS.  

> believe that the best way forward is experimentation with multiple
> proposals and a subsequent review of deployment experience.

This is what should have been done all along.

> better spent on gathering deployment experience.

I do not believe that just a small amount of additional time and
energy will lead to consensus.  I do believe that a change of tactics
by the co-chars and AD would.  I believe that this has been obvious
since the first month or two of this working group.

-wayne

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 22 Sep 2004 11:11:28 -0700 (PDT)

I'd like to request that this mail list not be closed together with WG so
that we could continue to discuss dns / email authorization technologies 
here and get input into possible experimental drafts that some may want 
to publish that address the area that this WG was supposed to work on.

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 22 Sep 2004 20:24:19 +0200

> to publish that address the area that this WG was supposed to work

I second this proposal and like to request to keep the archives
open as well.

I'd also like to discuss the non-technical part (e.g. patent issues, 
laws, the OECD recommendations, etc., everything which is related to 
email authorization).

If this list won't stay open or is the wrong place to go on with that 
kind of discussion, I can offer to open an mailing list for that.

regards
Hadmut

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 22 Sep 2004 20:44:55 +0200

On Wed, Sep 22, 2004 at 01:10:25PM -0500, wayne wrote:
> 
> The failure of the AD and co-chairs to make sure that these
> problems were resolved many months ago is an astounding failure. 

I agree. They did their very best to ignore the major 
problems and to aggressively make everyone quiet who tried
to mention the problems. 

regards
Hadmut

---

From: Andrew Newton <[email-masked]>
Date: Wed, 22 Sep 2004 15:00:38 -0400

> to publish that address the area that this WG was supposed to work on.

I think this is an excellent idea.

-andy

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 22 Sep 2004 22:25:09 +0200

wayne wrote:

> I believe that this has been obvious since the first 
> month or two of this working group.

I agree with everything you say.  What was the idea here,
waiting until somebody patented ideas stolen from the 
IETF, and then close the corresponding WG ?

                         Bye, Frank

---

From: Mark Baugher <[email-masked]>
Date: Wed, 22 Sep 2004 13:23:26 -0700

I am sorry to read stuff like this and feel that the chairs did a 
pretty good job and so did the IETF despite this particular 
disappointment.

Mark

---

From: <[email-masked]>
Date: Wed, 22 Sep 2004 16:39:31 -0400

If certain people had been a little more "PRO GROUP" and a little less "PRO WHATEVER MS WANTS TO
PUSH" then I would agree with you.

But the facts are the facts:
-the suppression of anyone talking about the IP concerns
-the suppression of the original mail-from SPF functionality
-accepting the repeated disclosure delays from Microsoft
-giving the OK to the MS license which is clearly incompatible with a significant portion of MTA's
-the suppression of alternative parallel scopes (until forced at the very end)

Therefore I cannot agree with you.  It stank from day 1, and this effort of MS to steal the IP of
SPF and related methods illustrates an ulterior motive from the start.  The good news is I don't
think it will work, providing the patent claims are fought off with prior art disclosure, and the
fact that MS does NOT represent the majority of MTA's anyway.

Lets proceed with SPF Classic and/or Unified SPF.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[email-masked]
Fax: (416) 441-9085

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mark Baugher
> Sent: Wednesday, September 22, 2004 4:23 PM
> To: Hadmut Danisch
> Cc: IETF MARID WG
> Subject: Re: MARID to close
>
>
>

---

From: [email-masked]
Date: Wed, 22 Sep 2004 13:57:30 -0700

> I second this proposal and like to request to keep the archives

I would like to see the archives remain available for educational and 
reference purposes. I would consel the chairs to close the email list. 
It has served its purpose.  The WG is disbanded.  I see no value in 
continuing the list.  Given the tone the list has assumed, I had and 
have no further interest in reading posts.

Bryce Ryan

---

From: Michael Hammer <[email-masked]>
Date: Wed, 22 Sep 2004 17:22:57 -0400

First off I'd like to thank the co-chairs and AA for taking on a
difficult task under difficult circumstances. Regardless of how things
have played out it bothers me that some would accuse them of
ill-intent or not doing a good job. While I don't agree with all the
calls they made I'm not going to second guess those calls.

I am disappointed that everyone is being turned loose to go their own
way and experiment. This sort of approach is likely to increase email
deliverability problems without addressing the issues that resulted in
the formation of the working group. This is too important to let folks
"duke it out" and whatever is left is the standard.

Given the current circumstances I would be interested in how
participants of the list would answer the 30 questions listed in the
FTC/NIST Email Authentication Summit announcement. I'm still digesting
the questions but do plan on writing down answers (not necessarily for
submission to the FTC) and may post them to the list.

If anyone else from the list is planning on attending the Summit (Nov
9/10 in Washington, D.C.) I wouldn't mind trying to get together a
group of MARID list folks for dinner/discussion the evening of
November 9th. Nothing formal and not sure what would come out of it.

Mike

---

From: Yakov Shafranovich <[email-masked]>
Date: Wed, 22 Sep 2004 17:48:19 -0400

[email-masked] wrote:
>>> that we could continue to discuss dns / email authorization 
>>> technologies here and get input into possible experimental drafts 
>>> that some may want to publish that address the area that this WG was 
>>> supposed to work
>>> on.
>>
>>

There are multiple mailing lists operated on IMC.ORG that are related to 
the IETF and Internet email, while not being "official" lists of the 
IETF but serving as WG lists at some points. This may continue as one of 
them. Archives are of course always available at the IETF and Gmane.org.

Yakov

---

From: [email-masked]
Date: Wed, 22 Sep 2004 19:00:49 -0400 (EDT)

On Wed, 22 Sep 2004, Ted Hardie spewed into the bitstream:

TH>
TH>After an assessment of the current state of the MARID working group, 
TH>its charter, and its milestones, the working group chairs and Area 
TH>Advisor have concluded that the MARID working group should be 
TH>terminated.

An excellent choice. The whole of this has been an exercise in futility
from day one. The knowledge of hidden limits made clear last week when
the patent applications were published was clearly available to one of
our members when we started and they chose to jerk several hundred
people around for months in a clearly concerted effort to increase their
already overwhelming market dominance. I will not personally involve
myself again as a willing contributor in any process that presumes
decency, honesty, or simple forthright behavior from that member.

good luck.

- --
[email-masked], head geek
http://moongroup.com

---

From: Rik van Riel <[email-masked]>
Date: Wed, 22 Sep 2004 19:13:29 -0400 (EDT)

> Lets proceed with SPF Classic and/or Unified SPF.

I hope we'll be able to proceed with SES.  It seems much
nicer in that it provides end-to-end authentication.

Rik
-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

---

From: Ryan Ordway <[email-masked]>
Date: Wed, 22 Sep 2004 17:05:45 -0700

> Advisor have concluded that the MARID working group should be 

	A sad but IMO forseeable event.

> better spent on gathering deployment experience.

	I truly hope that the work that has been
done here can eventually translate into a working
standard. If not MARID, then something. I'm sure even
those vehemently against what has gone on here can
agree that SOMETHING needs to be done, and the
piecemeal solutions to-date are obviously note enough.
We need a solution. 

	Many thanks to the co chairs, Mr. Hardie
and everyone else.

	Ryan

-- 
HELO, my name is root... you have SIGKILLed my father... prepare to vi!

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 23 Sep 2004 00:08:48 -0400

Ted, Andy:

I think this a good direction.  I believe the opportunity should remain
available to explore the "right" solution.  I also believe keeping this
forum/mailing list in place will provide an avenue of public record and
disclosure for all parties.  So I welcome this direction and I personally
would like to get more involved if its in the right direction with the
proposed review group.   We have commercial deployment experience with a
suite of methods, including SPF, Microsoft Caller-ID,  CBV (Call Back
Verification),  RBL and other concepts and methods centralized designed
around strong product liability considerations.

With that said, I would like to make specific comments and recommendations.
Hopefully, some of the comments will provide helpful feedback to help mode
the new direction.

First I hate to deviate to this, but around here, it sounds like it needs to
be stated.  Although IANAL, I was trained to understand IP and analyze IP.
My 25+ years of rich engineering expertise and understanding of high tech IP
related issues in both the corporate and private market place is well
established. This includes an understanding of the patent process both past
and present, especially how the software patent process has changed over the
years. . In short, there has nearly not been one day in my entire career
where IP, especially product liability issues was not a major part and/or
consideration for systems projects and/or product lines.

With that said, I will note that in regards to the recent MS patents,  we
have no concerns with the claims cited in the patent applications.  We have
been in this market for a long time with a high-end, integrated product line
and this certainly not the first time new software patents based on post
1996 relaxed guidelines were issued with claims touching based with old
technology or methods re-invented as "internet solutions.".  Push comes to
shove, the prior art, obviousness, the relationship of natural elements in
the Markush-type claims for these specific patent applications and the
negligence of due diligence can be well established by the expert in the
field and market of invention.  So we are not worry about it.  Like the
others with frivolous prior-art claims,  it would not be in Microsoft
interest to enforce and pursue this in a court of law as it will open the
door for counter-suits and patent review and establishing invalidity.

I mentioned this because I believe the problem with MARID was its structure
which allowed the MS patent to happen to the first place.  Back in July, I
offered a proposal to restructure the core to eliminate the IP issue. This
proposed design structure is 100% based on providing fundamental protection
against with Markus-type claims.

I don't think it needs to be restate the proposal at this point, however, I
do believe the following items are extremely important considerations in
this new direction.

1) SMTP Protocol Summary

We need to create a summary statement what are the critical issues with the
SMTP.  What are the loop hole? What are the ambiguities that need to be
cleared up?  What are the possible compatibility issues?  What are the
current authentication methods?

This will be the basic problem statement that will help provide a total
picture and "Check Off list" for the augmentation of new Extended SMTP
security enhancements.

2) Extended SMTP Protocol Security Enhancements.

Once have the SMTP Protocol Summary, we can begin to suggest the natural and
obvious black box extensions that provide added security.

In my view, this could of been the MARID CORE specification, however, as it
was currently, it was locked into some current problematic and troublesome
proposals.

What need to do is "separate" the protocol from the actual implementations
in the market place.  This is very important and it will lay and establish
the groundwork to pre-empt Utility Patents claims against the process.   I
should note this is already prior art and thus provides, if required,
evidence for disputes against the Microsoft Patents.  It is for this reason,
Santronics is not concern about these recent email patents as this have been
the framework for Santronics mail and file servers for many years.

Nonetheless, MARID needs to take a position where a CORE specification
provides an open-ended security enhancements to the SMTP protocol.

Once this is done, the proposed "review group" can be used this new MARID
CORE as a framework to evaluate new MARID compatible protocol proposals.

What will the MARID-CORE include?

The most important ones that stand out are:

- a generic framework for ESMTP mail sender/client validation, i.e., like
LMAP.

- a new standard for client/server version recognition,

- a proposal new set of new ESMTP commands,

- a new standard set of ESMTP response codes,  and

- a guideline to backward SMTP compatibility (how to deal with legal
operations.).

3) Optional: Rewrite SMTP 2821

One of the problems MARID had from the beginning was that lack of
participation of the core IETF-SMTP participants, including the WG chair,.
I was astonished by the response by the chair, the author of RFC 2821, as to
why he opted out of the MARID process.  It was not to hard to see that MARID
was crippled when the suggestions in the proposals did not even go their the
IETF-SMTP process.  It was the somewhat the same issue with RFC 2822 but
here there was some IETF-2822 participants due to the significances of the
822/2822 related issues.

In any case, unless the MARID group gets the IETF-SMTP involved,  it will be
a tough climb to reach the common goals we are all looking for success
across the board.   We need to recognize that the old design philosophy in
SMTP 2821, a "relaxed internet spirit required for wide deployment with less
emphasis with security" no longer applies today.

In summary:

In step 1,  we take a step back to the SMTP protocol to establish the
groundwork for step 2.  We get a good picture of what's wrong with the
protocol.  At a minimum, by providing a new SMTP specification in step 3 it
establishes a unambiguous basis for current or new SMTP mail servers to use
for required hosting requirements in the new era.  Finally, in step 2, the
new MARID-CORE is designed with a new level of SMTP operational expectations
that it can use as a generic framework for mail security.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office

----- Original Message -----
From: "Ted Hardie" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Scott Hollenbeck"
<[email-masked]>
Sent: Wednesday, September 22, 2004 12:31 PM
Subject: MARID to close

> believe that the best way forward is experimentation with multiple
proposals and a