Subject: RE: Licensing issues

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 16 Jul 2004 09:57:53 -0700

> You corporate guys appear to have bunched together in a group and *DO
> NOT* appear to want to *HEAR* what the non-corporates think!

It is very clear that none of the people raising objections in this
thread have bothered to read the archives of this mailing list.

I don't want to hear if you don't listen.

The issue was raised, we are waiting for clarification from the lawyers. 

Accusing Microsoft of bad faith less than 48 hours after the request
for clarification is made does not appear to me to be a good faith
complaint.

> | And BTW GNU would be an entirely unacceptable licensing scheme for
> | a patent controlling a protocol standard in any case.
> 
> Fine. Then use SPF-Classic which is unencumbered and let's have done
> with it. How in the sam hill do you patent something which is
> pre-defined in pre-existing RFC's? Sheesh! I did not "PRA" 
> for this! :-)

I don't know why the USPTO does such a lousy job, but it is a fact
that it does, there have been something like 100 patents filed by
third parties on my own work, the applications being made long after
publication and in many cases referencing the work. Defending against
these bogus claims can cost millions.

---

From: "John Glube" <[email-masked]>
Date: Fri, 16 Jul 2004 14:42:11 -0400

From: [email-masked]
[mailto:[email-masked]] On Behalf Of
Hallam-Baker, Phillip
Sent: July 16, 2004 12:58 PM
To: 'Chuck Mead'; [email-masked]
Subject: RE: Licensing issues

"> You corporate guys appear to have bunched together in a group
and *DO NOT* appear to want to *HEAR* what the non-corporates
think!

It is very clear that none of the people raising objections in
this thread have bothered to read the archives of this mailing
list.

The issue was raised, we are waiting for clarification from the
lawyers. 

Accusing Microsoft of bad faith less than 48 hours after the
request for clarification is made does not appear to me to be a
good faith complaint."

In my post, I made the following concluding remarks:

"Having said all of this, I gather from posts made to this
list and others that a good faith effort is being made to resolve
these issues. Hopefully the questions and genuine concerns being
raised will become moot and the working group can propose a base
standard which best suits the desired objectives within the
stated time frame."

Therefore to make the statement you made about people not being
aware of the situation, or of accusing one party or the other of
bad faith is not correct.

I trust we all can remember the old adage "Honey attracts more
flies than vinegar."

John Glube
Toronto, Canada

The FTC Calls For One Standard For Sender Authentication
http://www.learnsteps4profit.com/dne.html

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.718 / Virus Database: 474 - Release Date: 09/07/2004

---

From: wayne <[email-masked]>
Date: Fri, 16 Jul 2004 22:04:11 -0500

> thread have bothered to read the archives of this mailing list.

PHB:  That's not true and darn well you know it.

> The issue was raised, we are waiting for clarification from the lawyers. 

Yes, we are waiting, and waiting, and waiting some more and we are now
into the "working group last call month".

> for clarification is made does not appear to me to be a good faith

I have no idea where this "48 hours" thing came from.  Concerns have
been expressed about the MS Caller-ID license for months.  At the
Interim meeting in May (that would be about 8 weeks ago) when the
merged SPF/Caller-ID proposal was made, the subject of the license was
brought up and Jim Lyon said that he would make sure that it would be
OK with Open Source mailers.  It is my understanding that some lawyer
contacts were made in early June (6 weeks ago).  I raised the issue
very directly on this mailing list two (2) weeks ago with my original
"Obstacles" post.

While there may be stuff happening behind the scenes that I'm not
privy to, there has been *ZERO* movement in public in the several
months that this has been a known issue.

OK, we have very little time left before the IETF-60.  I think it is
very reasonable to assume that if nothing has happened in the last 8
weeks, that nothing will happen in the next 2 weeks and the Caller-ID
license is what we are going to get stuck with.

Now, maybe MicroSoft thought that the lack of posting on the subject
meant that there was a rough consensus that the license wasn't an
issue.  Maybe the MicroSoft lawyers aren't willing to budge at all.
Maybe this is all part of the Illuminati and trilateral commission's
plot to take over the world.  I don't know, and, to be quite honest, I
don't care.

The fact is that over the last week or so, no one has suggested that
it is acceptable to have a license for the Sender-ID IPR that would be
burdensome to GPLed or other open source MTAs/Spamfilters.  Many
people have said that the RFC that this work group puts forward should
have no licensing requirements at all.

There is a clear rough consensus that the current Caller-ID license is
not acceptable.

I'm sorry if MicroSoft has wasted many weeks by not addressing the
issue.  I'm sorry if we are now in a crunch period.  That doesn't
change anything though.

If the Sender-ID licensing can't be resolved in a matter of days
(maybe a week), I think this working group MUST drop the PRA algorithm
and go forward with another proposal.

Or, is it the position of the co-chairs that we are not going to have
a working group last call this month?

-wayne

---

From: Michel Bouissou <[email-masked]>
Date: Sat, 17 Jul 2004 09:45:00 +0200

> and go forward with another proposal.

+1

-- 
Michel Bouissou <[email-masked]> OpenPGP ID 0xDDE8AC6E

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 17 Jul 2004 04:42:36 -0400

