-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Greg
Connor
Sent: Friday, December 10, 2004 1:47 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Agenda item: SenderID Position Statement
Thanks Andy, Alex and Frank for the replies. I'll make some changes
tomorrow and circulate it around again.
gregc
--Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com> wrote:
On Thu, 2004-12-09 at 16:42, Greg Connor wrote:
Team-
Since "reuse of v=spf1 records" seems to be the most pressing issue, I
have written a "position statement" that addresses inappropriate reuse
and doesn't address other issues (PRA license or technical problems).
...
Link:
http://nekodojo.org/~gconnor/spf-context-usage.txt
Thanks Greg. I don't like how it specifically mentions Microsoft and
PRA by name (unlike my original short paragraph, but I was going for
something to be included in a standards document, rather than something
that is more along the lines of a position statement), but overall, this
accurate reflects *my* SPF context usage position.
Andy.
I'm with Andy on this one. Submitted for your consideration:
As developers and users of the Sender Policy Framework ("SPF"), we welcome
proposals that will truly help clean up the current problems with email
forgery.
SPF is an open protocol and its use is not controlled or licensed. The SPF
protocol and language is flexible and it is our hope that the same language
can be successfully applied in other contexts having to do with email
forgery.
The currently deployed version of SPF "v=spf1" was designed to protect only
the MAIL FROM address (a.k.a. return address or return path) and the HELO
domain. The "v=spf1" language didn't extend to protecting other parts of
the message transaction, such as From: or other visible headers. We expect
that a future version of SPF (Unified SPF) will be flexible enough to handle
multiple contexts within a single record.
We know that there are a number of cases where using the "v=spf1" record
information in other contexts will give incorrect results, and this will
lead to missed expectations and potentially delivery failures.
Further, we believe that the original intent of the domain owner who
published the record should be respected, and that implicitly using that
data for other purposes is not appropriate. We feel that requiring the
publisher of the record to "opt out" of such use is not sufficient; the
domain owner should explicitly "opt in" before the data is used in a new
context. While technical problems can be addressed with technical
solutions, this is not a technical problem to be solved; it is an issue of
respecting the intent of the domain owner.
Therefore, we recommend the following:
- Domain owners should publish v=spf1 TXT records to take advantage of SPF
now. (SPF can protect MAIL FROM and HELO), but they should do so
understanding the limits of the technology.
- Domain owners who would like to protect From:, Sender: and other headers
should publish spf2.0/pra records to take advantage of PRA, but they should
do so understanding the limits of the technology.
- When Unified SPF is complete, domain owners may be able to combine these
two uses, as well as other types of protection for other contexts, into one
single record. This version is not developed yet and current SPF-compatible
tools will not be able to immediately take advantage of it.
- Software vendors implementing PRA and other SPF-based protocols and
methods should NOT use "v=spf1" records to check data items other than MAIL
FROM and HELO/EHLO. Software vendors that fail to heed this advice MUST
take responsibility for supporting resolution of the negative impacts of
such an approach.
- Users should not buy or use software that configured to use "v=spf1"
records in an inappropriate context.
Scott Kitterman