----- Original Message -----
From: "wayne" <wayne(_at_)schlitt(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Sunday, December 05, 2004 8:39 PM
Subject: Re: [spf-discuss] Agenda item: SenderID Position Statement
In <x47jnw64k0(_dot_)fsf(_at_)footbone(_dot_)midwestcs(_dot_)com> wayne <wayne(_at_)schlitt(_dot_)net>
writes:
For the next SPF council meeting, I request that the SPF communities'
position on SenderID be put on the agenda.
One of my candidate pledges said:
I strongly support the "SPF Community Position on SenderID" as written
on http://www.openspf.org/OpenSPF_community_position_v102.html and
have signed it. Since this document was (obviously) written before
the elections, one of my first tasks would be to bring this to an
official vote.
It's an awfully good position paper. Unfortunately, it starts with a
mistaken premise:
Using SenderID _REQUIRES_ SPF
Unfortunately, this is not true. SenderID is politely hijacking the SPF DNS
component as a key tool. They used it as a convenient method of getting the
keys into DNS. They can and should use a different name for their field,
such as spf=v2, and the failure to do so is interfering with the already
working standard.
I encourage people to (re-)read the "SPF Community Position" that is
being discussed. See:
http://www.openspf.org/OpenSPF_community_position_v102.html
Meng asked: "what's the strategic objective of having a position on
sender id at this point?"
To spike Meng's well-meant but failed policy of cooperating with Microsoft
in this development effort. Meng, you're apparently a nice guy, but they've
used you to your detriment and SPF's loss.
In particular, there is confusion in the market about the relationship
between SPF and SenderID. This reduces the value of the SPF brand
name as an independant anti-forgery system. Problems associated with
SenderID have and will continue to tarnish the SPF name as long as we
allow this market confusion to continue. When (if?) SenderID fails in
the market, it is likely to cause further damage to SPF.
Bingo. They need to be separated, clearly, lest the failures of SenderID
imperial a much simpler and already effective tool.
Is SPF just an "essential part of SenderID"? If so, the council
should vote down this SPF position statement and rebuke the claim that
it is the "SPF community Postion on SenderID". If SPF is not a part
of SenderID, then I think the council should make this clear, and part
of making that clear would be to confirm this position statement.
SenderID is a parallel development, trying to using SPF's already proven
tools in DNS handling to publish their authentication information rather
than the domain-wide email handling policies that SPF publishes.