Subject: FW: Microsoft's Updated Statement about IPR Claimed in <draft-ietf-marid-core-03.txt> and <draft-ietf-marid-pra-00.txt> in Combination

From: "Harry Katz" <[email-masked]>
Date: Tue, 14 Sep 2004 23:24:13 -0700

Today Microsoft filed the following disclosure statement with the IETF Secretariat regarding IPR claimed in relation to Sender ID.  This statement does not mean that patents have been granted in any of the jurisdictions mentioned below, only that the patent applications themselves are due to be published shortly.  

________________________________

Subject: Microsoft's Updated Statement about IPR Claimed in <draft-ietf-marid-core-03.txt> and <draft-ietf-marid-pra-00.txt> in Combination

Microsoft is aware of the existence of US, EP; JP; CN; KR; and IN patent applications that are likely to include claims that would necessarily be infringed when implementing the combination of the specifications entitled "Purported Responsible Address in E-mail Messages", file name draft-ietf-marid-pra-00.txt, and located at the following link on August 23, 2004, url: http://www.ietf.org/internet-drafts/draft-ietf-marid-pra-00.txt and the specification entitled  "Sender ID:  Authenticating E-mail", file name: draft-ietf-marid-core-03.txt, url: http://www.ietf.org/internet-drafts/draft-ietf-marid-core-03.txt.  The patent applications are expected to be published by the respective patent offices on or around September 13, 2004. The relevant patent application information is: 

US - Title: "Reducing Unwanted And Unsolicited Electronic Messages By Preventing Connection Hijacking And Domain Spoofing", Serial no. 10/684020

EP - Title: "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages", Serial no. 04005644.2

JP - Title: "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages", Serial no. 2004-71769

CN - Title: "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages", Serial no. 200410028682.3

KR - Title: "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages", Serial no. 10-2004-16409

IN - Title: "Coordinated Reduction of Unwanted and Unsolicited Electronic Mail Messages", Serial no. 298/DEL/2004

A patent license with reasonable and non-discriminatory terms and conditions, with no fees or royalties is available at http://www.microsoft.com/mscorp/ip/standards/ or another public site that Microsoft may subsequently use to post the license.

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 15 Sep 2004 05:57:59 -0700 (PDT)

I cound not find the patent at uspto.gov, can somebody help and give direct
link or post copy of the patent text somewhere else?

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 16 Sep 2004 09:20:41 -0700 (PDT)

> Today Microsoft filed the following disclosure statement with the IETF 
> Secretariat regarding IPR claimed in relation to Sender ID.  This 
> statement does not mean that patents have been granted in any of the 
> jurisdictions mentioned below, only that the patent applications 
> themselves are due to be published shortly.  
...
> US - Title: "Reducing Unwanted And Unsolicited Electronic Messages By 
> Preventing Connection Hijacking And Domain Spoofing", Serial no. 10/684020

This patent got published today, to see it try using this url:
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=684020.APN.&OS=APN/684020&RS=APN/684020
If does not work go to http://appft1.uspto.gov/netahtml/PTO/search-bool.html
and type 684020 for Application Serial Number in field1. 

It contains a lot lot more then just things related to MARID and understanding
everything is difficult because of this "patent language", but from what
I see of the MARID specific parts, the patent does cover RFC2821 Mail-From
(which Microsoft calls "Reverse-Path" in their patent application) as 
well as RFC2822 headers and it many times mentions RMX records as well.
I'm also concerned that they way patent is written (as well as together
with another patent I found) it maybe designed to cover comprehensive checks
on multiple identities (eg universal spf or alike), but that maybe an 
exaduration on my part.

Please see below for more information on the MARID specific text:

----------------------------------------------------------------------------

[0067] A purported sending domain can be identified from parameter values 
contained in an electronic message. For example, messaging server 317 can 
identify domain 305 from parameter values contained in electronic message 
371 (e.g., from spoofed domain name 372). The purported sending domain can 
be identified from the domain portion (e.g., characters after the "@" 
character) of the purported sending entity. Other parameter values in an 
electronic message can include the actual sending network address. For 
example, an actual sending network address can be included in a 
Reverse-Path of an electronic message (which may be referred to as the 
envelope From address). A Reverse-Path can be included in an electronic 
message as a result of a sending computer system issuing an SMTP "MAIL 
FROM" command. Thus, messaging server 371 can examine this parameter 
values for electronic message 371 to attempt to identify an actual sending 
network address (e.g., the actual IP address of the messaging server 316). 

