blogrium

I’ve mentioned Mailhook a few times, but I haven’t spent a lot of time writing about it. Let me introduce it to you properly:

Mailhook is the easiest way to accept email in your web apps.

Using Mailhook, you can receive email directly into your scripts and applications as easy as handling a form post. This means that you have no excuse to not have an email interface to your application.

At a high level, you can think of Mailhook as an email to HTTP adapter. We receive the email and pass it to your script via HTTP. All you have to do is make the script, hook it up, and you’ll be ready to accept email in your application.

No more scary Sendmail configurations. No more complicated mail parsing. No more extraneous polling of mailboxes.

From a developer standpoint (hell, sysadmins too), the email system we have sucks. It’s no fun to work with and nobody wants to deal with it. However, it’s probably the most standard, well-known and commonly used interfaces from an end-user perspective, making it a powerful tool if taken advantage of. Mailhook makes email suck less.

I want you to use Mailhook to expand the ways your users can interact with your web applications. I want you to build new applications entirely based on email. I want you to use it in some amazing way that I didn’t think of.

When it’s this easy, all you have to worry about is coming up with cool ways to use email as an interface.

Even if just as a stopgap, Mailhook can help bootstrap your development, instantly giving you a working email interface.

But enough convincing it’s a good idea. It is. Let me tell you how it works now.

You come to the site and put in the URL of a script. You hit the button and we give you a unique subdomain of mailhook.org, which is a mail host that essentially maps all incoming mail to your script.

Now, obviously, you don’t really want your users to be sending mail to some address at xyz.mailhook.org, you want them to be sending to some address at yourapp.com. In that case you just have to set up an MX record for yourapp.com to xyz.mailhook.org and you’ll be good to go!

But wait, what does it look like to your script? Well, this is still likely to change a little, but when we receive mail, we post to your script passing all the important fields of the email as post variables.

You can expect to get a “to”, “from”, “subject”, “body” and soon an array of headers in “headers” as well as an array of attachments as post variables. In fact, the attachments will look like file uploads, so you can use whatever file upload infrastructure your CGI library uses to handle them. In PHP this is super easy.

For the most part, and this is one of the great benefits of web hooks, you can see what we give you with about one line of code that mails yourself the post data. Attachments might not show up because of the way file uploads are handled, but otherwise it’s that simple.

Actually, I’ve been a little misleading. Attachments won’t show up at all right now because what’s online at mailhook.org doesn’t support attachments because I haven’t finished writing that yet.

That’s where you come in. You need to use what’s up there and tell me what you think. I want to hear wacky ideas for ways to use Mailhook. And most importantly, nag me to finish it!

Or you can get active and help me finish it. I set up a project at DevjaVu (where else?) where you can see the code and contribute to the project. There’s also a Google Group mailing list to talk about development and support.

So yes, I hope you like it and that it helps you make something cool!

This entry was posted on Thursday, January 18th, 2007 at 8:09 am and is filed under Web, Development, Projects. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.