Subject: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID support in Courier)

From: "Anne P. Mitchell, Esq." <[email-masked]>
Date: Mon, 30 Aug 2004 11:04:37 -0700

Andrew Newton wrote:

> 4) You have stated above that you believe Microsoft's claim is 
> "nebulous" with regard to rights being claimed. Your release notes 
> state "Implemented Sender Policy Framework checking on the From: 
> header. Be sure to read the documentation and understand the 
> implication." Since checking of the From: header is listed in the -pra 
> document, are you concluding that this is not encumbered by 
> Microsoft's claim? If so, how did you come to this conclusion?
>

This brings up a point which has been rolling around in the back of my 
head for a few days.

We simply _don't_ know what is in the claim.  In any other area where 
adoption of some program is to be impacted or encumbered in some way 
which could cause either a legal liability or an inability to actually 
implement on the part of the adopter - particularly such a potentially 
widely used program - it is inconceivable that people would be even 
considering adopting, or recommending, the program.  In fact, if one 
had a professional license, and recommended adoption of such a program 
without a clear understanding of the encumberance, one could be guilty 
of malpractice.  But I digress...what has been rolling around in the 
back of my head is this:

Can anyone say with 100% certainty that there is *zero* technology, 
software, or process, which can be reasonably argued by Microsoft to 
belong to them, with regards to *checking*?   Bear in mind that I have 
some experience in patenting this sort of technology (I have been 
involved in the patent work on the Habeas "technology", among others, 
and I put that word in quotes because if you look at the Habeas model 
I'm guessing many of you would be shocked to realize just how much *is* 
patentable as "technology").

Ok, I'm going to guess that some of you  might say "yes" to the above.  
So, let's put it another way now:

Is the method for checking under Sender I.D. *identical* to the method 
for checking for SPF?

Imagine a world where some day you have to pay for a site license to be 
able to perform a check.  Where the only receiver who *doesn't* have to 
pay to perform checks is Microsoft itself.

Again, this is not Microsoft bashing - I personally believe that *any* 
large receiver owning the ultimate rights to an authentication system 
is a conflict of interest.

And to be honest, for the life of me, I don't understand why SPF, which 
already had a lot of support from other corners, isn't what's being 
pushed now.  Although, of course, for all we know (and I very much 
suspect) SPF is probably now in some way encumbered by MS anyways.  It 
would be foolish of them to embrace and incorporate SPF technology 
without first making sure that they darned well owned it.  Just like 
any other acquisition - you can either put the competitor under, or 
acquire them.

Anne

---

From: "David H. Lynch Jr." <[email-masked]>
Date: Mon, 30 Aug 2004 23:01:38 -0400

> of malpractice.  But I digress...what has been rolling around in the 

       Regardless of whether software should be patentable (or business 
methods, or ...) and regardless of the fact that trivial "improvements" 
should not be patentable no matter what. We live in a world where they are.

    Aparently we have no idea what parts of the current draft Microsoft 
thinks they have an IP claim on. While that is slightly scary from a 
practical perspective despite aparent IETF policies othewise, I think 
that must mean that Microsoft's claim and their proposed license should 
be given little weight. They are only slightly more significant that the 
possibility that some other entity also has IPR claims against parts of 
the current draft and has not come forward.

Certainly there is much to fear, but fearing the mostly unknow is not 
significantly different from fearing the totally unknown, and almost 
equally pointless.

While I would personally prefer that MARID adopt classic SPF and move 
forward - regardless of other merits it might have Caller-ID is 
Microsoft's baby and I personally beleive that if they truly wish to 
participate in the standards process they need to be open about their 
IPR. They can insist on whatever license they wish and the MARID group 
can decide if that is acceptable AFTER knowing what it is that is being 
licensed. I understand that may not be the policy of the IETF - though I 
beleive it should be. We are discussing changes to a core internet 
technology. I am not personally aware of any internet core technology 
that is encumbered in the way Microsoft is looking to encumber Sender-ID.

    I would advocate for moving forward with Classic SPF, because 
