4 ms·

Anyone ever make an email client?

8 points by dustineichler 19y ago

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

ubudesign 19y ago
if you do Java try javamail api
- dustineichler 19y ago
  exactly what i needed. thanks.
bootload 19y ago
"... 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 http://www.livinginternet.com/e/ei.htm To get an idea of how the specifications started - http://www.faqs.org/rfcs/rfc822.html http://www.faqs.org/rfcs/rfc822.html and how they are now interpreted - http://www.faqs.org/rfcs/rfc2822.html 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 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/ http://www.oreilly.com/catalog/python3/ You can download the source examples here ~ http://examples.oreilly.com/python3/ http://examples.oreilly.com/python3/
- dustineichler 19y ago
  great, thanks for the feedback.
nickb 19y ago
Have you looked at Thunderbird? http://www.mozilla.com/thunderbird/ http://www.mozilla.com/thunderbird/ Or Alpine (terminal-based gui but guts are there): http://www.washington.edu/alpine/ http://www.washington.edu/alpine/
- Tichy 19y ago
  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.
omnichuk 19y ago
>>Anyone ever make email client? Nope, I don't think anyone ever has. You should take that idea and run with it.
- dustineichler 19y ago
  i like snarky. thanks, but i meant had experience with.
  - omnichuk 19y ago
    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.
    - dustineichler 19y ago
      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.
marcus 19y ago
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.
- Zak 19y ago
  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.
  - marcus 19y ago
    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.
skmurphy 19y ago
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-conversation 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.
- skmurphy 19y ago
  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-communication/ http://www.techcrunch.com/2008/03/23/a-crisis-in-communicati... second YC thread here: http://news.ycombinator.com/item?id=144127 http://news.ycombinator.com/item?id=144127
henning 19y ago
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.
pierrefar 19y ago
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 http://www.faqs.org/rfcs/rfc1958.html Everything else will fall into place.
EastSmith 19y ago
For desktop (Windows): yes. I've used Delphi + Indy components
bprater 19y ago
Find and follow the RFCs related to email.
dazzawazza 19y ago
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.
ducky 19y ago
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 http://www.emailoverload.com/philosophy/PerfectClient.php If you want to check out my book online, see http://emailoverload.com/eudora/html/index.php http://emailoverload.com/eudora/html/index.php for the Eudora 5 version and http://emailoverload.com/outlook/OEO-O.complete.pdf 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!

8 points by dustineichler 19y ago

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

ubudesign 19y ago

if you do Java try javamail api

dustineichler 19y ago
exactly what i needed. thanks.

bootload 19y ago

"... 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 http://www.livinginternet.com/e/ei.htm To get an idea of how the specifications started - http://www.faqs.org/rfcs/rfc822.html http://www.faqs.org/rfcs/rfc822.html and how they are now interpreted - http://www.faqs.org/rfcs/rfc2822.html 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 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/ http://www.oreilly.com/catalog/python3/ You can download the source examples here ~ http://examples.oreilly.com/python3/ http://examples.oreilly.com/python3/

dustineichler 19y ago
great, thanks for the feedback.

nickb 19y ago

Have you looked at Thunderbird? http://www.mozilla.com/thunderbird/ http://www.mozilla.com/thunderbird/ Or Alpine (terminal-based gui but guts are there): http://www.washington.edu/alpine/ http://www.washington.edu/alpine/

Tichy 19y ago
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.

omnichuk 19y ago

>>Anyone ever make email client? Nope, I don't think anyone ever has. You should take that idea and run with it.

dustineichler 19y ago
i like snarky. thanks, but i meant had experience with.
- omnichuk 19y ago
  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.
  - dustineichler 19y ago
    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.

marcus 19y ago

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.

Zak 19y ago
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.
- marcus 19y ago
  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.

skmurphy 19y ago

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

skmurphy 19y ago
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-communication/ http://www.techcrunch.com/2008/03/23/a-crisis-in-communicati... second YC thread here: http://news.ycombinator.com/item?id=144127 http://news.ycombinator.com/item?id=144127

henning 19y ago

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.

pierrefar 19y ago

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 http://www.faqs.org/rfcs/rfc1958.html Everything else will fall into place.

EastSmith 19y ago

For desktop (Windows): yes. I've used Delphi + Indy components

bprater 19y ago

Find and follow the RFCs related to email.

dazzawazza 19y ago

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.

ducky 19y ago

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 http://www.emailoverload.com/philosophy/PerfectClient.php If you want to check out my book online, see http://emailoverload.com/eudora/html/index.php http://emailoverload.com/eudora/html/index.php for the Eudora 5 version and http://emailoverload.com/outlook/OEO-O.complete.pdf 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!