Re: Alternatives drafts for SUBMITTER identity

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" <[email protected]>
To: "Jim Lyon" <[email protected]>
Cc: <[email protected]>; <[email protected]>
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: [email protected]
> Anti-Spam and Email Security Research Worksite:
>  http://www.elan.net/~william/emailsecurity/
>
>