Subject: RE: Alternatives drafts for SUBMITTER identity

From: "Jim Lyon" <[email-masked]>
Date: Mon, 27 Sep 2004 15:51:36 -0700

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.

-- Jim Lyon

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 27 Sep 2004 17:10:37 -0700 (PDT)

> 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-masked]
Anti-Spam and Email Security Research Worksite:
 http://www.elan.net/~william/emailsecurity/

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 27 Sep 2004 20:55:58 -0400

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

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 27 Sep 2004 18:45:41 -0700 (PDT)

> level of credence.  In my view, this plays into the favor of the patentee.
How so?

I took the draft that Microsoft has no IPR claims on (since Microsoft 
person was co-author, if it was not so, he would have had to file IPR 
document in regards to that draft). However that draft in itself was 
referencing as requirement another draft (PRA) that had known IPR issues.

I removed the requirement of Submitter identity being the same as
patent-encumbered PRA identity and made SUBMITTER to be purely RFC2821 
identity on part with ReturnPath. Situation is such that Microsoft can 
not claim have patent  claims on this draft unless it is at the same time 
willing to put claims on SPF (which as you say they will not be able to do).

So the result is that we have subpart of SenderID that:
 1. Provides information about entity that was last involved 
    in reintroduction of message into transport stream. This
    is what many wanted.
 2. Does not require checking RFC2822 headers to find this identity.
 3. Does not require forwarders to add new headers in a way that is
    not compatible with RFC2822
 5. Can be implemented by every MTA no matter if they can use GNU
    license or commercial license for their product

This is not in conflict with Microsoft SenderID concept as that can
be easily build upon it by requirying finding PRA identity from 
headers to be the same as SUBMITTER identity. To make certain that
is what publisher wanted to be checked it is easily possible to do
it by means of SPF policy records which do use different scope. 

I note that, as indicated in another post, I made best effort to take
concepts of SenderID that did not have any major technical or IPR issues.
I believe this allows the concept to be implemented worldwide while if
that is not done, we'd have situation that Responsible Submitter identity 
would not be provided by majority of MTA servers.

What I have done should in fact greatly help Microsoft itself by allowing
Responsible Submitter identity to be present and certainly determined in a 
lot more cases then what it otherwise would have been.

---