On Fri, 10 Dec 2004, Scott Kitterman wrote:
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.
Remove "within a signle record" - it maybe a single record or it may
require multiple records, we can't speak for final unified spf syntax
right now.
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.
Replace "and potentially delivery failures" with
"and may cause unexpected delivery failures." (it sounds better).
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.
Ok
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.
Ok
- 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.
I disagree with above and believe its better to remove above all together.
I do not believe PRA is a good way forward to protect From: and Sender:
and that technology is fundamentally flowed, while above paragraph seems
to indicate that SPF does in fact believe it is a way to protect From and
Sender. Personally I think this should be left entirely to cryptographic
techniques (mail signatures, SES, etc) and best we can do for it in the SPF
world is header equivalency modifier I proposed (and its a lot safer and
easier to implement then PRA anyway). Furthermore I do not believe we have a
consensus on spf2.0 record format and scoping syntax at this time either.
- 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.
Change to
- When Unified SPF is complete, domain owners may be able to publish SPF
records to protect MAIL-FROM, HELO and other SMTP Session parameters as
well as apply similar protection methods for other contexts including
protection of 'From', 'Sender' and other headers. This version is not
developed yet and current SPF-compatible tools are not able to take
advantage of extended uses of SPF records.
- Software vendors implementing PRA and other SPF-based protocols
Change to
- Software vendors implementing SenderID 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.
Ok.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net