although I beleive that whatever Microsoft's IP that it is not likely to 
stand up to rigorous scrutiny, nor do I think it would be politically 
wise from Microsoft to force the issue - Microsoft has a reputation for 
being aggressively litigous in defense, but with few exceptions it has 
not really been offensively litigous. However I do not beleive the FOSS 
comunity would deploy Sender-ID if a patent did finally materialize, 
until that patent was nullified and that could take alot of valuable 
time. I beleive the FOSS community and a significant portion of the 
comercial SMTP comunity would deploy Classic SPF - even in the face of a 
possible Microsoft patent threat, it is easier and clearer to argue that 
SPF is prior art. There is also a moral and ethical difference, between 
going forward with SPF and going forward with Sender-ID in the face of a 
possible claim from Microsoft. Regardless of the validity of Microsoft's 
patent claim a fight over SPF would be fighting with Microsoft for 
trying to patent what somebody else developed. Fighting over Sender-IP 
would appear more like trying to steal something from Microsoft.

    I would love to see a result that included everyone. Sender-ID, with 
Microsoft on board, and FOSS on board would likely be the most effective 
solution. But the FOSS comunity is not going to sacrifice core 
principles for that and thus far it appears that Microsoft has drawn 
their line in the sand too. Absent Microsoft putting forth a License 
that is compatible with FOSS licenses, or just contributing their IPR 
freely, I think Sender-ID should die here. That is a bad choice - just 
better than the rest.

    I would rather no standard than one that is "owned" by anyone no 
matter how good the terms of ownership.
    Being forced to choose who to exclude I would choose to exclude 
Microsoft before excluding the FOSS community. Though success without 
both is questionable.

    While I personally beleive there is a public value served by killing 
any patent and a high public value for killing stupid patents, there are 
other institutions that serve that purpose. While I think many of the 
IETF's policies on IPR are poor,  in this particular instance wide and 
quick acceptance is critical and the more IPR issues there are the 
longer that will take.

---

From: wayne <[email-masked]>
Date: Tue, 31 Aug 2004 10:26:18 -0500

In <[email-masked]> "Anne P. Mitchell, Esq." <[email-masked]> writes:

> belong to them, with regards to *checking*? [...]

IANAL and I feel a little nervous providing answers to a lawyer, but
here it goes anway.

I believe that MS's claims do not cover the marid-protocol draft,
which is basically SPF checks, with only the identity used by SPF
removed.

First off, this question was explicitly asked at the IETF-60
MARID session and the answer that Harry Katz gave was that the patents
applied to only marid-core.  (marid-core has since been broken into
two I-Ds, both of which have the MS IPR claim.)

See the timestamp around 17:25.  psa was the jabber scribe. 
http://www.xmpp.org/ietf-logs/[email-masked]/2004-08-04.html

Audio archives of this session are also, so if you poke around to find
the right spot, you can hear Harry's answers directly.

Secondly, by participating in the MARID mailing list, you are required
to read the "NOTE WELL" IETF information (see
http://www.ietf.org/NOTEWELL.html ).  This refers you to RFC3667 and
RFC3668.  In RFC3667 section 5.1, says that people who submit I-Ds
must disclose IPR claims, although it is not clear tome if this means
for all I-Ds that they know of, or only the one that they are
submitting.  RFC3668 section 6 is much clear and explicitly says that
you must disclose IPR that you know of that are contributed by
others.  See: http://www.ietf.org/rfc/rfc3668.txt

Since MS has not give such notices on the marid-protocl I-D, I am 99%
certain that MS is not claiming any IPR on it.

*PLEASE* correct me if I'm wrong.

> Is the method for checking under Sender I.D. *identical* to the method

Well, there have been some changes in the marid-protocol spec compared
with earlier SPF specs, but they are pretty minor.   (e.g.,
marid-protocl uses a different version string.)  So, I think for all
practical purposes, the answer is "yes".

> And to be honest, for the life of me, I don't understand why SPF,
> which already had a lot of support from other corners, isn't what's
> being pushed now.

The two main claimed reasons for using the PRA algorithm in the merged
SPF and CallerID proposals are:

1) The PRA "protects what users see, e.g. the From: header".  (Never
   mind that the PRA really just protects the Resent-Sender: header
   which almost no one sees.)

2) Using the PRA makes it easier for mail forwarders to comply.
   (Never mind that support for mail forwarders on many open source
   MTAs has been around for a fair while now.  OTOH, I know of *no*
   support for forwarders to add the headers required for the PRA.
   Even the just announced milter from Sendmail doesn't appear have
   the required support.)

While those are the claimed reasons, I think it is quite clear from
talking to quite a few people involved with this working group that
the REAL reason is:

* People want MS on board because it would *really* help deployment
  and MS *really* wants their PRA algorithm.

-wayne

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 31 Aug 2004 17:45:34 +0200

