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).
Please browse the statement and see if it is compatible with your own vision
of SPF :) Suggestions for changes are appreciated.
Link:
http://nekodojo.org/~gconnor/spf-context-usage.txt
Text version appears below the sig...
--
Greg Connor
gconnor(_at_)nekodojo(_dot_)org
Everyone says that having power is a great responsibility. This is a lot
of bunk. Responsibility is when someone can blame you if something goes
wrong. When you have power you are surrounded by people whose job it is
to take the blame for your mistakes. If they're smart, that is.
-- Cerebus, "On Governing"
http://nekodojo.org/~gconnor/spf-context-usage.txt
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. Microsoft's PRA (part of
SenderID) is one
such use where the SPF language can be applied to other purposes.
The currently deployed version of SPF (SPFv1) was designed to protect only the
MAIL FROM
address (a.k.a. return address or return path) and the HELO domain. The SPFv1
language didn't
extend to protecting other parts of the message transaction, such as From: or
other visible
headers. We expect that the next version of SPF (SPFv2) will be flexible enough
to handle
multiple contexts within a single record.
We believe that there are a number of cases where using the SPFv1 record
information in other
contexts will give incorrect results, and that using "v=spf1" records for
checking message
headers will lead to missed expectations and 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
such as PRA 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:
- Users should publish v=spf1 TXT records to take advantage of SPFv1 now.
(SPFv1 protects
MAIL FROM and HELO)
- Users who would like to protect From:, Sender: and other headers should
publish spf2.0/pra
records to take advantage of PRA.
- When SPFv2 is complete, users will be able to combine these two uses, as
well as other
types of protection for other contexts, into one single record. This
record will most
likely start with "spf2.0" (This version is not finalized yet and most
SPF-compatible
tools will not be able to take advantage of SPFv2 records for some time.)
- 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. PRA
should only be
checked using "spf2.0" or "spf2.0/pra" records.
- Users should not buy or use software that uses "v=spf1" records in an
inappropriate
context.