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.
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.
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
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.
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.
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.
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.
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.