----- Original Message ----- 
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Chuck Mead'" <[email-masked]>; <[email-masked]>
Sent: Friday, July 16, 2004 12:57 PM
Subject: RE: Licensing issues

> for clarification is made does not appear to me to be a good faith

In regards to myself, where I was chastised for my what I deem valid
concerns, I wish to clarify that my critical concern is that the "MARID"
solution is being molded that is not ideal for world wide consideration and
it is based on borrowed concepts that make it extremely touchy from top to
bottom.

In my opinion the scope of MARID has been lost, and regardless of how
relaxed Microsoft licensing position will be,  I firmly believed it is
baseless and doesn't belong in what should be an sound technical MARID
framework.

Just consider this:

The Microsoft "MARID Model" for flawed and weak. Therefore,  there will be a
high propensity for a better "mouse trap" invention.   Will a weak Microsoft
model prevent new better discoveries?  If so how?  You don't patent just one
thing. You encapsulated with other concepts.  That is the problem: the other
concepts are all prior art.   In other words:

        2821+ DNS+2822  = SenderID patent

The ingredients are all prior art.  The patent guidelines specifically says
the "obvious" environment elements can not be used to stop new inventions.
MS must throw in something unique.  The patent protects the usage of the
same unique element.  That's it!

So what is unique here?  Nothing, it was cloned from SPF.

This is what makes it so crazy. The only thing that can make it unique is
the absence of a non-existence concept:

        2821+ DNS+MISSING SUBMITTER+2822  = SenderID patent

In other words, systems that don't support submitter or are not aware of it
and use POST SMTP validation might fall under the MS SenderID IP claim.

The problem is that the better "Mouse Trap" might be invented:

        2821+ DNS+MISSING SUBMITTER+2822  = Better Mouse Trap

that is based to work on a concept that isn't event a standard!!  A missing
non-existing element?

Is the better Mouse Trap limited to 2821 only?

Look, either way, the very fact it is even issue now makes this current
MARID model smell bad.

We have a unique opportunity here that doesn't come around too many times in
a life time, specially in the short history of online data communications.
We can't afford a questionable or weak solution plagued with many technical,
social, political, legal, international, administrative, adoption and
deployment issues. One that is so flawed technically, there will be a need
for a better Mouse Trap.

We need a MARID Framework that is:

    - 100% Open Standard for world wide fast deployment,
    - Maximizes solving the target problem of spoofers,
    - Maximizes Backward compatibility,
    - Offers a smooth transition,
    - Minimal redesign cost with SMTP software vendors,
    - Minimal Implementation cost,
    - Minimal affect on Network bandwidth,
    - Offers opportunities for a better "Mouse Trap,"
    - Yet still allows the inventor to protect his IP,
    - But independent on the MARID framework.

In other words, the new MARID framework is this:

    2821 + DNS + 2822 + METHOD = Final MARID Authentication Result

I have such a FRAMEWORK.

The Framework and Final Result is not patentable because I will specifically
say it is PUBLIC DOMAIN.

The METHOD may be patentable, but the FRAMEWORK is not and the patentee can
not use the FRAMEWORK as encapsulated ingredients to stop new methods based
on the new MARID framework.

This allows for the best "Mouse Trap" to be invented.  Let the better Mouse
Trap win!

I am putting multiple drafts right now that will keep in scope yet provides
exactly what the world is looking for.  I don't care if no one likes it. I
am tired of what I am experiencing here that will have a major impact on my
company and livelihood.  At the very minimum, I must publish them in a
public forum to stop any future IP claim.

The framework will throw a monkey wrench in the any Microsoft SENDERID
claim.  Sure, they can certainly file it. The 1996 USPTO patentability
guidelines were relaxed to allow for baseless prior art claims. It doesn't
mean it is valid. However, a patent greatest strength is not stopping others
from doing the same thing,  but as a tool to put the burden on others to
disprove it.

We must not allow any future standard of the internet mail system begin with
flawed, costly and problematic concerns.

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Michel Bouissou <[email-masked]>
Date: Sat, 17 Jul 2004 14:14:59 +0200

Le samedi 17 Juillet 2004 10:42, Hector Santos a écrit :
>
> I wish to clarify that my critical concern is that the "MARID"
> solution is being molded that is not ideal for world wide consideration 
[...]

I share this opinion.

I've been reviewing MARID drafts and discussions, and came to the conclusion 
that the current direction it takes makes little sense IMHO.

If we want the protocols/standards defined by MARID to be successful and 
useful, they must be widely and quickly acceptable by the whole Internet 
community, prove efficient, and be easy to implement and use on a purely 
technical standpoint.

email forgery is a hot issue that needs to be addressed with protocols that 
mail administrators will be able, and willing to implement and deploy in a 
relatively short timeframe, and not 3 years from now (if ever).

IMHO, all the 2822 and PRA stuff doesn't fit with this goal.

The 2822/PRA algorithm is rather complex and will probably raise 
implementation issues in many MTAs that currently don't have much provisions 
for message contents processing, and possible message rejection _after_ 
message DATA have been received and processed.

