hogwash! we can't have novel ideas any more! we have to put bandages on it and make it worse until it breaks and we have to outsource the creation of a new one!

/mine's the one with cobol code on the back

> If that's possible, it may also be possible to convince them that you can get a cheap and quick buzz by inhaling the fumes released when you mix ammonia and bleach

Can you clarify this in the article please? This doesn't cause a buzz, it causes death by chlorine gas poisoning (as used for chemical warfare in world war 1).

I'm worried that some idiot kid is going to see that and try it.

"Can you integrate this with my e-mail?" It's one of the more dreaded questions in software development.

Unless your application server is Lotus Domino :-)

"There should be a simple start for a developer, clear documentation, a framework, a modern language, well defined protocols, commented code, and you should be able to extend it without painful configuration. You know, a lot like Django, Rails, or Cocoa, .NET, or just about any other platform today."

Like Lotus Domino?

"Either that or you can use it to integrate your company's helpdesk system with e-mail."

Or you can just stick with your Lotus Domino based solution - or look into getting one. Check out Foundations server.

http://www.ibm.com/software/lotus/foundations/

Shameless sure, but when you talk about painful email integration then Lotus must needs mentioning.

"Every now and again, and alpha programmer will come along and put a nice API on top of one of these protocols [...] JQuery did it to Javascript"

jQuery is just a big wrapper around eval(). In other words it's a big fucking fail. Ted knows all about fail.

"Indeed, the Java world has taken a stab at e-mail, but has failed miserably."

Have a look at something called "Commons Email", by the folks at Apache, then reconsider statement. And as someone else quite rightly said of course, Java Mail (which ships with the Java distribution).

Seriously though, the RFC's for SMTP, POP3 and IMAP are easily available (and Exchange can be configured to allow them as protocols). Any "technical person" who can't research and understand them well enough to code a simple client for any of them should really go back to script kiddy college and leave the real work to us grown-up software engineers (you know, the ones who can imagine writing network apps without HTTP and write protocol implementations without a third party API?).

I find "how would you code a simple E-mail client" a great interview question to weed out people who are worth hiring...

Never had any problems with email apps, used Java and .NET stuff in the past.

But that's probably because I'm an awesome programmer...

Not seeing the advantage here. e-mailing is especially easy using Java - I used the javamail extensions years ago and it handled SMTP and MIME like a dream, probably even better now.

No-one wants a new server unless it does something genuinely different - they want code to integrate with their existing server.

Wake me up when this code does something special - like easily integrating with the advanced features of Exchange or similar, transparently handles exchange calendaring or helps you write mail gateways easily.

Of course that would require real effort, like discovering that some MAPI server functions silently corrupt your data when used one time in four, and having to code workarounds. Or perhaps that whilst core Windows has pdb files to tell you what functions you're debugging exchange didn't as little as a couple of years ago - assembly level debugging - niiice. Or that the documentation is incomplete and complex - you really don't want to know how you convert an RTF stream to something else.

It also sounds like a definite work in progress. Python isn't a bad language (apart from the enforced whitespace. Nice in theory, pain in the arse in practice) but last time I looked it wasn't rock solid in all its modules either.

It doesn't surprise me that Ted likes Zed who also comes across as a total dick ninety percent of the time but is likewise pretty funny with it. I am, however, surprised that there is room on the american continent for two egos of that size.

Also, the palm sweat doesn't come from the awkwardness of programming around email, that just comes with the territory. I mean obviously anything that helps with that is good, but the cold fear in my heart when I think of working with email is from the moment when you realise you have just sent your jokey/sweary/surreal/deeply inappropriate test email to every customer your employer has ever had. And that most of them are unlikely to see the funny side. And that the bounced messages from all the failed recipients are probably going to hose your company's mail server too...

You see, the last time I heard of this retard was because he was threatening anyone who disagreed with him to a boxing match anywhere in the world because of his opinion that RoR sucked ass and omg, I'm so a super programmer, why doesnt everyone take a spoon, so they can eat my ass.

Zed is just a drama queen, a prima dona. Lets actually look at what he has done.

........I'll wait..........NOTHING

All he has done is write ANOTHER email server like system, using python instead. WOW FRIGGING STRAP ME DOWN AND GIVE ME ANOTHER HOT CHERRY SURPRISE!!

The real problem is that the protocols and methods of doing the transactions are hopelessly out of date. They need to be improved.

Email, the protocol, the application layer, etc, etc, was built decades ago using what little we had to create a messaging system that would work reliably (as much as possible).

Back in those days, you had to do a lot, with a little, almost like programming procedure algorithms that create masses of data, or structure, from very little input (because it's expensive to store). You remember how in the late 90's or 2000's everyone was saying how the next wave of graphics would store a procedural representation of a tree and the algorithm would create the tree? Programming back in those days used those tricks a lot.

Email is a good example, instead of clearly marking out and encapsulating the information, giving proper access through an API, etc, etc, you got a raw chunk of data, some "line ending" issues to delimit data and "boundary" tags to mark out things, as well as other fun stuff.

This is great when you are building email in the 80's, because you only had 4Mhz to program with and 4KB of memory. But now, we have a lot more and all of it is being used to harm the environment than actually process things, thats why Intel now puts so much effort into making sure that Idle, means 0% utilization, not 5% utilization, because 5% of 3Ghz of power, is quite a lot of waste.

But now, we have all this tech, it might be better, to progress further than email, with a new spec that basically cleans up everything for the new age. THIS would be the future, not some crappy Python email server that does the same things as all the others. Or things in slightly different ways.

What we need, is a new protocol, same rules, different implementation and this time, no "write your own API", what we need, is a protocol and a base implementation, as well as a comprehensive API that can be called to perform actions on ALL parts of the email and management system that is required also.

What I would hate to see, are 1000 libraries for the new system that provide the same thing, just written differently. For example, PHPMailer was the tool of choice I had until I figured that there was a better one, SwiftMailer. Why doesnt PHPMailer support creating BCC addresses on linux, only on windows??? Isnt the whole point of these library to abstract away the platform and even language (to a degree).

What I would like to see, please dont think so hard about the "waste" but about obtaining the perfect representation, would be like an XML system, where messages were written in XML, using normal XML to markup the document and then sending it onto the next one. You could even decode that XML into normal Email to support a gateway with the outside world, as well as import and encode into XML where an email from outside is sent to your system.

Clients would be easier to write, because XML libraries are everywhere and mostly just work, there would be no guessing how to encode attachments, how to read line endings, reading until you hit the MIME boundary message, etc, etc, it would all be nice, packaged up and structured.

Hmmmm, now that I think, maybe I used described a cut down jabber server???

But anyway, I digress, Zed Shaw is a Gook, everyone knows it, he hasnt built anything impressive really, nothing to see here, move along.

This is a framework for applications ? I dont see a fully fledged smtp server here at all. Its is something sorely needed though as many programmers dont seem to understand SMTP.