

Anyone ever make an email client? - dustineichler

Where should i start. I interested in making a new application client. Thoughts?
======
skmurphy
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...](http://www.43folders.com/2008/03/12/patterns-email-
conversation)

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
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...](http://www.techcrunch.com/2008/03/23/a-crisis-in-
communication/)

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

------
bootload
_"... 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/>

~~~
dustineichler
great, thanks for the feedback.

------
ducky
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!

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

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

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

------
nickb
Have you looked at Thunderbird? <http://www.mozilla.com/thunderbird/>

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

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

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

------
omnichuk
>>Anyone ever make email client?

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

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

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

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

------
bprater
Find and follow the RFCs related to email.

------
ubudesign
if you do Java try javamail api

~~~
dustineichler
exactly what i needed. thanks.