[0068] However, it may also be that an actual sending network address is 
included in a first Resent-Sender header of an electronic message, in a 
first mailbox in the Resent-From header of an electronic message, in a 
Sender header of an electronic message, or in a first mailbox of the From 
header of an electronic message. Accordingly, messaging server 371 can 
also examine each of these parameters values (either separately or in 
combination with examining a Reverse-Path parameter value) for electronic 
message 371 to attempt to identify an actual sending network address 
(e.g., the actual IP address of the messaging server 316). Since a number 
of different portions of an electronic message are examined, there is 
increased likelihood that the actual sending network address of the 
electronic message can be identified. Some electronic mail implementations 
require that electronic mail messages be sent with an empty Reverse-Path. 
Embodiments of the present invention can be advantageous for identifying 
an actual sending address when an electronic message does not include a 
Reverse-Path parameter value. 

[0069] Based on spoofed domain name 372, messaging server 317 may identify 
domain 305 as the purported sending domain for electronic message 371. 
Electronic messages that do not contain a Reverse-Path or at least one of 
the listed headers may be considered unwanted and/or unsolicited. 
Considering such electronic messages as unwanted and/or unsolicited 
reduces the likelihood of an entity intentionally omitting a Reverse-Path 
and all of the headers to defeat a message classification module. 

[0070] The method 400 includes an act of examining a plurality of 
parameters values of the electronic message to attempt to identify an 
actual sending side network address corresponding to the sending computer 
system (act 402). Act 402 can include a receiving side computer system 
identifying an actual sending side network address corresponding to the 
sending computer system. The receiving side computer system can identify 
an actual sending side network address, for example, from one or more of a 
Reverse-Path, a first Resent-Sender header, a first mailbox in the 
Resent-From header, a Sender header of an electronic message, or a first 
mailbox of the From header, of electronic message 371. Messaging server 
317 can identify that an actual sending side IP address corresponds to 
messaging server 316. Method 200 can be utilized to decrease the 
likelihood of an IP address being spoofed. 

[0071] The method 400 includes an act of querying a name server for a list 
of network addresses authorized to send electronic messages for the 
sending side domain (act 403). Act 403 can include the receiving computer 
system querying a name server for a list of network addresses authorized 
to send electronic messages for the sending side domain. For example, 
messaging server 317 can cause domain 307 to issue name service message 
375, which includes authorized servers query 379, to name server 308. Name 
service message 375 can include an identifier that identifies domain 305. 

[0072] Name server 308 can receive name service message 375 and process 
authorized servers query 379 accordingly. At name server 308, entry 376 
may be a DNS entry that corresponds to domain 305. Entry 376 can contain 
one or more records (e.g., RMX and/or TXT records) for domain 305, 
including authorized servers record 336. Received TXT records can include 
XML instructions. Authorized servers record 336 can contain network 
addresses (e.g., IP addresses) corresponding to messaging servers that are 
authorized to send electronic messages for domain 105.

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 16 Sep 2004 11:08:19 -0700 (PDT)

On Thu, 16 Sep 2004, Andrew Newton wrote:

> On Sep 16, 2004, at 12:20 PM, william(at)elan.net wrote:
> 
> IANAL, but my limited understanding of these thing is that you must 
> look at the claims.  Somebody correct me if I'm off-base, which is 
> quite possible considering IANAL.

That is certainly true and because IANAL the language in claims is difficult
to make out. I'm posting here the claims that I believe relate to the MARID
portion of that patent application, perhaps you'll understand it better.

P.S. For the authors of this patent reading the list, I'll note that I 
found it funny that patent mentions taking first address of the From 
header. The RFC2822 is very clear that if From header is group of
addresses, then Sender header MUST be present and that is where info
is to be looked at (if its not, one can probably discard the message 
as not RFC compliant). I  simply did not expect such a stupid mistake as
far as email standars are concerned to be part of the patent text.

Claims
--------------------------------------------------------------------------------
What is claimed and desired secured by United States Letters Patent is

...

