ietf-mxcomp
[Top] [All Lists]

Re: FW: on the topic of IPR

2004-08-30 10:16:47

On Fri, 2004-08-27 at 09:27, Michael R. Brumm wrote:
Kevin Peuhkurinen wrote:
It makes no sense to say "here we have some verifiably homegrown IP
with no encumberances and here we have some encumbered IP.   Let's use
the encumbered IP rather than the unencumbered IP because otherwise we
might get sued by parties unknown".

Andrew Newton wrote:
Is there a connection between "verifiably homegrown" and patent claims?

You are correct that the parties are unknown.  If this were an arcane
subject area, it is most likely that they would remain unknown and
probably non-existent.  However e-mail and electronic messaging and
anti-spam are hot areas of intellectual property.  I did take a stroll
through the USPTO database and there are numerous, numerous patents in
this area.  And these do not include the pending patents that cannot be
seen.

Also, if company XYZ came forward tomorrow and claimed covering IPR,
should we ignore them?

Ok, so now we have the *FEAR* of existing patents, the *UNCERTAINTY* of
future patents, and the *DOUBT* that the IETF and free/open source
communities could defend against the possible onslaught of submarine
patents.

<sarcasm>
Sounds to me like a good reason to go with Microsoft. We all know they have
our best welfare at heart, and they will protect us against this FUD.
</sarcasm>

We have at least one technology (SPF) which is in the public domain, is
superior at solving the problem this working group was chartered to solve,
and is widely deployed and tested on all the major MTAs.

So, why are we spinning our wheels with an privately owned IP which is
encumbered by an onerous license, doesn't appear to solve the problem, and
has never been deployed or tested on any MTA?

While I agree with this statement, I would also like to add there can be
several improvements made to SPF.  

1) The number of required lookups for describing the mail as being sent
   from disparately administered domains be confined to a single record.

2) Determine an identity without assumptions of the integrity of the
   mail channel upon which to establish defensible reputation services.

3) For sensitive mail, allow guarantees of the source of RFC2822 From.

4) Mark the mail channel list as restrictive or normative, but do not
   also use the list for the double purpose of authenticating the MTA,
   as this makes normative lists prone to being exploited.

The single lookup becomes possible when, rather than using IP addresses
to describe the permitted senders, authenticated names are used.  This
becomes another major bonus, as these authenticated names provides the
certainty need for reputation services or enforcement.  This then safely
moves this effort into the realm of using names rather than addresses. 
By applying flags to indicate what mailbox fields this list restricts,
both the MAIL FROM and From can be defended from spoofing.  Leaving the
list as being normative does not enable spam exploits made possible with
"open-ended" authentication lists where the list is dual purposed, as
with SPF.

Yes, this becomes a two step process.  Authenticate and authorize the
MTA, and then add mail restrictions as desired.  Authenticating and
authorizing the MTA does not add to the number of DNS record lookups! 
But by being able to use names, delegating the sending of mail to other
domains becomes a simple matter of specifying a name.  Because mail
restrictions are not part of the MTA authentication, they can be applied
as needed.  Because IP addresses are not used to define the permitted
mail channel, there is no need to do subsequent DNS lookups to find
these addresses.

These lists can provide the normative mail channel used for the domain,
in much the same manner an "open-end" list would have allowed.  In the
exceptional case, for superior protection from spoofing the From for
financial institutions as example, a restriction on a header can be
made, but this option does not burden normal mail use, as it does for
SPF or Sender-ID.  In addition, because these restrictions are not based
upon the presents of other RFC2822 headers, this avoids the troubling
IPR problem.  If you want your From to only come from specific servers,
this can be established.  Sender-ID can never claim this ability.

The forwarding problem created by going from a normative to restrictive
list on the From header can be helped with public MAIL FROM signatures
now being considered, that also locks the back-door left wide-open with
Sender-ID.

-Doug


 

 


<Prev in Thread] Current Thread [Next in Thread>