Talk:Comparison of e-mail clients

From Wikipedia, the free encyclopedia

 This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion.
??? This article has not yet received a rating on the quality scale.
??? This article has not yet received an rating on the importance scale.

Contents

[edit] List of Features

The comparison as it stands today is of limited use since only a small number of features are discussed and the differences appear only minor. A lesser problem is the limited number of mail clients listed. Linux Weekly News made an overview http://lwn.net/Articles/72937/ that should give ideas on useful features to list. It will be also useful to add in which version the feature was introduced.

Someone has just placed half a dozen new columns in the 'features' list. Some are probably useful, some look redundant, and the are all unreadable at the moment. Any thoughts on how to group them? DStaal 14:51, 16 March 2006 (UTC)

This is a great page of data, but to my mind the level of detail obfiscates its meaning with regard to my interest, which is deciding which client i should get ... I just wonder if there was somebody competent at this sort of thing, who was able to edit it so that one could systematically hide aspects (I mean, rows or columns) of it as a reader decided they were irrelevant and cluttering up his simple picture of the world? i.e. if a feature is uninteresting (e.g. "server capabilities") or of great interest (e.g. "free"), it could be excluded, and if a particular client or operating system had already been rejected, it could be removed from the screen. It occurs to me that this might seem to fall outside the mandate of the wiki, but perhaps it shouldn't: I'm thinking information analysis (data mining?) is what I used the wiki for all the time. User:Obiter 19 jan 2007
Why isn't spell check listed? -I ought to get a user name...

[edit] Mailody?

I went to this page to find out some information about the "darling of the moment", Mailody but no one seems to have added it yet. If someone has used this client and knows a bit about it, can you please add it in?

I have even heard it may eventually replace Kmail in Kontact, though it is an IMAP-only client at this stage, with no plans by the chief developer to add POP3 support. Thanks. 211.26.1.6 05:17, 10 August 2007 (UTC)

[edit] POV security comparisons

I think these "security comparisons" were really only added to bash an MS product. First of all, it is misleading to use vulnerability counts as a measure of security. This is an encyclopedia and really, adding such a vuln count would require too many qualifications regarding what they mean to the point where it would become meaningless to include. Second of all, these vulnerability counts are just flat out WRONG. The search engine for bugtraq, when you select by vendor and product name, doesn't work that well for a lot of products. You need to do a keyword search. A simple keyword search for "thunderbird" or "The bat" reveals many results. See this advisory as an example of an "extremely critical" vulnerability in Thunderbird.—Preceding unsigned comment added by Ptomes (talk • contribs)

Have to agree with the vulnerability table is VERY skewed against MS
I agree the table is somewhat biased, as the clients in first place proablly do have security vulnerabilities that are unknown because they are not frequentlly used. So the chart becomes a inverse listing of how frequentlly a client is used. Lotu 23:17, 25 February 2006 (UTC)
Well, I guess the reason that a lot of clients don't have security bugs is because they have a lot of security releases and don't recycle version numbers. We are comparing Outlook Express 6 with Mutt 1.4.2.1/1.5.11 for example; we cannot determine if certain security bugs are already fixed. --EdSchouten 14:26, 18 March 2006 (UTC)
What about deleting this complete vulnerability section (table) entirely? --Maxim Masiutin 18:37, 29 September 2006 (UTC)
Based on the above opinions, I have deleted this section entirely. --Maxim Masiutin 21:21, 3 October 2006 (UTC)

[edit] Merge from List of e-mail clients

Object: Support: The two articles offer different information. All of the clients in the list are not included in the comparison (unfortunately) and are also categorized. Note that several other comparisons and lists are separate as well such as Comparison of web browsers/List of web browsers and Comparison of media players/List of media players. It is odd that the person who requested the merge, and therefore opened this discussion, didn't even feel the need to state their reasoning here. --Kamasutra 06:17, 20 February 2006 (UTC)