22. In a receiving domain that is network connectable to one or more 
sending domains, the receiving domain including one or more receiving 
messaging servers configured to receive electronic messages from sending 
domains, a method for determining if a sending messaging server is 
authorized to send electronic messages for a sending domain, the method 
comprising: an act of receiving an electronic message purportedly sent 
from the sending domain; an act of examining a plurality of parameter 
values of the electronic message to attempt to identify an actual sending 
side network address corresponding to a sending computer system; an act of 
querying a name server for a list of network addresses authorized to send 
electronic messages for the sending domain; an act of determining if the 
actual sending side network address is authorized to send electronic 
messages for the sending domain; and an act of providing results of the 
determination to an message classification module such that the message 
classification module can make a more reliable decision as to classifying 
the received electronic message. 

23. The method as recited in claim 22, wherein the act of receiving an 
electronic message purportedly sent from the sending side domain comprises 
an act of receiving an electronic mail message. 

24. The method as recited in claim 22, wherein an act of receiving an 
electronic message purportedly sent from the sending domain comprises an 
act of receiving an electronic message that does not include a 
Reverse-Path parameter value. 

25. The method as recited in claim 22, wherein an act of examining a 
plurality of parameter values of the electronic message to attempt to 
identify an actual sending side network address comprises an act of 
identifying an Internet Protocol address corresponding to the sending 
computer system. 

26. The method as recited in claim 22, wherein an act of examining a 
plurality of parameter values of the electronic message to attempt to 
identify an actual sending side network address comprises an act of 
examining a plurality of parameter values wherein at least one of the 
plurality of parameter values is selected from among a first Resent-Sender 
header value, a first mailbox value in the Resent-From header, a Sender 
header value, or a first mailbox value in the From header. 

27. The method as recited in claim 22, wherein the act of querying a name 
server for a list of network addresses authorized to send electronic 
messages for the sending domain comprises an act of querying a Domain Name 
Services server for a list of network addresses authorized to send 
electronic messages for the sending domain

28. The method as recited in claim 27, wherein the act of querying a 
Domain Name Services server for a list of network addresses authorized to 
send electronic messages for the sending domain comprises the act of 
querying a Domain Name Services for a list of Internet Protocol addresses 
authorized to send electronic mail message for the sending domain. 

29. The method as recited in claim 22, further comprising: an act of 
receiving a list of network addresses that are authorized to send 
electronic messages for the sending domain. 

30. The method as recited in claim 29, wherein an act of receiving a list 
of network addresses that are authorized to send electronic messages 
comprises an act of receiving one or more DNS TXT records. 

31. The method as recited in claim 30, wherein an act of receiving a list 
of network addresses that are authorized to send electronic messages 
comprises an act of receiving one or more DNS TXT records that encode the 
list of network addresses in XML instructions. 

32. The method as recited in claim 31, wherein an act of receiving one or 
more DNS TXT records that encode the list of network addresses in XML 
instructions comprises an act of receiving electronic messaging 
configuration information that spans across a plurality DNS TXT records 
such that the electronic message configuration information can be 
concatenated into an XML instance. 

33. The method as recited in claim 32, wherein the act of receiving 
electronic messaging configuration information that spans across a 
plurality DNS TXT records such that the electronic message configuration 
information can be concatenated into an XML instance comprises an act of 
receiving a plurality of DNS TXT records that include ordering data 
indicating how the XML instructions contained in the DNS TXT records are 
to be ordered. 

34. The method as recited in claim 33, further comprising: an act of 
concatenating the XML instructions according to the ordering data to 
generate an XML instance. 

35. The method as recited in claim 22, wherein the act of determining if 
the actual sending side network address is authorized to send electronic 
messages for the sending domain comprises an act of determining that the 
actual sending side network address is contained in a received list of 
authorized network addresses. 

36. The method as recited in claim 22, wherein the act of determining if 
the actual sending side network address is authorized to send electronic 
messages for the sending domain comprises an act of determining that the 
actual sending side network address is not contained in a received list of 
authorized network addresses. 

37. The method as recited in claim 22, wherein the act of an act of 
providing results of the determination to an message classification module 
comprises an act of indicating to the message classification module that 
the actual sending side network address is authorized to send electronic 
messages for the sending domain. 

38. The method as recited in claim 22, wherein the act of an act of 
providing results of the determination to an message classification module 
comprises an act of indicating to the message classification module that 
the actual sending side network address is not authorized to send 
electronic messages for the sending domain.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 16 Sep 2004 13:36:48 -0400

-andy

---

From: Meng Weng Wong <[email-masked]>
Date: Thu, 16 Sep 2004 22:17:20 -0400

