On Mon, 2004-06-07 at 01:07, Greg Connor wrote:
possible. To me, which particular interpretation/expression of the idea we
choose to get behind is not as important, but getting rolling soon, and
getting many allies early in the game are most important. If we are all
pulling the same direction, we can make a lot of progress quickly, and a
lot of things that used to be impossible now become possible. If there are
minor differences between two expressions of the same idea, I believe it is
much more powerful to pick one and go with it, together, than to stick to
an idea that we think is superior, but turns a potential ally into a
competitor.
To me its VERY important which one we get behind. Perhaps Microsoft is
evil, perhaps they are not, this opinion is not one worth discussing,
and this is certainly not the place for it. HOWEVER, IMHO the people
responsible for CID are insane and need a trip to the funny farm for a
failure to consider hindsight which as we all know is 20/20. (In trying
to word my strong feelings for how ludicrous much of the CID spec is and
its many incongruities, thats about as close to I can come to describing
it without breaking into my healthy library of colourful language.)
Also, I believe that Microsoft is not the enemy. A lot of people have
strong feelings that Microsoft is evil. I don't. They are simply another
player, and they are a big one... they control servers (exchange) MUAs
(outlook) and one of the largest email services (hotmail).
I would consider Hotmail or MSN (ISP) a big player, but involving
Microsoft puts the wrong entity into the mix if you were to ask me. I'd
rather see separate correspondents from each of the aforementioned
subsidiaries than I would deal with individuals from the parent company
who if they aren't out of touch with reality (um.. I think CID is proof
that I could be on to something here..), are unlikely from the front
lines.
It is a testament to our success that Microsoft approached Meng to talk
about convergence. Most of the time when Microsoft wants to master a new
technology, they just go out and do it. In this case, enough of their
customers and partners said "Hey, hang on, what about SPF?" that they
decided to take the time to talk to Meng to see if convergence was even
possible. Meng should be proud that we got to this point, and so should we
all be.
LOL. Whilst I respect what you are trying to point out Greg, I don't
believe you could BE any more wrong. Microsoft approached us
originally, and they were effectively sent on their way. Their first
approach was the "buyout" attempt. Their second approach was because
low and behold CID is just as ludicrous as we all stated, SPF already
had its claws into the community (<3<3 Slashdot, <3 AOL, <3<3
LinuxJournal), and likely the only people publishing CID were those paid
to or related to MS. For example I HIGHLY doubt that Sendmail jumped on
the CID bandwagon without some sort of $$$$ carrot.
Still, we are not the only fish in the sea, and MS Caller ID is not a
slouch of a proposal either. If there were no convergence, or if the deal
is scuttled for whatever reason, SPF Classic can continue to go its way and
MS CID can continue to go a different way. Eventually one or the other
would probably win out, but this would mean dividing our resources,
competing for attention, etc.
MS has nothing but $$ and press time to offer. Why don't they offer to
pay mine and others salaries so we can all work together in a secret
location in some deep dark underground lair for a couple weeks/months?
I promise I'll hand in ALL my expense receipts!
In exchange for gaining a powerful ally, the New SPF shifts its attention
to 2822 headers instead of 2821 MAIL FROM. Many folks see this as a step
down, because we can't check the authorization before the DATA phase -- at
least not at first -- and the bounce address is protected indirectly, not
directly.
This difference -- 2821 MAIL FROM vs. 2822 From:/Sender: was a big concern
in the IETF MARID working group as well. MARID, true to IETF form, is full
of literally dozens of great ideas, some of which have a chance of working
and some which don't. But again, great ideas by themselves don't solve
problems... hard work solves problems. The MARID camp was pretty much
split due to disagreement about 2821 vs. 2822, much the way SPF and MSCID
were split a few weeks ago. An agreement with MS allows us to present a
consistent story to MARID, which I think is crucial to getting an RFC
drafted and approved.
We already HAD an RFC being considered did we not? In fact I dare say
had we just continued upon our merry little way we'd be farther ahead in
this all area's even if we had less published records as a result.
Someone remind me to send the DNS admin @ AOL a box of chocolates this
Christmas because they not only put the puck in our zone, they moved the
centre back behind the opposing team's net! For those of you who are
hockey-analogy-impaired AOL effectively took Home, 1st, 2nd, and 3rd
base and put them a couple feet apart. What we got from Slashdot, AOL,
and LinuxJournal, was all we needed to get the ball rolling. The
intelligent design, community interest and support, combined with the
continued forgery by spammers is all we needed...
Finally, being able to announce a convergence of the two proposals at the
INBOX email conference was a huge win. This will help us get the message
out there, and help us push through many barriers that would have been
impassable before now. There is a huge difference between asking an ISP to
do something because we think it's right and we hope it won't break
anything, and getting users pumped about it so that they ask their ISP for
it. (Same goes for corporate IT, forwarder, whatever)
Now this I will agree, I was impressed to see SPF become the headline
event if you will of the conference (at least that was my impression).
However, the problem still remains. SPF good, CID bad. SPF and CID do
not mix. Not in the slightest. Our best chance is SPF+DK. One coming
before the other.
So. Those are my reasons for supporting the New SPF. I hope that the SPF
support community will pull together under the common banner, which is
still "Stop email forgery". I hope that the technical differences will
give us some spirited debate, and then get resolved quickly so we can all
stand together again. We have built up a good head of steam and have got
people moving in the right direction. I would not like to see people get
lost in the details, or decide to throw themselves on the tracks because
it's not exactly the same expression of the idea they originally had in
mind.
There is NO resolving the CID issues unless MS wishes to back down and
change their stance on XML. Its stupid and pointless. In addition to
this SPF is only a PART of the solution. We have a significantly
smaller chance of working with Yahoo IMO if we're tied to a hulking pile
of crap whose XML library is larger than one of the worlds most popular
MTA's. We're going to get laughed at.
I have not stated this before, but I might as well now.
libspf will NEVER link any XML crap. I think you can guess at the
ramifications associated with not doing so.
Just which do you think the entire Internet is more likely to get
behind?
A) Tiny library without external requirements (other than core
ubiquitous DNS libraries) that implements a light weight, powerful,
flexible language expressed in such few characters as to easily fit into
DNS records without requiring TCP or having to enter into the DATA
segment of e-mail allowing for early rejection and will lighten loads on
MTA servers (less work for anti-spam software!)
B) Hulking huge library with requirement for a non-standard library
(XML) that implements a heavy weight, powerful, flexible language
expressed using so many characters that it will not easily fit into DNS
records without requiring TCP, and will result in easily noticed
increase in bandwidth consumption and unacceptable additional delays
into e-mail processing. And any benefit yielded by using it (saved CPU
cycles due to less work for anti-spam software) will be nullified by the
disgusting overhead required.
All of this has been said before, but for the benefit of the new people
in here, and anyone who suffers from amnesia or Alzheimer's its worth
the reiteration.
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://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBD3BF855
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
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