On Mon, Aug 30, 2004 at 11:04:37AM -0700, Anne P. Mitchell, Esq. wrote:
> of malpractice.

IANAL and not even a native english speaker. What really puzzles me is
the term "perpetual" in the license and the meaning. My dictionary has
some possibilities like
    eternal
but also
    for an unlimited period
The first would be not too big a problem, the second would be an immense
problem as MS could in one year from now terminate the existing license
contracts and formulate a new one with a fee, right?

	\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: Markus Stumpf <[email-masked]>
Date: Tue, 31 Aug 2004 18:22:56 +0200

>   and MS *really* wants their PRA algorithm.

Why will that help deployment?
The latest surveys state that MS SMTP servers have less than 10%
market share.
I'd say having sendmail + qmail + postfix + exim will help more than
having MS on board for whatever solution.

	\Maex

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 31 Aug 2004 12:27:03 -0400

> the right spot, you can hear Harry's answers directly.

To play devil's advocate, it really doesn't matter what he said until we 
see it in writing from Microsoft's lawyers.

> *PLEASE* correct me if I'm wrong.

Lets add to that that the note well information may apply to list 
postings, including the ASRG list which is hosted at ietf.org, and you 
got yourself a can of legal worms. To my knowledge, Microsoft employees 
have never disclosed any potential IPR information on the ASRG list 
unlike what Phil Hallam-Baker and others have done.

>   and MS *really* wants their PRA algorithm.

It is also interesting to note that the protection of the "From:" header 
has been discussed at least a year and a half ago on the ASRG list here:
http://www1.ietf.org/mail-archive/web/asrg/current/msg04390.html

The use of XML for storing RMX records was first proposed on the ASRG 
list here:
http://www1.ietf.org/mail-archive/web/asrg/current/msg04302.html

I wonder how the IETF's IPR policy in the "note well" text applies here.

Yakov

---

From: Paul Iadonisi <[email-masked]>
Date: Tue, 31 Aug 2004 12:49:29 -0400

> having MS on board for whatever solution.

  I made this point a while ago on the spf-discuss list.  While it would
be nice to have Microsoft on board, they do *not* have the lion's share
of the installed base of internet facing SMTP servers.  That's where
most of implementation of these standards will take place.
  I would be quite disappointing if this draft was pushed through with
the current patent license because someone thought 'we need Microsoft'. 
Even if we did, shunning this license does not have to mean pushing
Microsoft out, so to me, it would make no sense to push this through
just because someone thinks we need Microsoft.

-- 
-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: Yakov Shafranovich <[email-masked]>
Date: Tue, 31 Aug 2004 13:58:11 -0400

> just because someone thinks we need Microsoft.

We had this argument in the ASRG as well until some pointed out that the 
PRA algorithm works in MUA. The market share on Microsoft MUAs is over 70%.

Yakov

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 31 Aug 2004 20:00:51 +0200

> having MS on board for whatever solution.

I was asked if I could provide some URLs:
Here are links to some recent surveys:
    http://cr.yp.to/surveys/smtpsoftware6.txt
    http://www.falkotimme.com/projects/survey_smtp_032004.php
    http://www.tty1.net/smtp-survey/survey-2004-03-04_de.html
    http://www.ornl.gov/lists/mailing-lists/qmail/2003/11/msg00245.html

Numbers differ in detail but the overall figures are the same.
What is also important is the number of users served by the the
different MTAs and I know from scratch of no large provider using
MS SMTP server, but I may be wrong.

        \Maex

---

From: <[email-masked]>
Date: Tue, 31 Aug 2004 14:26:37 -0400

But by the time the email gets to the MUA its TOO LATE.  Client machines cannot do an SMTP reject.

But SPF classic requires *zero* changes to the MUA, its just the MTA that is enhanced.

This is especially true if one of the goals is to preserve MTA to MUA bandwidth nad/or clutter of
bad emails at MUA.

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 Yakov Shafranovich
> Sent: Tuesday, August 31, 2004 1:58 PM
> To: Paul Iadonisi
> Cc: IETF MARID WG
> Subject: Re: Unencumbered Checking (was Re: DEPLOY: SPF/Sender ID
> supportin Courier)
>
>
>
> Paul Iadonisi wrote:
>

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 31 Aug 2004 14:33:02 -0400

Note the list arguments about silently swallowing emails and then think 
why these arguments are relevant (hint: swallowing email on MUA level).