On Thu, Sep 16, 2004 at 09:20:41AM -0700, william(at)elan.net wrote:
| > US - Title: "Reducing Unwanted And Unsolicited Electronic Messages By 
| > Preventing Connection Hijacking And Domain Spoofing", Serial no. 10/684020
| 
| This patent got published today, to see it try using this url:
| http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=684020.APN.&OS=APN/684020&RS=APN/684020
| If does not work go to http://appft1.uspto.gov/netahtml/PTO/search-bool.html
| and type 684020 for Application Serial Number in field1. 

Application Serial Number 10/683624 may also be of interest
to this working group.

"Reducing Unwanted and Unsolicited Electronic Messages by
Exchanging Electronic Message Transmission Policies and
Solving and Verifying Solutions to Computational Puzzles"

cheers
meng

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Sep 2004 22:51:44 -0700

>From their presentation, the concept was to impose about a 16 second
additional CPU message burden for the sender.  Their statement was such
additional overhead doubled the cost of equipment for the sender.  This
does not consider that many abusive senders control millions of Window
machines with hidden Trojan proxies and never pay for their use. 
Instead of deploying 50,000 machines, this puzzle may require 100,000. 
With each machine costing them $0.00, even doubling CPUs will not affect
the abuser's costs of sending to the same extent it will for legitimate
senders.

It does bring up the issue of cost for a maximal 200 second receiver
burden for resolving Sender-ID or SPF records.  With a common spammer
technique of using random sub-domains, this will keep filters guessing
and the DNS resolvers scrambling for records.  It would seem
illegitimate senders win in any war of escalated overheads.  If only
these innovators would properly handle a temp error, we could slow
unknown senders without punishing legitimate senders. ; )

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 16 Sep 2004 23:41:11 -0700 (PDT)

> machines with hidden Trojan proxies and never pay for their use. 

And besides, the CPU  costs are rapidly going down with twice as fast CPUs
being released every one or two years. You simply can't rely on this 
technique - the hardware cost even for spammer that does not use zombie
machines is likely to be low percentage for cost of his operation - its 
the cost of hosting of such machine on "spam tolerant" network that is high.

> and the DNS resolvers scrambling for records. 

I note that the same problem exists with absolutly every proposal before
MARID. And in reality its not really proper concern for this group, we
need to worry how to properly identify GOOD senders and how to make sure
THEIR domains are not forged.

That spammers can still buy new domains for almost nothing ($6) or use 
subdomains which are technically free to them and then publish MARID 
records there is outside the scope of this group - it is something to be 
addressed by reputation.

> It would seemi illegitimate senders win in any war of escalated 
> overheads.  If only these innovators would properly handle a temp error, 
> we could slow unknown senders without punishing legitimate senders. ; )

I did not understand how handling temp error would help. Can you explain
or give example?

---
William Leibzon, Elan Networks:
 mailto: [email-masked]
Anti-Spam Research Worksite:
 http://www.elan.net/~william/asrg/

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Sep 2004 10:37:39 -0700

> the cost of hosting of such machine on "spam tolerant" network that is high.

Increased overhead burdens legitimate mail disproportionately more than
it does for illegitimate senders.  Higher overhead moves toward a system
that does not achieve the needed scale and that becomes more fragile or
prone.

> I note that the same problem exists with absolutely every proposal before

The focus should be centered upon establishing a basis for
accountability with low overhead (i.e. CSV).  The marid-mpr draft was to
show once a reasonably strong name or identity is established, to then
include mailbox domain constraints only requires a name list.  There is
then no need for "includes", "redirects" or various other subsequent
record lookups.  Your point is on point, however.

> records there is outside the scope of this group - it is something to be 

You are right, obtaining a new domain becomes just another cost of doing
business for the spammer.  I see some sites, in efforts to bypass
filters, pickup several domains a day.

> I did not understand how handling temp error would help. Can you explain

Although a good list may be relatively complete, there will always be
new users and legitimate domains that will need to enter the system. 
Rather than tar-pitting, a friendlier method may be to cap these obscure
domains until there is a history established.  Capping could be done by
issuing a temp error.  There will still need to be a clearing house to
note the good domains that have "gone bad" and perhaps help identity the
new domains from the older well behaved.  

Microsoft innovations have overlooked some basic elements to grapple
with the spam problem.  Forwarding the message should include all
headers to make submitting a complaint something an average user would
be able to do.  Handling of temp errors should cause a sizable delay
before the delivery is retried.  Some sites require the use of DoS
blocking techniques to handle poor behavior.

-Doug