OTOH, 2821 processing such as SPF is easier to implement, all MTAs being 
designed for acting upon message envelope contents. There are already a 
number of MTA implementations of 2821/SPF, either by the means of MTA patches 
asociated with an SPF library, or by external "plugin" modules. All this 
already exists and has real-world implementations that prove satisfactory.
Such implementations could be easily extended to include more 2821 tests that 
MARID could define, such as HELO validation.

I believe that the present email RFCs have very wisely separated transmission 
protocol and message envelopes (RFC2821) from actual message contents 
(RFC2822), the former being the actual MTA business, and the later, message 
contents, being rather MDA / MUA / user application layer business.

I believe that trying to incorporate a bunch of 2822 processing into MTAs for 
implementing PRA would _not_ be a good direction to take, as this basically 
is not MTA's business.

Also, if we consider efficiency / bandwidth issues, it is much better to 
reject a message before its DATA has been received (by 2821 processing), 
rather than having to receive the entire message, perform 2822 PRA 
processing, then possibly reject it (or worse, bounce it back).

If we now consider the issues of the "side effects" of these protocols, we 
know what 2821/SPF breaks : it breaks forwarding, but this can be solved by 
the already-designed SRS solution, which already has some implementations 
beginning to become available, or that will be shortly. And this is MTA-level 
implementation and business, it doesn't need any further changes to 
application or user-level software .

If we consider 2822/PRA, we notice that it relies on supplementary message 
headers (i.e. Resent-From:, Sender: ), that most email systems currently do 
not add when performing simple alias or ".forward" forwarding, or user-level 
forwarding, and that a number of mailing-lists systems (for example, SYMPA 
[http://www.sympa.org], which I happen to use) do not currently add nor 
manage.
2822/PRA draft even discusses modification to M.U.A. software for displaying 
fields that are used for PRA computations.

Well, folks, I believe that such adaptation of all forwarding systems, 
mailing-list software, MDAs and the like will not be widely deployed in the 
"real world" before years, if ever.

Furthermore, I think that a wide deployment of 2822/PRA would uncover a number 
of yet unforeseen issues, and that all this seriously lacks large-scale 
testing for now.

SPF already has received a very strong support from the real-world sysadmins 
community : http://spftools.infinitepenguins.net/register.php already knows 
more than 21,300 domains that actually have published SPF records (and 
counting), and some people estimate that the actual figure would rather be 
around 100,000 (even though I don't know on which basis this estimation 
relies).

This is a massive vote for the SPF technology, and shows that a massive number 
of real-world sysadmins estimate that this SPF technology is both useful and 
easy enough implementing, without breaking too much of their existing mail 
setup.

On the other hand, about 2822/PRA, we only have a big question mark.

Taking all of these points into consideration, I believe that MARID should 
seriously reconsider the direction to be taken.

My own preference would be that MARID defines as a standard (in a first time) 
the current implementation of SPF, with some possible improvements such as 
HELO verification, but remaining strictly 2821. And accompany this with the 
standardization of SRS, that solves the forwarding issues.

That would give a "2821 MARID RFC" that could be rather quickly deployed in 
the real world and show its benefits against mail forgery.

As a second step, later on, we could consider if "what remains of email 
forgery once SPF is widely deployed" deserves that an additional 2822 
standard should be devised, or not.

If it happens that pure 2821/SPF is able to block 98% of email forgeries, 
zombie spam and virus problems, then I think that MARID would have 
brilliantly reached its goals, and no further protocol is necessary.

If it shows that, alas, 2821/SPF is not sufficient to solve enough of the 
problem, then it will be necessary to consider another 2822-based protocol.

But I think that anyway, the priority for now is validating a 2821 protocol, 
and, maybe in the future, if a 2822 protocol shows necessary, it should be 
kept separate from the 2821, just as RFC2821 and RFC2822 are separate.

These were just my 2 cents...

Regards.

---

From: Michael Weiner <[email-masked]>
Date: Sat, 17 Jul 2004 09:15:58 -0400

> kept separate from the 2821, just as RFC2821 and RFC2822 are separate.

I wholeheartedly agree with you here, and honestly i dont think anyone
has yet stated it in quite this way (except possibly Chuck Mead).

I believe you are correct in your line of thinking, and as an MTA
admin for a number of large mailing domains, that would be my "vote"
as well, to keep MARID out of the MUA business and stick to what is in
implementation now and WORKS.

I have see a few proposals from peers to the SES perspective that
helps the forwarding issue, but i dont see that currently on the table
in the MARID discussions. I personally would like to see the new-SES
proposals as part of the SPFv1-classic stuff, as i believe this adds
strength to the implementation.

MARID, i believe, should go down the road of SPF/SRS as that is the
current WORKING "implementation" and we have real data to prove that
this first step on the road map actually does do some what it was
intended to accomplish, is easy to implement, and doesnt add heavily
to any bandwidth issues that i am aware of. And i also believe alot of
the stuff people want to see in the MARID proposal/standard is nothing
more than feature-creep which i believe is what is holding SOME people
back from implementing even the first part of the road map - SPFv1.

Michael Weiner