-----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: zondag 12 december 2004 16:47
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Re: spf-statement-on-SenderID
Perhaps one or two council members can chime in to this
thread.
Ok, here is my *personal* vision (ahem). I see the Sender ID statement
actually as part of an overall "SPF Sender Authentication Deployment
Recommendations" position, possibly split up in recommendations for
senders, receivers, and mid-points, like in the sendmail paper. Together
with positions on the use of HELO, the reuse of SPF records, etc.
This is only a very preliminary draft. Especially the "Recommendations for
Senders" is still ridiculously short. :) For now, I just like to get a
feel on whether the SPF community, at large, supports the idea of an
overall "SPF Sender Authentication Deployment Recommendations" position.
Most relevant in my draft, I consider the "Recommendations for Receivers"
section; primarily so, I reckon, because it contains the most
controversial issues. :) I have very carefully avoided the name of PRA or
Microsoft. While I have strong feelings on both, I hold the equally strong
belief that a 'positional' paper can be made without mentioning either.
N.B. I have re-used some language of already existing drafts. The idea, of
course, is not to outdo one another, but to combine efforts.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
------------------------------------
1. Recommendations for Senders.
We recommend that senders publish "v=spf1" records, so that receivers may
authenticate designated, authorized mail servers.
2. Recommendations for Mid-Points.
It is the position of the SPF community that every sender on the net take
responsibility for his own "accountable messaging space;" mail forwarders
not excluded. In an SPF world, this means that every outgoing message
SHOULD bear the MAIL FROM stamp of accountability for the relay in
question. By consequence, we recommend that mail forwarders do SRS on the
MAIL FROM entity for mail in transit.
We believe that forwarding, without SRS, "breaks" Sender Policy: in
contrast to the belief that SPF "breaks" forwarding. As such, we believe
that the 'accountable' solution for the forwarder lies in bringing each
message in transit within the purview of its own Sender Policy Framework,
using SRS.
3. Recommendations for Receivers.
3a. Fitness of purpose.
SPF "v=spf1" records are designed and published for software which
protects and operates on the MAIL FROM entity (and, under circumstances,
HELO/EHLO). Using SPF "v=spf1" records for any other purpose may or may
not conflict with Sender Policy. Specifically, the "v=spf1" language does
not cover other parts of the message transaction, such as protecting From:
or other visible headers. Improper use of SPF "v=spf1" records may result
in unexpected/unwanted behavior. In particular, we point to the risk of
having legitimate mail rejected.
We therefore recommend that receivers not use SPF "v=spf1" records for
anything else than MAIL FROM and HELO/EHLO checks.
3b. License encumbered technology.
The SPF community recognizes the existence of patent license encumbered
technology in today's market. It is the position of the SPF community,
however, that key components of the Internet infrastructure should remain
free of license encumbrances. As a result, we feel that license
encumbered technology, insofar as it overlaps with the use of SPF "v=spf1"
records, will hinder and/or conflict with the rapid, Open Source
deployment of SPF. We therefore recommend that receivers only examine SPF
"v=spf1" records with algorithms that are, themselves, unencumbered.
4. Overall Recommendations & Notes.
SPF Classic has been deployed in many antispam and MTA products already,
and currently enjoys the support of an estimated 1 million domains. We
therefore encourage continued development of SPF Classic in the email
industry. We furthermore encourage continued development and exploration
of other possibilities in the accountable messaging space, including, but
not limited to, Identified Internet Mail and cryptographic solutions, like
Domain Keys, SES, S/MIME, and PGP.
As there has been some confusion on the relationship between SPF and
SenderID, we would like to clarify the relationship. While Sender ID
reuses existing SPF records to perform the PRA test, SPF Classic is not
Sender ID, and Sender ID is not SPF. The two technologies are
complementary, but they operate on different parts of the message and
serve different purposes.