Correct, it would not be difficult to prove prior art and upon examination
using the Markush-type patent analysis, it would be difficult to enforce the
broad claims in this MS patent application.
Prior Art existed for MAIL FROM checks for years now. Besides, RFC 2821
Section 3.3 "Mail Transactions clearly opens the door for MAIL FROM
validation possibilities:
3.3 Mail Transactions
.....
The first step in the procedure is the MAIL command.
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
........ Despite the apparent
scope of this requirement, there are circumstances in which the
acceptability of the reverse-path may not be determined until one or
more forward-paths (in RCPT commands) can be examined. In those
cases, the server MAY reasonably accept the reverse-path (with a 250
reply) and then report problems after the forward-paths are received
and examined. Normally, failures produce 550 or 553 replies.
In this case, we doing a RCPT-TO check first to determine the acceptability
of MAIL FROM. SPF and others ignore RCPT-TO.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office
----- Original Message -----
From: "Andrew W.Donoho" <awd(_at_)DDG(_dot_)com>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Wednesday, September 22, 2004 12:18 PM
Subject: [spf-discuss] SPF Prior Art?
Folks,
IANAL but I have been around the block a few times.
SPF leverages a well known security pattern of third party
authorization/authentication. In the DNS context, this is demonstrated
by well deployed products like BIND 9 that only accept NOTIFY messages
from non-LAME nameservers. This is exactly analogous to how SPF queries
DNS but SPF looks at a different record - TXT versus NS. The use of
this security pattern in the context of email is neither novel nor
innovative. For example, RFC 821 refers to HELO as having a FQDN but
that you are not supposed to rely upon it. At minimum, this says that
the concept of using the security pattern of third party
authorization/authentication is well known and should not be depended
upon when processing HELO. This looks like prior art to me in the
specific instance of deciding not to use the DNS to authorize an IP
address. Shifting to use the MAILFROM instead of HELO is not innovative
nor novel. It is obvious to one practiced in the art of using the SMTP
protocol. There is prior art all over the concept of SPF.
The W3C, recently, at the request of Microsoft, formally asked the
USPTO to re-examine the EOLAS patent. It was then found to be invalid.
Therefore the question facing us is: how do concerned parties register
this prior art with the USPTO as an objection to patents that affect
SPF? Waiting for litigation is waiting for inordinately expensive
trouble.
Best Regards,
Andrew
____________________________________
Andrew W. Donoho
awd(_at_)DDG(_dot_)com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta
features SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com