I have just read the PRA, CORE, etc files which are referred to in MARID and
the MS patent licence and I hope I am wrong, but here's my take on it.
The PRA algorithm goes down the headers in a specific order, and selects or
discards the various addresses listed until it comes up with a good one.
Here's what it does --
<quote from PRA>
2. Determining the Purported Responsible Address
The purported responsible address (PRA) of a message is determined by
the following algorithm:
1. Locate the first non-empty Resent-Sender header in the message.
If no such header is found, continue with step 2. If it is
preceded by a non-empty Resent-From header and one or more
Received or Return-Path headers occur after said Resent-From
header and before the Resent-Sender header, continue with step
2. Otherwise, proceed to step 5.
2. Locate the first non-empty Resent-From header in the message.
If a Resent-From header is found, proceed to step 5. Otherwise,
continue with step 3.
3. Locate all the non-empty Sender headers in the message. If
there are no such headers, continue with step 4. If there is
exactly one such header, proceed to step 5. If there is more
than one such header, proceed to step 6.
4. Locate all the non-empty From headers in the message. If there
is exactly one such header, continue with step 5. Otherwise,
proceed to step 6.
5. A previous step has selected a single header from the message.
If that header is malformed (e.g. it appears to contain multiple
mailboxes, or the single mailbox is hopelessly malformed, or the
single mailbox does not contain a domain name), continue with
step 6. Otherwise, return that single mailbox as the Purported
Responsible Address.
6. The message is ill-formed, and it is impossible to determine a
Purported Responsible Address.
</quote>
In my humble opinion this cannot be patented as it as just too obvious and
has probably been written loads of times before. Even I have written
similar such scripts in attempts to mess with my spam.
It useless anyway - it doesn't even check for an MX record in the address it
is offering as the PRA - so the address is not *really* usable in sorting
out whether the mail came from a *genuine* address or not.
<quote from PRA>
3. Security Considerations
The PRA, as described by this document, is extracted from message
headers that have historically not been verified. Thus, anyone using
the PRA for any purpose MUST be aware that the headers from which is
is derived might be fraudulent, malicious, malformed and/or
incorrect. [SenderID] describes one mechanism for validating the
PRA.
</quote>
I then went back to where the PRA is "called" from -
The PRA is called from the CORE document and it states
<quote from CORE>
5. Actions Based on the Decision
When the Sender ID test is used by an SMTP server as part of
receiving a message, the server should take the actions described by
this section.
The check_host function returns one of the following results. See
[Protocol] for the meaning of these results.
</quote>
where [Protocol] refers to the -PROTOCOL document and it states that
<quote from PROTOCOL>
2. Permitted Sender Records
Domains publish records to declare which hosts are and are not
permitted to use their names when sending mail. Loosely, the record
partitions all hosts into permitted and not-permitted sets. (Though
some hosts might fall into other categories.)
The record is a single string of text:
record = version *( 1*SP ( directive / modifier ) ) *SP
An example record is:
spf2.0/pra +mx +a:colo.example.com/28 -all
This record has a version of "spf2.0/pra" and three directives:
"+mx", "+a:colo.example.com/28", and "-all".
Mail receivers read these records to allow them to perform checks for
a given host in a given context. They do so by evaluating the
check_host() function (described below), and the directives of a
domain's record direct the evaluation.
2.1 Publishing
A domain publishes its record in DNS.
........etc
</quote>
which is SPF !!!
Now - please tell me I am wrong - but if M$ are applying for a patent
licence over the CORE and PRA documents (or parts of them), it is going to
be impossible to *not* include the PROTOCOL document - which is spf . This
is what the patent licence disclosure states:
<quote>
C. If an Internet-Draft or RFC includes multiple parts and it is not
reasonably apparent which part of such Internet-Draft or RFC is
alleged to be covered by the patent information disclosed in Section
V(A) or V(B), it is helpful if the discloser identifies here the
sections of the Internet-Draft or RFC that are alleged to be so
covered.
Both Sender ID: Authenticating E-mail <draft-ietf-marid-core-03.txt>
and Purported Responsible Address in E-mail Messages
<draft-ietf-marid-pra-00.txt> in combination.
</quote>
Then I read this expert legal opinion on the ietf-mxcomp(_at_)imc(_dot_)org
mail-list :
<quote>
.....
And herein lies one of the rubs - without knowing what the patent
alleges to include, we can't possibly say with any certainty that if it
doesn't work out, very few components need to be switched out to remove
their IPR from play. It's entirely possible that the pending patent
includes everything, and a few extras besides. Certainly if I were
their lawyer, that's how I'd write it. As such, it's entirely possible
that one could find that one couldn't use *any* related components.
Sure, as some have mentioned, there is prior art, MS created Caller
I.D., not Sender I.D., etc. etc.. Are *you* going to fund and mount
that legal battle?
From a legal viewpoint, it's always safest to assume that the claim
includes nearly everything, if not everything. Especially when one
can't even see it.
Anne
Anne P. Mitchell, Esq.
President/CEO
Institute for Spam and Internet Public Policy
Professor of Law, Lincoln Law School of SJ
Committee Member, Asilomar Microcomputer Workshop
</quote>
So - as far as I can see - M$ are actually trying to patent the whole
thing - Caller-ID, Sender-ID, *and* SPF. If they are not, why haven't we
been told what they *are* trying to patent????
If - like me - you're having trouble locating this paperchain of documents,
here's most of the url's :
http://www.ietf.org/html.charters/marid-charter.html
http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-marid-core.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-core-03.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-pra-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-protocol-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-marid-rationale-00.txt
http://www.ietf.org/ipr
It's not a huge amount af reading, and I'd recommend anyone with even a
slight interest to take the couple of hours to read it all and relate all
the references, and to see what interpretation you come up with.
Slainte,
JohnP.
johnp(_at_)idimo(_dot_)com
ICQ 313355492