Review Requests [LWN.net]

Review Requests

Posted Jun 17, 2004 7:11 UTC (Thu) by larryr (guest, #4030)
Parent article: The Grumpy Editor's guide to mail clients: introduction

I do not have a mail client I feel ready to commit to. I have been keeping my eye out for something which conforms to my idea of

Standalone Application(s).
Feature rich and configuration/interoperability friendly.
Substantial user/developer base.
GPL, BSD, or similar license.
Runs on Linux/Solaris/OSX and Windows (natively or via Cygwin).
Likely to be updated and improving for years to come.

And of the maybe a dozen which satisfy a few of those, I only feel these are at all auspicious:

I left out Evolution because I expect it to at some point in the not too distant future to be orphaned and not have a community developer base to update/improve it.

Currently for my main mail handling I use standalone programs to pull mail into Maildirs (mutt as simply a fetchmail equivalent because I hate fetchmail), send message files (qmail-inject), view and compose simple plain text email (vim), view HTML emails (lynx -stdin -dump). For MIME encoded messages I may use mimencode to unencode base64 or quoted-printable messages, or munpack/mpack to split/join a multipart message into its constituent parts. Of course to make this approach efficient requires some scripting, it is not a complete outofthebox solution to just use these programs.

To peruse my new mail, I use mutt in readonly mode. If I want to search, I can use find, grep, xargs, etc, and produce as output a list of filenames which I can then link to from a temporary Maildir with symbolic links to the files which matched, so the search results are just a plain Maildir as much as anything else, and I can just "rm -r" when I am done with them.

(Log in to post comments)

Review Requests

Posted Jun 17, 2004 9:04 UTC (Thu) by njd27 (subscriber, #5770) [Link]

I left out Evolution because I expect it to at some point in the not too distant future to be orphaned and not have a community developer base to update/improve it.

What a strange thing to say. Are you saying you think that Novell will go out of business? Are you saying you think that all the hackers that work on Evolution will suddenly vanish?

Review Requests

Posted Jun 17, 2004 15:51 UTC (Thu) by larryr (guest, #4030) [Link]

Are you saying you think that Novell will go out of business?

I think before they go out of business they will decide not to put much effort (money) into improving Evolution.

Are you saying you think that all the hackers that work on Evolution will suddenly vanish?

I think the amount of effort going into Evolution will diminish to the point where other applications are clearly better as mail clients (MUAs).

Essentially I think of Evolution as a commercial product, not a community product, regardless of price/licensing, and that eventually no company will be willing/able to fund developers enough to keep it competitive.

Review Requests

Posted Jun 17, 2004 15:56 UTC (Thu) by smoogen (subscriber, #97) [Link]

No he is saying that Novell will focus on other parts of its business, and even with all of SuSE and others.. there are only so many engineers and too many other parts of a 'desktop' strategy that needs to be developed.

EG They cant do everything...

fetchmail

Posted Jun 17, 2004 15:31 UTC (Thu) by rfunk (subscriber, #4054) [Link]

As part of the team working on reviving development on fetchmail, I'm
interested in why you hate fetchmail.

fetchmail

Posted Jun 17, 2004 16:31 UTC (Thu) by larryr (guest, #4030) [Link]

I'm interested in why you hate fetchmail.

Put succinctly, because I think it does not make simple things simple. For example I would expect what I consider to be a trivial thing, get new messages from a POP account and put them into a Maildir, to be trivially simple, essentially something like
fetchmail --mailbox /my/maildir/path/ pop3://username:password@host
For me, getting fetchmail to do this was far from trivial, but then I have to admit I do not find the fetchmail user interface (command line options and configuration file) to be at all intuitive, so I may not be understanding. I found that fetchmail did not seem to be happy about running multiple instances at once, about delivering directly to a Maildir, about having multiple independent POP accounts on the same host, and about running without a configuration file, all things which I think should just work right out of the box for a program called "fetchmail".

fetchmail

Posted Jun 17, 2004 18:31 UTC (Thu) by rfunk (subscriber, #4054) [Link]

Thanks, that's good to know. Some of the developers (including me) share
at least some of your concerns, so I think things may improve a bit in
the future. Probably not in the next release, but possibly after that.

fetchmail

Posted Jun 17, 2004 21:28 UTC (Thu) by lakeland (subscriber, #1157) [Link]

While I've got a developer listening... ;-)

I run fetchmail systemwide to get mail from my backup MX. The only way I
found to do this was to add a new user to my system, and add fancy a
procmail rule for forwarding the mail on. Fetchmail
supports /etc/fetchmailrc, but that file does not appear to allow delivery
to more than one user??

My solution works perfectly, but I think it is
ugly and it was a pain to set up. Anyway, I'm not sure how many people
are in the same boat -- most people
nowadays are probably are sitting on single user systems.

fetchmail

Posted Jun 17, 2004 21:49 UTC (Thu) by rfunk (subscriber, #4054) [Link]

It sounds like you might want multidrop mode. Search for that phrase in the man page and see if what it says there helps.

If that doesn't help, post your intentions and configuration to the fetchmail-users@lists.berlios.de mailing list.

fetchmail

Posted Jun 17, 2004 21:55 UTC (Thu) by lakeland (subscriber, #1157) [Link]

Cool, thanks :-)

Fetchmail is ... unfortunate.

Posted Jun 19, 2004 17:58 UTC (Sat) by bronson (subscriber, #4806) [Link]

Its config "language" is an excellent example of overly-complex geekiness. A few years ago I wrote and supported Trestlemail, a wrapper for Fetchmail. Easily 80% of my support questions were due to confusion with Fetchmail's config syntax and cryptic errors, not due to anything in Trestlemail. It wasted a lot of my time. All you need to do to fix this is to adopt a nice traditional config file format, something like "server=www.host.com user=me pass=hiho options=fetchall". It would take less code and a lot less documentation. For some reason, though, ESR still thinks that Fetchmail's UI is really groovy.

Have you noticed that Fetchmail has had an amazingly poor security history for such a simple program? This isn't too surprising: the code stinks. It's the groaning result of years of accretion. I am convinced that it would be easier just to do a ground up rewrite than actually try to fix it and audit it.

I recommend that people look to pretty much any alternative (Charles Cazabon's getmail is my favorite) before they resort to Fetchmail.

... in my opinion, of course. :)

Review Requests

Posted Jun 17, 2004 21:40 UTC (Thu) by lakeland (subscriber, #1157) [Link]

Personally I love the kmail in KDE 3.3. It seems the bugs in disconnected
(cached) IMAP have finally been ironed out. I honestly can't think of
anything I'd improve. <thinks> Ok, no blocking when calling external
programs/proper threading... and now the bugs in IMAP have been fixed I'd
like it made fast again (without reintroducing the bugs). But it is
pretty near perfect :-)

As for the others, I use mutt whenever I don't have X; it works well. I
tried kmail with aalib once -- I was surprised by how well it worked but
soon went back to mutt. Thunderbird is pretty good too, but I prefer
kmail. I personally dislike evolution, but I find it hard to believe
Novell will drop it like you think.