On Fri, 2004-06-18 at 16:37, Jonathan Gardner wrote:
Jim Lyon's got a new proposal out on IETF-MARID. If I understand correctly,
the chair has proposed that we settle the XML debate once and for all by
allowing people to propose difficult yet possible future extensions. Once
they all get posted, then the anti-XML people will propose how SPF syntax
can be extended to include that.
I propose that we issue a vote on non-confidence in chancellor Lyon.
What I see so far is that their proposals are all way beyond the scope of
what SPF is trying to address: authentication.
I concur, as do I believe every single SPF developer, and most of our
users.
Jim Lyon's recent proposal tries to transfer reputation or accreditation
from one person to another. For instance, he thinks that if abc.com sends
mail through hotmail.com, the owners of abc.com may or may not want that
mail to have the same rep/accred as hotmail.com. This is nonsense because
you can't transfer accred or rep based on how the email got there. The only
question is: Did this mail really come from abc.com or did hotmail.com just
make it up?
Why does this entire situation seem to resemble some sort of car-jacking
to you?
We can't allow extensibility into SPF or SenderID. The problem set is small,
and must remain small. As long as we keep the problem scope small and
well-defined, we will be able to create implementations and languages that
are compact and easily understood and managed. The chance of having every
implementation functioning 100% exactly the same is much greater if the
number of "features" is very small. If someone sees a problem that is
similar to SPF but not in the realm of SPF, let's push back and say, "Come
up with your own solution, but leave us out of it."
Hear hear!
We can win the XML argument if we stick with authentication, authentication,
authentication, and don't allow anything else. I can see their arguments
falling apart as we approach detailed specifics.
I believe given the actions you have just specified lend strong weight
in favour of believing that this is a battle we are winning. In fact,
we were fine until this entire bastardized "merger" was proposed.
However, given what we have endured thus far I would agree with your
words and urge that no one become complacent or content, and that we
must continue our push forward.
I believe I am not alone in saying that regardless of what happens,
there is a strong movement that will carry forward with SPFv1 as it
stands, and I assure you that MS is well aware of this fact.
Cheers,
James
--
James Couzens,
Programmer
-----------------------------------------------------------------
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://gpg.mit.edu:11371/pks/lookup?op=get&search=0x6E0396B3
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Send us money! http://spf.pobox.com/donations.html
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
signature.asc
Description: This is a digitally signed message part