The purpose of a merge would be to put all of the clients into the comparison, which could be categorized the same way as the list (if appropriate). If the comparison did have all of the clients which were in the list, in the same categories, wouldn't the list be redundnat? See also Wikipedia:Articles_for_deletion/List_of_image_viewers for precedence. If we don't merge the two, I'd like to replace this list with categories (which also has precence).
I proposed the merge (as I did for ~1/3 of the lists, many of which I started to clean up (rming entries which had articles AfDed, red-linking articles, and rming many external links). Sorry for not piping in with my reasoning sooner. This list is fairly well-maintained, but I think it offers nothing that categories and/or the comparison would be able to (and the merge tag provides motivation to add a few more clients to the comparison article). --Karnesky 12:59, 23 February 2006 (UTC)
If you are personally willing to categorize and add all of the missing entries and their information, or find someone who will, then I do not object. The problem I find is if they were "merged" and the comparison remained incomplete as the unmerged ones I've cited. I almost always use webmail, so I'm not one to contribute much to this article. However, it would be nice to see it nearly as robust as the web browsers' one, not only in clients but also in comparison attributes. I'm all for redundancy removal as long as they are truly merged and no other information is lost. --Kamasutra 17:00, 23 February 2006 (UTC)
I am willing and do plan to
  • Improve categorization, based on what the software lists have dictated as useful
  • Add more entries (with info) to the comparison pages.
Obviously, this is a good amount of work (and I'd welcome help). As long as the majority doesn't object to this kind of FULL merge of the list to the comparison page, I think it is worth working on & worth leaving the merge tags up so others might also be inclined to help. --Karnesky 18:10, 23 February 2006 (UTC)

Object: From reviewing the List... and Comparison... articles referenced above by Kamasutra, I presume their separation by category was in anticipation of the articles becoming particularly long and unwieldy. Looking at the Comparison of Web Browsers in particular, it is far more robust than the Comparison of E-Mail Clients, comparing several more categories of features than the latter. Assuming that the Comparison of E-Mail Clients will be expanding (e.g. to include comparisons of encryption integration, message managment, etc.) then the separation of the List from the Comparison remains in order. --Theaphro 03:54, 22 February 2006 (UTC)

Would you object to using categories instead of the list? Categories would be more maintainable and more useful than the list. I personally think that the comparison would be able to support every client in this list. Even if it can't, I don't think this list is as useful as is claimed. --Karnesky 12:59, 23 February 2006 (UTC)
No, Lists have a different purpose than Categories. Categories only work for clients with an existing article. That's why it is common to have red links in lists.--Hhielscher 13:57, 23 February 2006 (UTC)
But there are other ways to request articles. Also, red links have systematically been removed from this particular article. The removal isn't something I really agree with (particularly for otherwise notable clients (such as Mahogany)), but your argument is moot for the way this list has been maintained. --Karnesky 14:28, 23 February 2006 (UTC)
This is User:Sleepyhead81 who seems to be removing red links from lots of articles. --Hhielscher 14:57, 23 February 2006 (UTC)
Sleepyhead81 works for a firm whose article was deleted, and the redlink expunged from a load of other articles to which he'd added it. But as it happens I agree with this action, per WP:NOT (a directory). I also strongly support the removal of weblinks from these articles, we're not here to boost pageranks either. Just zis Guy you know? 16:14, 23 February 2006 (UTC)
First, there have been all red links removed, not one. Second, even WP:NOT agrees that Lists are part of wikipedia. Personally I am also removing weblinks (or am moving them to the appropriate article if the page has not previously been linked) if there is an article. But I think it is ok to leave a weblink next to a red link to give a starting point for further research. Furthermore I do not think that Wikipedia should care about pageranks at all—Wikipedia is not a search engine.--Hhielscher 17:32, 23 February 2006 (UTC)
  • Strongly support as it is a good way of making list articles more encyclopaedic. Of what encyclopaedic value is a bare list of email clients? A comparison table with platforms and other information is so much more useful! Just zis Guy you know? 13:23, 23 February 2006 (UTC)
  • Strong Support per karnesky and karmasutra --Quiddity 23:58, 24 February 2006 (UTC)
  • Strongly Suport: The list and the comparision should defintally be together becase one is a subset of the other. If any thing is in the list that is not in the comparion it should be added.Lotu 23:13, 25 February 2006 (UTC)
  • Object:It really is fine and easy the way it is, and I do not think it would be any better. ~Linuxerist L / T 22:59, 12 March 2006 (UTC)
  • Strongly support: When all clients are in this article, users are more likely to add more bits to the table. --EdSchouten 12:12, 25 March 2006 (UTC)
  • Strongly support: Most importantly, I opened BOTH of these pages in different tabs anyway and read them both. I was looking for a way to find a list of e-mail clients that fit my certain list of salient characteristics, and in so doing, I was successful. I think most people will find both of these listings and read them both anyway. My point: why not? 66.233.125.65 03:15, 6 April 2006 (UTC)Nathan
  • Object: I find the Comparison of E-Mail Page confusing - and the information is presented in a format that I personally find very un-useful. The List of E-Mail Clients is far more useful because it is simpler and allows faster comparision of simmilar clients (i.e. you can view one list of simmilar clients at a time). MatthewKarlsen 06:39, 16 June 2006 (UTC)
see my comment above under 'list of features', regarding making columns or rows invisible at the users fancy --User:Obiter 19 jan 2007
  • Strongly Object: Sometimes you want a full table with a comparison of features, sometimes all you want is a list so you can go to the individual entries for each of the clients you're interested in. In the latter case then an unwieldly table gets in the way. Think of it as an index to relevant articles. If by any chance it does get merged then I hope that someone will go through every client mentioned on the list and make sure they're fully marked up so that the category page can be used as the list is used now? Not sure where that would leave clients without articles though... sheridan 02:23, 6 September 2006 (UTC)

[edit] Open Sourciness?

On the Comparison of web browsers page, the consensus was that open source can't be counted as an advantage. Someoneinmyheadbutit'snotme 02:42, 3 May 2006 (UTC)

But, per most other comparisons & per talk on the template pages, green doesn't denote an advantage--it merely denotes "yes." --Karnesky 00:22, 13 March 2007 (UTC)

[edit] Webmail clients

I'm not sure whether webmail clients/frontends should be listed in the presence of these applications, but perhaps a page forked from here showing webmail clients such as SquirrelMail, RoundCube, and perhaps more commercial examples as GMail, Hotmail, YahooMail, and Exchange OWA... though those also include storage whereas the first can act simply as a client via imap/smtp.

[edit] SMIME and PGP should only track native support

The entries for S/MIME and PGP support are very questionable. There is a big difference between a mail client that offers native support for security and one where it is provided through a plug-in. Plug-ins are a bitch to maintain and effectively preclude most enterprise deployments. Most individual users never know they exist.

This is important because if I send an S/MIME signed message there is a very high probability that the recipient will have an email client that is capable of reading it and verifying the signature. The same is not true for PGP. Practically any client with an extension interface can be made to do either. We could easily lose the OCSP/CRL entries which I suspect are wrong in any case (Outlook and Outlook express will both use OCSP if the base Windows O/S is configured for OCSP checking. --66.31.39.76 00:53, 29 December 2006 (UTC)

Some plugins, such as enigmail for Mozilla's products, are VERY tightly integrated & still warrant a mention. I think we should keep the convention of separating those with built-in support (green yes) from those with support through extensions (yellow yes with a note about the extension(s)).--Karnesky 01:55, 29 December 2006 (UTC)
I agree with Karnesky. Probably a better example is Mulberry: it has plugins for GPG and PGP, but the plugins are developed by the application author and distributed with the application. The main reason for having them as plugins is historic: The US used to have rules saying that encryption products could not be exported. At that time the plugins were a seperated download, and you had to agree you would not break US export laws. Other email clients probably have similar setups, where the current archetecture is based on old legal requirements. DStaal 14:50, 29 December 2006 (UTC)
Actually, I think Mulberry is a special case. It ships with the ability to use the gpg executable. However, it isn't distributed with gpg. This is due to license: gpg is under GPL, and so the code can only be reused in GPL-licensed products. Since Mulberry isn't GPLed, it wouldn't be able to make integration any tighter. --Karnesky 15:08, 29 December 2006 (UTC)

[edit] mbox

I added a column for "Message file format": mbox, maildir or proprietary; which I think is a core matter. The tables have a lot of features that don't mean much to me, but I would like information about abilities to import/export varioius msg file formats, or what tools can convert between what formats. * * * I don't understand the column "Fragmented attachments". If this is what I would call "stores attachments as individual files" it needs to be renamed or footnoted, and should be bumped over near the "Message file format" column. I'm going to copy over some discussion source material, below. 69.87.193.176 16:39, 18 January 2007 (UTC)

Of the most popular and commonly used MUA's out there, here's a breakdown of the mail formats they use:

  • Outlook: proprietary database
  • Outlook Express (all variants): proprietary database
  • Thunderbird: mbox
  • Eudora: mbox (though the RFC-2822 messages inside are not MIME compliant)
  • AOL: proprietary database
  • Mozilla/Netscape: mbox
  • Lotus Notes: proprietary database
  • Mulberry: mbox
  • Pine: mbox
  • Pegasus: proprietary mailboxes
  • Elm: mbox
  • QuickMail Pro: proprietary message files
  • Mac OS X Mail: was mbox until latest release, now proprietary message files
  • Opera: mbox

While there are MUA's that do use maildir, maildir and maildir++ have mostly been deployed on the server side for IMAP mail servers. {end of quoted copy from Talk:Mbox by anon}

Thanks--That's an informative column. We should, perhaps, list what variant of mbox the clients use & also might mention other mailbox formats that clients can use (pine can use mbox, c-client MBX, or mtx. It can access maildir with a patch. Alpine has added support for the new mix format. --~~ —The preceding unsigned comment was added by Karnesky (talk • contribs) 21:45, 21 January 2007 (UTC).
Fragmented attachments = Fragmented messages RFC2046 - 5.2.2.1. Message Fragmentation and Reassembly —The preceding unsigned comment was added by 85.1.225.180 (talk) 22:21, 1 February 2007 (UTC).--85.1.225.180 22:22, 1 February 2007 (UTC)

[edit] data table usability

This is a great page of data, but to my mind its far to much to be useful for my purpose, which is deciding which client i should get ... I just wonder if there was somebody competent at this sort of thing, who was able to edit it so that one could systematically hide aspects (I mean, rows or columns) of it as a reader decided they were irrelevant and cluttering up his simple picture of the world? i.e. if a feature is uninteresting (e.g. "server capabilities") or of great interest (e.g. "free"), it could be excluded, and if a particular client or operating system had already been rejected, it could be removed from the screen. It occurs to me that this might seem to fall outside the mandate of the wiki, but perhaps it shouldn't: I'm thinking information analysis (data mining?) is what I used the wiki for all the time.

I agree. If a column is "Yes" for all the programs than it is redundant and should be deleted. The same for all-"No" column. E.g. if nobody supports CRAM-RIPEMD than we should delete this column, and so on. --Maxim Masiutin 13:31, 5 February 2007 (UTC)

[edit] Editing this page

May I request when people are editing this page that they always state what program their changes refer to in the 'Edit summary'. With most of the data contained in tables it is a nightmare knowing what every change refers to when all you see is ((yes)) Dsergeant 18:09, 10 February 2007 (UTC)

[edit] server side spam filter in a client?

I think that column is misleading and confusing. That implies that the "client" is what runs the spam filtering on the "server". That confusing. There is a number of clients that read the X-Headers from spam filtering software and use them in their own filtering if they have any. Some clients allow you to adjust the spam filtering controls on specific servers (Outlook/Outlook web access + Exchange or GroupWise Client + GroupWise for example). However when a client is using the basic well known protocols (like IMAP & POP3) they have no influence over what the server does. If no body objects, I come back in a few days and drop that column. ZacBowlingtalk 03:50, 5 March 2007 (UTC)

I had assumed they meant whether the client supported marking mail as spam based on whether a server-side filter had marked it as such. I can see rewording the column, or even adding a note at the end of that table, but I think it is useful information. We should probably clarify, not delete. DStaal 15:55, 5 March 2007 (UTC)

[edit] Eudora First release date

I have been trying without success to verify the release date of Eudora. The oldest archival record of the company home page is dated June 09 1997. At this time Eudora Lite 3.1 had been released but this was not the oldest public release. QUALLCOM support documments trouble shooting steps applying to both 3.x and 2.x versions here. An English version 2.0.x updater for windows stored at their ftp site reports a modification date of October 27, 1994. A file claimed to be Eudora 1.0 for windows stored here reports a modification date of Feb. 02, 1993. While I will not change the date based on these facts alone the evidence seems to suggest an older public release date than 1996.Phatom87 01:27, 12 March 2007 (UTC)

The riddle of Eudora's birth has been solved. 1988 or 1989 original release went commercial in 1991. I don't know where 1996 came from.Phatom87 20:38, 10 April 2007 (UTC)

[edit] mutt & HTML

It's not true that mutt's handling of HTML email is read-only, or if it is, then one can say the same about plain text emails. It will send anything you create with your external editor in the mime type you specify. I changed the cell contents to “external” to reflect that, and also the fact that the display of HTML messages is also handled by an external program. --89.176.54.194 21:57, 14 May 2007 (UTC)

[edit] Google

I think google mail should be added to the comaparison but I don't know enough about it to add it to this list myself. I was wondering if someone could add it. --Jhfireboy Talk 18:24, 5 July 2007 (UTC)

What he said. I kept scrolling through the list thinking Where the @#$% is Gmail? 64.212.128.3 (talk) 21:20, 11 January 2008 (UTC)

Google is not an e-mail client. Gmail offers web-based email services but it's not a client in the sense that you can use it to access an email server (i.e. a POP3 or IMAP server). --Nneuman (talk) 10:10, 30 April 2008 (UTC)

[edit] map.org's list of products supporting IMAP

This link http://www.imap.org/products/ does not (longer?) exists. --213.243.130.27 14:01, 9 July 2007 (UTC)

[edit] CommuniGate Pro

CommuniGate Pro CommuniGate Systems Free {5 user license} GPL

I think that CommuniGate Pro is not GPL as table claims. --213.243.130.27 14:28, 9 July 2007 (UTC)

[edit] Folders in folders

Eudora allows folders in folders. OR, just mail in a folder (mailbox). But, Eudora does NOT allow both mail AND folders to be mixed, in a given directory tree node. Very frustrating. The article does not seem to mention this aspect. I assume almost all other email clients do not have this limitation?-69.87.202.94 11:44, 17 July 2007 (UTC)

[edit] Where is SCALIX email?

Why isn't Scalix included anywhere in this document? http://www.scalix.com/ —Preceding unsigned comment added by 142.46.212.62 (talk) 19:34, 19 September 2007 (UTC)

[edit] Where is Pocomail / Barca?

And I have to wonder why there are so many programs listed that I've never heard of, despite a thorough search for a new e-mail client. I guess that's the downside of this type of website. —Preceding unsigned comment added by 99.231.124.188 (talk) 02:49, 20 October 2007 (UTC)

[edit] Where is Becky! Mail

Why are Becky! Mail not listed here? http://en.wikipedia.org/wiki/Becky%21 http://www.rimarts.com —Preceding unsigned comment added by 87.72.215.200 (talk) 12:53, 31 October 2007 (UTC)

Because no one's spent the time to develop a comparison. Inclusion on a comparison-list is unrelated to notability or importance, only to the interest by a program's partisans Tedickey 13:05, 31 October 2007 (UTC)

[edit] Cost

Any? wtf, should be free? —Preceding unsigned comment added by 193.167.107.251 (talk) 17:29, 17 February 2008 (UTC)

[edit] protocol table sorting

if you try to sort the protocol table, than the table gets mashed up.. Looks like javascript sorting script problem.. —Preceding unsigned comment added by 212.158.147.229 (talk) 12:01, 29 March 2008 (UTC)

What are you talkjing about? javascript? Mabdul (talk) 17:43, 29 March 2008 (UTC)

[edit] Alpine & Pine

There seems to be a disagreement whether Alpine is a web-based email client or not. I don't know Alpine very well but the Wikipedia article on it as well as its homepage only indicate a non web-based version. Mabdul (talk) however seems to insist that it belongs in the section of web-based e-mail clients. Maybe somebody can shed some light on that? --Nneuman (talk) 18:33, 30 April 2008 (UTC)

Same issue with Pine actually. There does seem to be a web-based version of it but it's only "available to individuals associated with the University of Washington (students, faculty, etc.)" (see Pine (e-mail client)). Furthermore Pine "is no longer under development, and has been replaced by the new Alpine client." Therefore I don't think it belongs listed here in the section of web-based clients. --Nneuman (talk) 19:18, 30 April 2008 (UTC)

ok, maybe you're right (i didn't really read the article until now), but why did you delete the alpin of the list instead of adjusting it to another section? Mabdul (talk) 20:49, 30 April 2008 (UTC)
Because it already is listed in the section of text-based clients ... --Nneuman (talk) 09:51, 1 May 2008 (UTC)


Lots of different things here. The old programs:

  • Unix Pine (source available under pine license)
  • PC-Pine (windows; closed source)
  • Web Pine (web-based; closed source, only available to UW)

And the new ones:

  • Unix Alpine (apache license)
  • PC-Alpine (windows; apache license; basically a tweaked version of Alpine to make it easier for windows users to compile and/or to differentiate the binaries)
  • Web Alpine (web-based; apache license; ships with the Alpine source code)

People have used "Pine" and "Alpine" to refer to:

  • Only Unix (Al)Pine
  • Only the desktop mail clients
  • Both desktop clients and the web-based client

Alpine is distributed as source code that can be used to compile Unix Alpine, PC-Alpine, and Web Alpine.

--Karnesky (talk) 00:43, 1 May 2008 (UTC)

Thank you for the detailed information. I'll adjust the corresponding articles. --Nneuman (talk) 09:51, 1 May 2008 (UTC)

[edit] features

[edit] security

The chart should indicate whether users have the ability to disable (or ignore) JavaScript in inbound e-mail messages. For incoming e-mail, a client may:

  • ignore JavaScript completely;
  • have the ability to support JavaScript, but disable this functionality by default;
  • warn the user if an inbound message contains JavaScript, and ask whether it should be executed or not;
  • support JavaScript, enable this functionality by default, but allow the user to disable it;
  • or support JavaScript and not allow the user to disable it.

The first three options are best.

[In software designed for a multi-user environment (especially medium-to-large business), the client may also allow the administrative or "root" user to set the default or to "lock it down."]

69.140.152.55 (talk) 00:21, 4 May 2008 (UTC)

[edit] return receipts

The chart should indicate whether or not the software supports delivery receipts (i.e., the ability to request successful delivery status notifications).

69.140.152.55 (talk) 00:14, 4 May 2008 (UTC)