spf-discuss
[Top] [All Lists]

RE: Agenda item: SenderID Position Statement

2004-12-09 15:42:51

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.