spf-discuss
[Top] [All Lists]

fixing email

2004-12-17 19:50:18
On Fri, Dec 17, 2004 at 05:43:39PM -0800, Hallam-Baker, Phillip wrote:
| The lesson to draw from all this is that if you want to be effective in
| propagating a standard you need to write test suites.
| 
| An SPF test suite would be very nice. It would also effecitvely mean that
| control of the test suite was control over the spec.
| 
| An email test suite would be even nicer. It would be realy nice if there was
| some source that provided a set of tests that could be used to show the
| extent to which software complied with a spec and a spec was an accurate
| description of what is in use.
| 
| We could then draw up a big matrix and work out what the shortest distance
| is from where we are to a coherent and consistent set of email specs that do
| not do this sort of thing. 

I'm working on it!  Details to follow.

Unfortunately these things don't write themselves, so with
any luck we'll see a few bucks in the next few months to
make these things happen.

The alternative is that folks will pretty much give up on
Plain Old Email Service and switch to whatever succeeds it,
eg p2p email or sender-stores IM.  (Adium already does
sender-side buffering when both sides are not around: that's
pretty much the spirit of IM2000.)  And the innovation model
we've seen lately is for proprietary standards to establish
immiscible domains.  So if we, for the greater good of the
internet, want to fix it, we have to do it right.  It's a
lot of work and not all of it is fun or sexy.  Hence the
need for bucks.

This is not the forum for those who believe that it ain't
broke and we shouldn't fix it.  I hate to have to pull out
the quote, but here it is: "Lead, follow, or get out of the
way."  

Most of the rest of us have moved past that point to the
thinking that yes, we're going to break it a little more,
and some use cases will suffer, but it's necessary to take a
step back and look at the global picture, and realize that
you can't make omelettes without breaking eggs.


<Prev in Thread] Current Thread [Next in Thread>