On Wed, 15 Dec 2004, Hallam-Baker, Phillip wrote:
Sorry, but I think it is wrong and I intend to bring it to a
vote so that in the future we can point to the vote and
disavow any claims by Meng or Harry or anyone else that SPF
is part of SenderID.
What does that achieve besides warning the public that there is still
uncertainty and argument and they maybe should wait a while?
Public would be right to wait until we finish with experimentation phase
and have better results on how larger scale use SPF and SID changes
email system and how much effect it has on legitimate use of email
(this is all especially true for SID, which has NOT undergone any
serious testing and is just trying to use SPF name to say that its
already in wide use and everything is ok when its not even close)
Do you really achieve your goals by forcing Harry to make a new slide which
shows SenderID layered on top of SPF? That is if you think you can force
anything...
Harry's slides are his own, if he wants to present false information to
the public he can, but its another thing that people might have access to
true information from other sources and not believe the slides and that
will cut into his credability when he says something about great benefits
SID brings and how widely it is already deployed.
The only thing we need unanimity on is the SPF record format. If you want
to go any further and insist on a set of rules then give the MAIL from
rules a catchy name, like MFR.
Then SPF = the DNS record, Sender-ID Framework = PRA + MFR + csv'
You did not understand what we were talking about. People here have no
problem if SID says that it uses ->SPF syntax<- its the MFR (i.e. SPF
Classic) being partof SID that we have a problem with. So the framework
parts view is like this:
CallerID = PRA using XML syntax dns records
SenderID = PRA using SPF syntax dns records
Classic SPF = MFROM using SPF syntax dns records
Unified SPF = MFROM + HELO + SUBMIT + PTR all using SPF syntax dns records
(+ possible PRA as well if its shown to work)
SPF, MFR, csv' are all unencumbered, therefore no problem with FOSS
implementation.
I'm sorry but my view is that framework its non-encumbered if all parts of
it are unencumbered.
Names change over time, at one time I had a scheme called TAXI, even went as
far as registering TAXI-PKI.com. Today that is called XKMS and SAML.
Yes names change and I would not be surprised if Microsoft is forced to
do it for SID in the future...
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net