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" <hardie(_at_)qualcomm(_dot_)com>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Cc: <andy(_at_)hxr(_dot_)us>; <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us>;
"Scott Hollenbeck"
<sah(_at_)428cobrajet(_dot_)net>
Sent: Wednesday, September 22, 2004 12:31 PM
Subject: MARID to close
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