Anyone ever make an email client? | Hacker News Reader

Anyone ever make an email client?

Where should i start. I interested in making a new application client. Thoughts?

Aim for the high end. What would a client look like that allowed you to process between 1,000 and 10,000 inbound messages a day, answering 1-10% of them, in 2-4 hours of clock time. E-Mail is not going away, but the metaphor of the inbox and folders is obsolete and needs to be rethought from the ground up. Here is one place to start: http://www.43folders.com/2008/03/12/patterns-email-conversat...

Please feel free to contact me directly if you would like to continue the conversation. I think this is one area that is overdue for a significant change in paradigm, the evidence that the current approach isn't scaling can be found in every successful blogger who can no longer find time to read and answer E-mail.

More evidence (appears to have been posted after above comment, at least I wasn't aware of it).

http://www.techcrunch.com/2008/03/23/a-crisis-in-communicati...

second YC thread here: http://news.ycombinator.com/item?id=144127

"... Where should i start. I interested in making a new application client. Thoughts? ..."

To learn how email was invented

- http://www.livinginternet.com/e/ei.htm

To get an idea of how the specifications started

- http://www.faqs.org/rfcs/rfc822.html

and how they are now interpreted

- http://www.faqs.org/rfcs/rfc2822.html

and to program a simple client in python read the source code from Programming Python by Mark Lutz ~ http://www.rmi.net/~lutz/about-pp3e.html I mention Python & Lutz specifically because they are covered in detail as a CLI then GUI app in "Programming Python Ed3", pp 766 - 911 ~ http://www.oreilly.com/catalog/python3/ You can download the source examples here ~ http://examples.oreilly.com/python3/

great, thanks for the feedback.

Hi, I am the author of _Overcome Email Overload_, and I watched a LOT of people use email and interviewed them about their practices. I have distilled what I think is needed into http://www.emailoverload.com/philosophy/PerfectClient.php

If you want to check out my book online, see http://emailoverload.com/eudora/html/index.php for the Eudora 5 version and http://emailoverload.com/outlook/OEO-O.complete.pdf for the Outlook 2002 version. (They are very similar, but use different terms and reflect the slightly different features of Eudora and Outlook.)

IMHO, the most important part to read is the beginning of Chapter 2.

I have also written some email clients. I would agree with dazzawazza that you should not try to write your own POP/SMTP/IMAP code. It is really easy to write a simple POP/SMTP email program, and incredibly difficult to write a good email program. (For example: attachments can be recursively nested, yuck! For example: IMAP clients must be able to accept input from the server at any time.)

All the popular languages -- C, C++, Java, Python, Perl, PHP, and undoubtedly Ruby -- have robust email libraries. I wouldn't be surprised if even some of the lesser-known languages like Erlang and Squeak have good libraries as well.

I would suggest building on top of Firefox, GMail, SquirrelMail, or Evolution, depending upon what your goals are. You might also think about contributing to the Chandler project.

Good luck!

It would be ideal if you're a serious email user or you can become one.

Whatever you do, dogfood it. Use it for your day to day email as much as possible as soon as the probability of it losing/corrupting messages is low. If you find yourself going back to your old client, write the code you need to so you don't have to.

Decide what's going to be the most important things about your app and work hard to get those right. All the "it would be cool if.." stuff can wait till later. Only focus on the essence to begin with. Then, release it and see what people think and go from there.

Never built an email client but I used to do my email checking by telenting to port 110 logging in and retrieving the messages.

I think that'll be a great place to start. Learn the protocol and start playing with it directly instead of using an email program.

I don't think any of the common mail protocols are especially complex. If you're trying to do anything interesting with a mail client, it probably doesn't involve doing anything special with the protocols. Find a good library and tweak if you really need to.

I agree that everything he'll need can be found in a library but I believe that you always should get to know the internals of stuff, especially when it is as accessible and easy to learn as SMTP/POP/IMAP are.

That is half of what being a hacker means, striving to understand and tinker with the world&technology around us. It's why most of us took apart watches, radios & computers as young kids.

yes, it was a long time ago though. I used powerplant (old style macos class library from Metrowerks). The best thing was it had classes to deal with POP/SMTP.

What I learned: * don't write POP/SMTP/IMAP - it's been done * don't write for the home user, it's been done (IMHO) * the corporate world loves Exchange and Lotus Notes but they are not ideal solutions so you could look there. You will find it hard to get corporate customers to move from exchange/notes for company email though. * maybe look at customer support systems where emails are handled by many, many people. A lot of them have clever pre processing and flow control heuristics in them. You may have a new angle to help those guys.

The app I wrote was for fun because surely it can't be that hard. Well it was and I was a fool.

good luck.

Have you looked at Thunderbird? http://www.mozilla.com/thunderbird/

Or Alpine (terminal-based gui but guts are there): http://www.washington.edu/alpine/

I always use Thunderbird, but I think where Thunderbird really sucks is the address book and mailing lists management. I am not really a power user for that, but when I tried to use it for mailing list, it was horrible. So there is definitely room for improvement.

The absolute key concept is "Be strict when sending and tolerant when receiving."

It's from RFC 1958: http://www.faqs.org/rfcs/rfc1958.html

Everything else will fall into place.

>>Anyone ever make email client?

Nope, I don't think anyone ever has. You should take that idea and run with it.

i like snarky. thanks, but i meant had experience with.

Sorry, couldn't resist :)

More seriously, if you're looking to invent a better UI for an email client, you might find it easier to build it first as an add-on for Thunderbird. This would get you a working prototype without having to worry about the nuts-and-bolts problems that you'll face if you start from scratch. You could use this to hammer the kinks out of your concept with reasonably little coding effort. Even if you don't want to use Thunderbird in the end, it would help you find out whether your idea will work and if it is worth the effort of reading all those bloody RFCs.

Good point. I was thinking of actually taking the long route and when all I really want to do is integrate new api's. Thanks.