Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Perfect Email Client?

Posted by ryuzaki0 on from the one-that-doesn't-send-HTML-email dept.

An anonymous reader sends: "Can those who review also design? Trying to practice what it preaches, CNET published this article, a description of the perfect e-mail client. Next up, apparently: hardware and electronics designs."

3 of 425 comments (clear)

  1. stored searches instead of folders by macpeep · · Score: 5, Interesting

    I've been planning an email system that is based on searches rather than folders. The user interface might be "folders" but in reality, each "folder" is actually a search into an email database. This means a number of things. First of all, emails can exist in any number of folders (including no folder at all). Folders can have all kinds of "complex" rules such as "unread emails plus emails that have been read within the last 10 minutes". This would be a kind of "inbox", for example. Then there could be "Today's emails". "Yesterday's emails", "Emails from Firstname Lastname", "Work related email" and so on. Emails can be flagged using filters to help categorizing them. For example you could have a folder "work emails" that simply search for all emails that have a "work" flag set. The work flag would be set when the email arrives by checking if the email matches a set of rules (is from certain people, is to a certain email address, has a certain topic etc.).

    The basic idea is to get powerful email management without having to actually manage "at runtime". Instead, the management happens by setting up folders and rules.

    One implementation idea is to implement it as an IMAP server that one would run locally. That would allow people to use existing email clients with this system. I haven't decided about that yet though.

  2. Can those who review also design? by gazbo · · Score: 5, Interesting
    Frankly no. The majority of the features they list I would turn off (they would have that option, right?) Some are good but obvious (integrate PGP - no-one's said *that* before)

    Some just show that these people do not understand UI design (all powerful right-click. Yup, nice idea, but when you say how many options there are in modern clients, I wonder how you expect them all to fit in a context menu? As an example they give 'send all mail from this user to folder x' Well great, but to be all powerful they also need 'block email from this user','automatically reply to this user with x', direct all email with this subject to x' etc. all in the context menu)

    Overall, a couple of nice ideas, a couple of dumb ideas, and a rehash of some oft-mentioned ideas. Hardly anything groundbreaking.

  3. To busy. Look at kmail. by ddmckay · · Score: 4, Interesting

    The proposed design is way too busy with too many features I'd turn off if I were using it. The ultimate e-mail client IMHO is one that does e-mail, only e-mail and does it well. The ultimate e-mail client needs to:

    1/ Support *all* inbound e-mail standards, pop, apop, pop over ssl, imap, imap over ssl, MicroSoft exchange (I don't want to run Outbreak^h^h^h^h^hlook), etc. I don't want to change e-mail clients to match up with whatever e-mail server is in use where I am working.

    2/ Support *all* outbound e-mail standards, smtp *and* the various authenticated smtp methods. Security matters.

    3/ Deal with *all* content standards, MIME, HTML, etc. and provied fine control over how they are viewed (e.g. no html, html without downloading images, etc.)

    4/ Supports crypography (GPG, S/MIME, etc).

    5/ Message filters. Filter inbound mail, filter on demand, etc. Filter on any header or other part of the message. Filter using external programs like spamassassin, etc.

    6/ A Clean UI. No oversized cute buttons, etc. Let me decide where to put the list of my folders, messages in a folder, etc.

    An example of an e-mail client that's close to ideal for me is KDE's Kmail.