Meng (and everyone else),
I'd like to ask that we step back and consider something rather basic.
MWW> I have been calling this approach "Unified SPF" --- it
MWW> embraces the CSV and the MTAMark/SS semantics using the SPF
MWW> syntax and lookup, just as SPF has embraced the CallerID
MWW> semantics with SenderID.
When I first heard about SPF, I thought I knew what it was. Over time,
I have become quite sure that I don't. The text of your note, "Unified
SPF" eliminated any doubt that I might have had. A specification that
increasingly is described as being able to do everything is one that
always confuses the heck out of me.
So I would find it extremely helpful to hear some precise descriptions
of what this thing called SPF really is and what it really does. When
we have a clear and consistent understanding of it, the community can
reasonably assess what is reasonably appropriate to count within SPF
and what should be counted as outside it.
Knowing what is NOT in a mechanism is often more important than
knowing what is IN it. For all discussions over recent months, it
appears that every feature for spam and spoofing control can be
incorporated in SPF. This should give us some pause. Offhand, I
cannot think of a successful Internet protocol that has demonstrated
this degree of flexibility.
By way of pursuing this off of a previous, related thread:
MWW> SPF is extensible. Multiple mechanisms can be defined. While other
Extensibility is always appealing, but it also often is surprisingly
risky, both in the near-term and the long-term. Referring to it can
be a mantra for avoiding careful analysis in the near-term and for
deferring considering of essential issues. Of course, in the
long-term it can fail to support the promised enhancements, at the
least resulting in massive opportunity costs.
Here, it raises a rather basic question: What, exactly, is SPF? What
mechanisms does it provide? What incremental value-add does it
create?
My reason for asking such a basic question is that I think it is
important for the community to be clear about proposals, so they know
what they are "buying". The alternative is that they will have
unrealistic expectations and wind up at least disappointed, and
possibly far worse.
(The delays in issuing the recent version of our own CSV proposal was
that we felt it essential to hold it to this strict standard of
clarity. It turned out to be remarkably difficult to be sufficiently
clear about describing the details of functionality, even amongst
ourselves.)
A number of different answers about SPF are possible. I suspect my
own list of choices is woefully incomplete, but here goes:
LABEL: SPF is a a suite of essentially independent tools, brought
under a common label. Taking the example of the extension you
suggest for DomainKeys, SPF does not "do" DomainKeys, Rather, it
"refers" to it. What does it actually mean to say that SPF
"supports" DomainKeys? At the least, this means that the cited
mechanisms need to be evaluated independently, to consider their
independent behaviors and merits.
CAPABILITIES: SPF is a means of publishing email reception access
control capabilities. Hence it permits sending SMTP clients to
know what tests they will be subjected to and, by implication,
what tests they need to facilitate, such as doing their own
publishing of relevant information, marking of individual
messages, etc. It is worth noting that the DNS is only one, useful
means of getting information published on the net. In fact there
are some IETF "capabilities" standards that support alternative
means of permitting such publishing through different channels.
POLICES: SPF is a means of publishing email reception access
control capabilities, as well as detailing parameters for the
behavior of the supported mechanisms. Given the current meaning of
the "P" in SPF, this might seem the obvious choice, but public
discussion usually describes SPF as "doing" the control
mechanisms, rather than only "describing" them.
PLATFORM: SPF is a means of performing a series of email reception
access control tests. It provides an common, integrated platform
for these test, leveraging common component mechanisms for
efficiencies such as simpler software and easier administration.
Including something like DomainKeys would suggest that that this
choice does not apply, since DoimainKeys is an entirely
independent mechanism.
The reason this question is important was underscored at the SPF BOF
at Inbox event: a room full of staunch supporters also thought the
question important enough to discuss and participants gave
significantly different answers. Even supporters are not very clear
about the details of the job that SPF does.
For a specification that has been around this long, that kind of
uncertainty is worthy of note and repair.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>