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.
I thought the same on reading this last night after Meng provided the links.
IMHO, steps 3 - 6 are defined in the RFCs, and AccuSpam has been doing them for
quite a while. I would need to dig into backups to see when was our first
published use (in the old AccuSpam algorithm from 2003). Does anyone know when
Microsoft's patent for PRA was filed?
Also I agree the legal opinion quoted (I am not a lawyer nor referred this to
our lawyer) in that irregardless of the actual claims, in a practical sense is
much more costly to go back to being "unencumbered" from the license after
you've already agreed to it. In the real world, this for example could have
more to do with paralysis from fear and unknown than anything else.
What is the advantage for the IETF to incorporate SenderID into their published
standard? What is cost/benefit analysis?
Again I still have not taken the time to read all the documents, so I will not
comment again on this until I or our lawyer does.