It is clear to me from the entire Sender-ID development from its roots 
in the ASRG, as well as the information I heard directly from Microsoft 
employees on the subject, is that the Sender-ID standard is intended to 
be deployed on the MUA level by Microsoft. Of course, they are free to 
correct me.

Yakov

[email-masked] wrote:
>>>  I made this point a while ago on the spf-discuss list.
>>
>>While it would
>>
>>>be nice to have Microsoft on board, they do *not* have the
>>
>>lion's share
>>
>>>  I would be quite disappointing if this draft was pushed
>>
>>through with
>>
>>>the current patent license because someone thought 'we need
>>
>>Microsoft'.
>>

---

From: Graham Murray <[email-masked]>
Date: Tue, 31 Aug 2004 20:18:56 +0100

> be deployed on the MUA level by Microsoft. Of course, they are free to 

But should that concern us in this working group? Should we not be
investigating and recommending the best solution for implementing in
the MTA (as per the name and charter of this group)? We should be
concerned about what may or may not be done or implemented in MUAs.

---

From: Graham Murray <[email-masked]>
Date: Tue, 31 Aug 2004 21:01:48 +0100

Graham Murray <[email-masked]> writes:

> We should be concerned about what may or may not be done or
> implemented in MUAs.

Oooops That should say "We should not be concerned....."
                                  ^^^

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 31 Aug 2004 16:51:21 -0400

> Oooops That should say "We should not be concerned....."

There are many instances were the check will be done after the SMTP 
transaction. SpamAssassin is an obvious example.

Plus, the MUA checking is what makes this valuable against phishing.

Yakov

---

From: Markus Stumpf <[email-masked]>
Date: Tue, 31 Aug 2004 23:15:28 +0200

> Oooops That should say "We should not be concerned....."

I have raised this and I have also raised more than once concerns that
there are zillions of MUAs in intranets and behind firewalls that cannot
do DNS lookups themselfes. But I was told this is then a job for
"special gateways" and "solution" would be to add headers for evaluation
by the MUAs that would be removed for security reasons at the receiving
MTA for incoming eMails.

Funny thing is that
    http://weblog.infoworld.com/udell/2004/03/23.html
clearly shows MUAs and the user interface (and the users behind) are
simply to dumb to get things halfway right ... and SenderId will not
change a thing with that regard.

	\Maex

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 31 Aug 2004 14:28:02 -0700 (PDT)

> be deployed on the MUA level by Microsoft. Of course, they are free to 

SenderID can not reliably be used at MUA level and in my opinion should 
not be used there. See my long object on this very topic at:
 http://www.imc.org/ietf-mxcomp/mail-archive/msg03769.html
This was however discussed more at spf-discuss, my arguments there are:
 http://archives.listbox.com/[email-masked]/200408/1237.html
 http://archives.listbox.com/[email-masked]/200408/1255.html
Unless I'm mistaken the same arguments were expressed before by others too 
but I only have copies of my own posts to find them in archive.

My recomendation for MUA support is to require MTAs that do MARID record 
checks to add special received header (or specified fields in normal
received header) and for MUAs to look for this header and if it is the
one from the top-most Received header only then can MUA show to the
user that certain from address is MARID verified, in such received
header should already contain PRA address, which is the one MUA can show
to the user (this is not to say MUA can't show other address that are 
typically involved in PRA to the user, but that is optional and carries
no assurances that those addressed were ever checked). 

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: <[email-masked]>
Date: Tue, 31 Aug 2004 20:33:36 -0400

> Sent: Tuesday, August 31, 2004 4:51 PM
> To: Graham Murray
> Cc: [email-masked]
> Subject: Re: Unencumbered Checking
>
<snip>
> Plus, the MUA checking is what makes this valuable against phishing.
Why?

If the email is rejected before being written to users mail spool files, it still doesn't get to the
MUA.  But rejecting at the MTA also saves bandwidth etc.

So why isn't checking at the MTA valuable against phishing?

Terry Fielder

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 31 Aug 2004 20:41:00 -0400

> So why isn't checking at the MTA valuable against phishing?

Let me more clear - it can in theory be used as a check on the MUA level 
or past MTA for phishing in those cases where the underlying MTA does 
not support Sender-ID yet but the MUA or a filter running behind the MTA 
does. Obviously it is better to reject stuff at MTA level. Another 
possibility is when the MTA doesn't reject it out right btt assigns a score.

Of course this is in theory, take a look at William Leibzon's earlier 
reply to this of why this is might not feasible.

Yakov