spf-discuss
[Top] [All Lists]

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

2004-09-16 09:20:41

On Tue, 14 Sep 2004, Harry Katz wrote:

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. 


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