William,
I agree with Jim from the standpoint there is a conflict here in regards to
"protesting" a patent application, yet at the same time, giving it some
level of credence. In my view, this plays into the favor of the patentee.
I should note that I don't believe there is a claim to be made to restrict
the usage of the ESMTP return path modifier, hence for this reason and many
other similar reasons along the same line, the patent applications have
little to no enforcement quality. It really doesn't any deserve any more
attention that it already got.
I should also note MS simply has no say over SPF. As a early implementer of
SPF in our commercial mail products, rest assured that legal and IP issues
were fully examined before SPF were considered at the time, which was
clearly before any MS introduction into the picture. The legal facts are
such; SPF, which is based on prior art itself, was introduced in early
2003, making it not eligible for patentability today, and therefore can not
be claimed by anyone also with current applications. Rest assured, if this
was not the case, and indeed MS does have a claim to SPF, it would be PULLED
immediately from our product line and we would investigate the legal avenue
to recoup the lost of development and engineering cost put into it over the
last year. This is why I am fully confident there is nothing to worry
about here as far as SPF.
With that said, if an alternative is being pursued, don't approach it with
a MS angle Approach it from the standpoint of SMTP purity and basic
operations. These are elements that are natural to all parties, with
standard and/or BCP in place. This is what needs to be part of any protest
information provided to the patent examiner. It will help him examine the
Muskush-type claims of these applications to see that there is a community
between all claims that without these common elements, not only will the
patent process will not work, but the industry will fail to function as
well.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
----- Original Message -----
From: "william(at)elan.net" <william(_at_)elan(_dot_)net>
To: "Jim Lyon" <jimlyon(_at_)exchange(_dot_)microsoft(_dot_)com>
Cc: <ietf-mxcomp(_at_)imc(_dot_)org>;
<spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, September 27, 2004 8:10 PM
Subject: RE: Alternatives drafts for SUBMITTER identity
On Mon, 27 Sep 2004, Jim Lyon wrote:
William,
Regarding draft-leibzon-responsible-submitter-00, please pick a name
other than SUBMITTER for the SMTP extension and parameter. It will be a
real mess if we have two competing documents specifying different
definitions for the same extension.
1. Its actually quite easy to make marid-submitter draft to be
compatible with my responsible-submitter draft. Major thing
that is necessary is to require double-checking on if SUBMITTER
value is same as your PRA (derived from headers) ONLY IF there
is spf2.0/pra policy record available for domain part of SUBMITTER.
In such a case, you can assume that known that on his network all
servers that use SUBMITTER also comply with Sender ID and added
whatever headers you like, where as if they published spf2.0/submit
scope records you can assume they might not have done so.
The only other issue of some importance is that in my
responsible-submitter draft, the recomendation for smtp proxy
servers (as in hotel "Guest E-Mail Service" example) is to add
Sender header where as in marid-submitter it said that Resent-From
is to be used. For all other cases I conviniently avoided specifying
what exactly are supposed to be headers added (although you'll
see a definitive recomendation about that in my next draft).
2. As per above my recomendation in regards to resolving difference
between marid-submitter and responsible-submitter is to have you
rewrite your concept to reference responsible-submitter instead
of marid-submitter. You can do it by rewriting new core+PRA
draft so that it requires checking of RFC2822 headers PRA value
only if SPF2.0/pra policy record is published. In such case you
can write also that such PRA MUST be equivalent to SUBMITTER when
it is present during SMTP session and make recomendation for MTAs
to verify SUBMITTER parameter value based on either SPF2.0/pra or
SPF2.0/submit policy record during SMTP session.
Basicly what I'm asking is for you to consider rewrite of
Sender ID concept where it references submitter-draft instead of
submitter referencing marid-core and pra. Both are equivalent
ways of doing the same concept and should be able to coexist.
3. Unless you make changes to SenderID drafts as I recommended above,
I would have absolutly no problem in giving IETF directorate and
implementors a choice between what they want to accept and use:
- an encoumbered solution that is based upon incorrect use of existing
RFC2822 concepts and has IPR requirement that does not allow to be
used in open-source SMTP servers OR
- a solution that is entirely within RFC2821 framework and does not
break existing SMTP standards and does not have patent problems
(as long as we assume that SPF classic which is also RFC2821 does
not have have similar patent issues)
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/