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.