Weekly Edition
Return to the Front page
| |||||||||||||
The Grumpy Editor's guide to mail clients: introduction
Your editor will have to request some patience, however. A proper review of mail clients will take more than one column, along with a significant amount of time. Those wanting an instant review of bleeding-edge graphical mailers will have to wait a while; this column, instead, will attempt to provide an introduction to the topic by looking at the standards set by MH. MH was, at the outset, different from any other mail client out there, and it remains different. Mail clients tend to be classic examples of monolithic design; everything (one hopes) that a user might want to do with electronic mail is built in to one single, large application. The designers of MH concluded that this design did not fit well with the Unix way of doing things, which is to have a relatively large number of small programs, each of which does one thing well. As a consequence, MH is not one program, but many: the current nmh distribution contains 39 separate utilities. When dealing with MH at this level, the user is never "in" the mail system; instead, all commands are typed directly to the regular shell. The inc command brings in new mail; scan lists a folder; show, next, and prev display individual messages; repl generates a reply; rmm, refile, and others dispose of messages; and so on. There is a command (pick) which can perform complicated searches through folders. All of these commands (and many not mentioned) manipulate a global state, giving the full set the feel of a single, integrated application. MH folders, incidentally, are also unique: they are simply directories containing each message in a separate file. A number of modern mailers support MH folders, though usually not as the preferred format. The result of this organization is that it is possible to build software on top of the MH primitives with great ease. Over the years, developers have created numerous interfaces for MH, including xmh (an old graphical interface still shipped with XFree86), exmh (a Tk-based graphical client), and MH-E (an emacs-based interface favored by your editor). The scriptability of the MH primitives also makes it easy to integrate the mail client into any other task-oriented software that the user may need to run. The availability of multiple interfaces to the same mail system is nicer than one might think. A fancy, graphical interface may be useful when one is in the office and near to the mail system. When one is stuck behind a slow network connection (a GPRS link from a nearby mountain, say), the command line interface may be the only way to work through a batch of mail quickly and with minimum pain. There is great value in not being locked into a single mode of interaction with the mail system. Unfortunately, MH is showing its age in a big way. The nmh effort appears to have stalled for lack of developers; it shows no commits to its repository since 2003; the 1.0.4 release - the latest available - came out in April, 2000. A 1.1 release candidate was posted in January, but nothing has happened since then. There is support for MIME in nmh, but that support is awkward at best. The exmh front end does MIME, but there has not been an exmh release in over a year; it, too, is getting harder to find in distributions. MH works with POP, but there is no IMAP implementation in sight. In general, MH is old, unmaintained, and fading from the scene. This is a shame, because MH got some things right decades ago that modern mail client developers still seem to miss. Your editor does not want to funnel his email into a single-interface black box. He wants to be able to manipulate mail from his desktop, over a modem link, or running through mindterm on a Windows "email garden" system in a remote place. It should be possible to do anything with email - even things that the developer of the mail client might not have thought of. It must be possible to make connections between the mail client and the LWN site code. It should be possible to manipulate messages and folders with shell scripts and programs without great pain. The client should be a powerful tool for working with electronic mail, but it should be just the beginning point, rather than the final destination. Your editor is now shopping for an email client which can replace MH. This process could be a long one; understanding a mail client well enough to write about it takes a significant amount of effort. The process may also require delving into other parts of the larger email system, such as IMAP servers. Watch for a series of upcoming articles over the (northern hemisphere) summer as this journey unfolds. As a down payment, here is a quick look at the MH-E interface. Your editor has used MH-E for years; it does a nice job of combining the power of MH with an efficient keyboard interface and the usual benefits of integration with the editor itself. Your editor has long assumed that MH-E has suffered the same fate as MH; the version shipped with the current GNU emacs distribution dates from 2000. This version of MH-E has many shortcomings; it does not even deal with simple things like mail in the quoted-printable encoding correctly.
On the down side, enough commands have been changed to drive a long-time MH-E user nuts for a while, and the documentation is, um, missing. The default colors show a distinct lack of restraint or concern for human factors. It also has adopted the gnus habit of replacing smileys and such with its own built-in icons - behavior which is amusing for about two messages before you realize you'd rather just see what the other person wrote. Fortunately, this behavior is easily turned off with a configuration option. The new MH-E is apparently slated for inclusion in emacs 21.4. It is good to see that significant work is going into this mail interface; MH-E is too good to allow to slip into obscurity and decay. The fact remains, however, that MH-E is built on a foundation which has not seen any significant maintenance in years. (For more information on the history and philosophy behind MH, see the classic (if quaintly titled) paper "MH: How to process 200 messages a day and still get some real work done," available in PostScript format). (Log in to post comments)
Other emacs mail readers? Posted Jun 17, 2004 2:08 UTC (Thu) by ronaldcole (guest, #1462) [Link] I've used emacs as a mail reader for many, many years if only because I'm lazy and only wanted to learn one set of email commands/key bindings, yet be able to read email on a text terminal or an X terminal. I've tried gnus and vm, and I much prefer vm.
The Grumpy Editor's guide to mail clients: introduction Posted Jun 17, 2004 2:25 UTC (Thu) by ewen (subscriber, #4772) [Link] As another long-time MH user I'm also concerned that it's basically unmaintained and being dropped from various distributions (although fortunately still in the distribution I use: Debian). While MH shows its age in some areas (eg, MIME handling is passable at best, especially once PGP or similar is involved) it's still the most functional MUA I've found for the way I work.I'll be interested to see what else -- if anything -- you find that can adequately take its place, particularly in terms of use from a text console and in having multiple "mail sessions" open at once (I quite frequently have two or more MH commands running at once -- sometimes multiple reply windows, sometimes just viewing multiple messages). Mutt is about the closest I've found to a substitute, but the interface feels restrictive after having used MH for so long. Ewen
mutt c.f. MH: tell us more Posted Jun 17, 2004 5:33 UTC (Thu) by nicku (subscriber, #777) [Link] As a happy mutt user, but with no experience with MH, I am interested to know how you find mutt restrictive. How do you think mutt could be less restrictive? I am just curious, and do not want to start any silly "my mail client is better than yours" discussion.
mutt c.f. MH: tell us more Posted Jun 17, 2004 13:53 UTC (Thu) by mmarsh (subscriber, #17029) [Link] I think the "restrictiveness" that MH users (myself included) feel is not so much specific to mutt, but rather driven by the flexibility of MH. The fact that I can compose a message or a reply and while that's still active check out new mail (or cross-reference another message) is extremely useful, and what prompted me to switch from elm. I've also had situations where I'll be writing a message to a friend, and in the meantime another message comes in that demands immediate response. With a "drafts" folder in MH, this is no problem. Putting aside a message for later is also easy, though I'm sure mutt also has this capability.Granted, some or all of these things can be done with the graphical mail clients. However, if you're using a terminal-based client, it's really tough to beat the level of flexibility in MH, and that flexibility comes from the fact that it's not a single client, but a suite of applications that run on the same directory structure. That being said, MH isn't the only mail software I use. Since my mail has to be fetched via IMAP, I use fetchmail (both at work and at home). At work my script for fetchmail passes the messages to procmail for filtering, and I check the messages marked as spam using mutt. That's mainly because I've had some spam messages cause inc to segfault. Another mail suite I could point out is IM, which seems to be included in mew (at least on RH). It's MH-like, and uses the same directories. It knows imap, though, which is nice, though it doesn't know krb5 in the context of imap. IM and MH are fairly easy to combine -- the only thing I had to do was use "imget" instead of "inc" -- but it doesn't update the MH context, so after getting new mail "curr" isn't updated.
mutt c.f. MH: tell us more Posted Jun 17, 2004 15:29 UTC (Thu) by leonid (guest, #4891) [Link] Putting aside a message for later is also easy, though I'm sure mutt also has this capability.Yup. It's called 'postpone' in Mutt-speak. :)
mutt postpone and remote access Posted Jun 17, 2004 21:34 UTC (Thu) by nealmcb (subscriber, #20740) [Link] I love mutt. I always run mutt sessions within `screen -S mutt` and when I want remote access, I just ssh to my box and connect to mutt via `screen -d -r mutt`One problem with postpone is that when a postponed message is http://groups.yahoo.com/group/mutt-dev/message/12048 I also wish my postponed mail could be handled well by other mailers I also want to pipe the mutt index to a command or save it in a file, but see no option to do that other than doing cut-and-paste on successive pages of the screen output.
mutt postpone and remote access Posted Jun 18, 2004 6:06 UTC (Fri) by leonid (guest, #4891) [Link] Did you try script(1)? It is very useful for saving all sorts of console outputs in the file. I didnt' try it with mutt though.
mutt c.f. MH: tell us more Posted Jun 17, 2004 21:23 UTC (Thu) by ewen (subscriber, #4772) [Link] Because MH commands are run from your normal shell you can easily intermix working with your mail and working on other things. This is both true in terms of individual commands (eg, read mail message, do work to action it, reply to mail message), and also in terms of working with mail messages (eg, using shell commands, or a perl script, or whatever to identify messages to work with). Mutt's tag facility provides some of the later approach, but it's not as easy to do incremental refinement.MH's draft facilities lets you work on multiple (outgoing) messages at once, either in parallel (which I do frequently) or by deferring them for later. You can pick all the deferred replies when you start up again (comp -use N). While Mutt allows you to postpone a single message I've not found a good way to deal with multiple postponed messages in Mutt. You can work on messages in multiple folders at once, or easily interleaved (in Mutt you need to change folders). I do this quite frequently as well. The shell-based nature of MH also allows you to define lots of aliases (and I have as has every MH user I've come across) for various common tasks, to speed up your work. In contrast Mutt's got a fairly fixed set of commands, and the defaults for some commands (eg, refiling messges) are just wrong. MH gives you full template control over display of message headers, and pre-building messages (new, and replies) and per-MIME-type control over what programs are used to display messages. This can be used for quite a lot of flexibility. I used elm for about the first 5 years of my Internet mail usage, and have used MH for most of the last 10 years, and once I got used to MH I found it much more flexible than elm ever had been. Mutt is better than elm in that respect (eg, more external hooks), but still not as flexible as MH. It's just a shame that MH has essentially been unmaintained for the last 6-7 years, and hence it's support for "modern mail concepts" is limited. Ewen
mutt c.f. MH: tell us more Posted Jun 24, 2004 8:04 UTC (Thu) by brab (guest, #14805) [Link] About postponing multiple messages in mutt, I do it all the time. I stop editing the message, hit "q" to abort sending it, and say that I want to postpone it. When I want to resume writing the message, I hit the proper key, and i see a list of messages that are currently postponed.
mutt c.f. MH: tell us more Posted Jun 18, 2004 8:11 UTC (Fri) by Tet (subscriber, #5433) [Link] I am interested to know how you find mutt restrictive.It lacks format strings for fine grained header control, default output formats etc. See mh-format(5). More information can be found in the MH book. For me, these are what really make MH indispensable. That and the ability to read my mail over a 9600 baud ssh connection through my mobile phone (which admittedly, mutt should also be able to do).
mutt c.f. MH: tell us more Posted Jun 21, 2004 12:54 UTC (Mon) by wookey (subscriber, #5501) [Link] 'How do you find mutt restrictive?'.The thing that really irritates me about mutt is its modal interface - i.e. the way I can only edit/view one message at a time and only have one mailbox open. I used to use 'Marcel' on RISC OS and that let me have as many mail folders as I liked open, and as many messages visible as I had room for, but still integrated with my favourite text editor. As synthesis of emails is what I do most of the day, this was great. When I moved to GNU/Linux for mail I chose mutt and generally like it a lot, but to get mail from another message you need to quit editing the current one and postpone it, then open up another and save it somewhere like tmp then go back to the original and read in the other message in order to cut and paste. Also the long delay in switching between mailboxes (Many of mine take >60 seconds to swtich between) makes for real inefficiency when referring to mails in a different mailbox/folder. There may be solutions to these problems - I would love to hear about them. Just being able to 'pre-open' mailboxes would help a lot.
mutt c.f. MH: tell us more Posted Jun 24, 2004 7:47 UTC (Thu) by joib (guest, #8541) [Link] When I moved to GNU/Linux for mail I chose mutt and generally like it a lot, but to get mail from another message you need to quit editing the current one and postpone it, then open up another and save it somewhere like tmp then go back to the original and read in the other message in order to cut and paste.Nothing prevents you from starting another mutt process in another shell. Or if you just quickly want to check a detail in another email, suspending the editor with ctrl-z and then starting another mutt process in the same shell works equally well. I use it all the time. Also the long delay in switching between mailboxes (Many of mine take >60 seconds to swtich between) makes for real inefficiency when referring to mails in a different mailbox/folder. I guess that's a "feature" of the mbox format if you have big mailboxes? mutt also supports qmail-style Maildirs as well as MH mailboxes, which might help? Personally, I save received and sent mail to separate mailboxes, a new file each month (you can do this automagically with mutt). That keeps the mailboxes reasonably small.
mutt c.f. MH: tell us more Posted Jun 30, 2004 18:39 UTC (Wed) by robot101 (subscriber, #3479) [Link] For the sake of completeness, recent versions of mutt support indexing of mboxes, but I've actually just replaced wookey's mail server with dovecot, which keeps its own indices, so IMAP should go a lot faster now hopefully! :D
IMAP Posted Jun 17, 2004 3:33 UTC (Thu) by lakeland (subscriber, #1157) [Link] I'm not going to comment on any email program in particular, but I wouldlike to note that many of the benefits you extoll for mh can be achieved equally in IMAP. For instance, I can get my mail on a standard windows box in an internet cafe using squirrelmail, at a friend's place using outlook, at work using evolution and at home using kmail. From a dialup link I can use both mutt and pine.
IMAP Posted Jun 17, 2004 14:02 UTC (Thu) by corbet (editor, #1) [Link] IMAP does look like it will be a part of the eventual solution. It achieves a nice separation between the storage and presentation levels, and makes it easier to use a wide variety of mail clients.What IMAP doesn't do, by itself, is provide the flexibility of the low-level MH interface. While MH makes it easy, for example, to write shell scripts which do interesting things with messages and folders, IMAP servers have a tendency to lock up mail inside a black box. At that point you are back to the "you can only do what the mail client developer could imagine" mode. One of the upcoming articles, anyway, will likely be a look at IMAP servers. There's a bunch of them out there and choosing the right one is not always straightforward.
IMAP Black box? Posted Jun 17, 2004 15:24 UTC (Thu) by rfunk (subscriber, #4054) [Link] Most of the IMAP servers I'm familiar with use one of the standard mailbox formats. (Cyrus is the major exception. And if I remember correctly its format is fairly MH-ish.)In fact, many of the better ones seem to be maildir-compatible these days. Again, check out my recent writeup on mailbox formats.
IMAP Black box? Posted Jun 17, 2004 21:10 UTC (Thu) by lakeland (subscriber, #1157) [Link] Right, the four IMAP servers I've used have all worked with Maildir (forthree of them it was the default). I've come back to using courier now, it just seemed the others needed manual restarting every so often -- say once a month while courier just keeps on ticking...
IMAP Posted Jun 24, 2004 7:09 UTC (Thu) by cras (guest, #7000) [Link] I've had exactly the same thoughts about scriptability. IMAP isn't very well suited to it by itself. The protocol is too complex to access directly with simple shell scripts, you'd need separate utilities that provide easier interface for it.For example I quite often want to search a message from a specific sender where message body contains specific words. While IMAP itself allows this with SEARCH command, it only gives back a list of message numbers which have to be separately fetched. I can't just do "echo ... | nc imap.server | less". grepping mailboxes directly doesn't work very well either. I'm using Evolution which would allow it with advanced search, but it needs so many mouse clicks that I usually just begin grepping. Fortunately, I've finally gotten my IMAP server's (dovecot.org) internals very flexible. It's no longer limited to only what IMAP can provide, so I can easily do pretty much any kind of mail accessing with it. First I'll add new IMAP extension which allows pipelining commands together, something like: search from "user name" body "text" | fetch body.peek[] This would allow me to do most of what I want. Perhaps the next step would be to create new protocol which allows much easier scriptability.
IMAP and Maildir Posted Jun 17, 2004 3:52 UTC (Thu) by rfunk (subscriber, #4054) [Link] I'd like to echo the opinion that IMAP is a big help in getting to your mail in whatever way is convenient at the time.Also, the Maildir mailbox format has all the advantages of the mh mailbox format (starting with separate files per message), plus more (no locking). And it's supported by more clients -- it's not just for qmail anymore. Check it out. (I wrote an overview of mailbox formats last month.)
IMAP and Maildir Posted Jun 17, 2004 7:29 UTC (Thu) by tzafrir (subscriber, #11501) [Link] For more information/flames on the mh mailbox format:http://www.washington.edu/imap/documentation/formats.txt.html The format itself is still supported by many programs. Notably the c-client library used by uw-imapd, pine and balsa. Another mailer is kmail. BTW: imap is great for saving mail, but what about an addressbook? is ldap convinient enough?
Addressbook Posted Jun 17, 2004 15:28 UTC (Thu) by rfunk (subscriber, #4054) [Link] BTW: imap is great for saving mail, but what about an addressbook? is ldap convinient enough? LDAP is a pain to set up, so I don't consider it convenient. I think there's a way to store addressbook info in IMAP, but I haven't figure it out yet.
Addressbook Posted Jun 17, 2004 21:12 UTC (Thu) by lakeland (subscriber, #1157) [Link] Like you, I haven't got around to setting up LDAP because it seems toomuch of a pain. Most people around here use kaddressbook with fish:// to give easy remote access from anywhere. It seems to work pretty well. Corrin
fish:// addressbook Posted Jun 18, 2004 17:26 UTC (Fri) by rfunk (subscriber, #4054) [Link] When I use fish:// or sftp:// with kaddressbook (KDE 3.1), it lets me doit but warns about multiple simultaneous access to remote addressbook files being bad. I haven't had a chance to check whether that's changed in KDE 3.2.
Address books and other prefs via IMAP Posted Jun 22, 2004 13:34 UTC (Tue) by utoddl (subscriber, #1232) [Link] IMAP is just for mail access. It isn't designed to do address books and store other preferences by itself. What your're looking for is IMSP. Quoting the abstract:The Internet Message Support Protocol (IMSP) is designed to support the provision of mail in a medium to large scale operation. It is intended to be used as a companion to the IMAP4 protocol [IMAP4], providing services which are either outside the scope of mail access or which pertain to environments which must run more than one IMAP4 server in the same mail domain. The services that IMSP provides are extended mailbox management, configuration options, and address books.IMSP was superceeded by ACAP in the mid to late '90s. There's a Cyrusoft Guide to IMSP and ACAP that you may want to look at.
IMAP and Maildir Posted Jun 17, 2004 18:32 UTC (Thu) by cthulhu (guest, #4776) [Link] Color me confused... I thought IMAP was protocol, not an application. Isthere some email client called IMAP? If so, please post a link...
IMAP Posted Jun 17, 2004 20:03 UTC (Thu) by rfunk (subscriber, #4054) [Link] Yes, IMAP is a protocol. It's a protocol that gives full and flexible access to your mail, without needing to download it to a specific client. That means you can use multiple different clients to access your mail.Our Grumpy Editor said in the article that he... wants to be able to manipulate mail from his desktop, over a modem link, or running through mindterm on a Windows "email garden" system in a remote place. It should be possible to do anything with email - even things that the developer of the mail client might not have thought of. It must be possible to make connections between the mail client and the LWN site code. It should be possible to manipulate messages and folders with shell scripts and programs without great pain. The client should be a powerful tool for working with electronic mail, but it should be just the beginning point, rather than the final destination. Well, the IMAP protocol allows all that and more, especially when backed by Maildir mailboxes. IMAP facilitates making your mail program into a tool rather than a mail destination. Perl and PHP have IMAP API interfaces (I'm sure Python does too), making scripting easy. There are many webmail interfaces (mostly written in PHP) that interface to the mail using IMAP.
IMAP and Maildir Posted Jun 17, 2004 21:31 UTC (Thu) by lakeland (subscriber, #1157) [Link] Right, IMAP is a protocol but it is a very flexible protocol which makesour editor's requirements significantly easier. I deliberately did not mention any applications in my post because it is too easy to start a flame ware :-)
Emacs + gnus Posted Jun 17, 2004 3:54 UTC (Thu) by ssavitzky (guest, #2855) [Link] Although gnus is billed as the standard emacs news reader, it's also a mail reader -- basically it makes an MH mail folder look like a news spool directory (which it really does anyway). The preferred backend adds a.overview database so it can track message IDs.
The current version of gnus handles MIME attachments (launching helper apps as needed). There is also a wide variety of backends including an RSS reader and a reader for mailing lists archived on the web. Have to try that soon.
Emacs + gnus Posted Jun 17, 2004 9:52 UTC (Thu) by davidw (subscriber, #947) [Link] I like gnus a lot, but I'm not sure how to integrate it with anti-spam software, and I'm tired of configuring it via elisp. I want a program that mostly does the right thing without needing a lot of twiddling that might result in my mail being erased.
Emacs + gnus Posted Jun 17, 2004 10:49 UTC (Thu) by mwh (guest, #582) [Link] I use gnus for my mail, but I'm not entirely happy about it. It's great, fantastic for mailing list mail, but it's not perfect for personal stuff. I still haven't found something that I like, though. Mail.app is OK for when I'm on OS X.I don't know how do integrate spam filtering into it, but that's because I do my filtering at delivery time (when God intended, etc).
Emacs + gnus + spam filtering? Posted Jun 17, 2004 21:15 UTC (Thu) by davidw (subscriber, #947) [Link] I had the idea that for "Bayesian" spam filtering to work properly, it was necessary for the user to train the spam filter, by deleting spam and flagging it as such. This operation would best be performed in the mail reader itself rather than as a separate option at delivery time. Or am I missing something?
training spam filter Posted Jun 18, 2004 0:21 UTC (Fri) by rfunk (subscriber, #4054) [Link] I do my bayesian spam filtering (with bogofilter) on the server, and whensome spam gets by it I move that message to a special "spam" folder on the server (via IMAP). I have a cron job on the server that goes through that folder every hour to learn about new spam.
Emacs + gnus + spam filtering? Posted Jun 19, 2004 0:52 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link] the user does have to train it, but that training can be done in any number of ways.Popfile is just getting an IMAP module that lets you train (and correct) the filter by just moving messages to the folder they are supposed to be in. this sort of multiple access is one of the big advantages of IMAP (although I will admit that not that many people take advantage of it). unlike the other options you don't even have to have the various pieces on the same machine.
Emacs + gnus Posted Jun 20, 2004 1:21 UTC (Sun) by IkeTo (subscriber, #2122) [Link] The current version of Gnus has all the interfaces and key-bindings for handling spams using various interfaces, one of them internal to Emacs and the others are external programs that you'd use (like bogofilter, spamassassin, etc). Check with it.
Emacs + gnus Posted Jun 18, 2004 19:46 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Yes, I thought gnus was for news. I use it for that, but I use rmail for mail, because I thought I was supposed to. Do you know how they compare?Why does Emacs come with both rmail and gnus (or does it?). And doesn't gnus violate the Unix one-program-one-function law?
Emacs + gnus Posted Jun 20, 2004 1:40 UTC (Sun) by IkeTo (subscriber, #2122) [Link] That "one-program-one-function" does not mean that you can't have alternatives, especially when there is an alternative view of what the functionality actually is.Gnus view Emails quite differently from any other mail software. Everybody else think that Emails are something that you don't want to lose unless you press a command to do so. Gnus views Emails to be similar to News and expires in the same way. You are encouraged to configure it to automatically split mails into many groups, each group expires in a different way. Once you get used to it, you'll find that mails and news are really not very different after all, especially for public mailing lists, mailing lists of the company you're working on, and people who will send you mail for exactly one reason (e.g., your insurance agent). You can say that this is a consequence of putting a round peg into a square hole, but I think otherwise. It gives you a break to have to delete Emails: all you do is to mark it as read (or simply catch up the whole group), the mail will be kept there for a while, and then will disappear by itself when it ages. And you keep mails for mail and news in the same way (using Gnus' "cache" feature), which copy it to a place and still treat it as part of the newsgroup rather than having you to find somewhere to copy to. After using it for I think 3 years, I'm pretty much ruled out from any other mail readers.
Review Requests Posted Jun 17, 2004 7:11 UTC (Thu) by larryr (guest, #4030) [Link] 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
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.
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'minterested 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 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) shareat 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.
The Grumpy Editor's guide to mail clients: introduction Posted Jun 17, 2004 13:07 UTC (Thu) by leonid (guest, #4891) [Link] I have been a happy Mutt user for few years now. Sometimes I try other MUAs just out curiosity, but none of them came even close to replacing Mutt for me.Mutt, of course, is not by any chance a complete solution to all the email tasks. I, myself, use this setup:
Here are Mutt features that I consider very valuable:
I should also mention that Mutt has an excellent documentation shipped with the package. /etc/Muttrc will have all possible options with comments and possible values. There are a lot of patches that add all sorts of wierd functionality to mutt, like support for compressed mail folders, breaking and merging of threads, etc. mutt-users mailing list is also very helpful and fast responding. ... I hope I didn't sound like a sales person from the 50s. :)
Yet another happy mutt user Posted Jun 17, 2004 14:45 UTC (Thu) by vmole (guest, #111) [Link] Two comments:
mutt Posted Jun 17, 2004 15:34 UTC (Thu) by rfunk (subscriber, #4054) [Link] I love mutt, but (last I checked) it doesn't work well for IMAP. It hastrouble handling more than one IMAP server, especially if they have different login info. It also has no mailbox caching, which gets really slow on big IMAP mailboxes. It's great for local mailboxes though.
mutt Posted Jun 18, 2004 1:07 UTC (Fri) by lakeland (subscriber, #1157) [Link] Would a caching IMAP server fix your problems with mutt? It is a nice wayof giving lightning speed to clients that don't support disconnected IMAP.
caching IMAP Posted Jun 24, 2004 18:12 UTC (Thu) by nobrowser (guest, #21196) [Link] Hmm, what exactly do you mean by 'caching IMAP server'? I think thecomplaint was about mutt not caching _messages_, not connections. Which existing IMAP server actually caches messages?
mutt+offlineimap Posted Jun 18, 2004 15:18 UTC (Fri) by vmole (guest, #111) [Link] You might find offlineimap useful. It's syncs (in both directions) between local Maildirs and remote IMAP. This lets you use mutt locally, yet still get a consistent view of your mail via the IMAP server when you need it. Here's a Linux Journal article about it by the author.
mutt+offlineimap Posted Jun 20, 2004 1:34 UTC (Sun) by jwb (guest, #15467) [Link] The author will probably come out of nowhere and flame me, but whenever I see a recommendation for offlineimap, I feel compelled to mention that, on two different occassions, offlineimap completely destroyed all my IMAP mailboxes and forced me to restore from backups. The author seems more interested in writing weird python user interface wrappers than in fixing the architectural defect which allows offlineimap to screw up majorly.
mutt+offlineimap Posted Jun 21, 2004 14:53 UTC (Mon) by BigNachos (subscriber, #1867) [Link] I don't think I've ever seen John flame someone, so I wouldn't worry about that.Have you reported your problems to him? I'm sure he would be very interested to hear about them.
The Grumpy Editor's guide to mail clients: introduction Posted Jun 17, 2004 14:47 UTC (Thu) by rlb (subscriber, #9072) [Link] I'd also suggest trying a recent version of gnus. If you're running Debian "apt-get install emacs21 gnus", and then "info gnus".The standard nnml storage format is similar to what you're used to, but also includes a news style .overview file in each directory to speed things up. Gnus has backends for many other formats too, including mbox, imap, maildir, and slashdot, among others. You might also want to look in to the gnus agent (plugged vs unplugged), pgp handling, mime handling, stackable summary limits (limit to author, limit to...), process marks, attachments (C-c C-a when editing a message), etc. Gnus does handle email in a potentially unusual way by default, but it's not too difficult to change that. For example, you can change it to mark articles as dormant, rather than read by default, when you read them so that they won't be subject to expiry. This presumes that you're using total-expire for the relevant group, which means that read email expires after N days. Given that alteration, then you'll just explicitly hit 'd' to mark an article as read, which will schedule it for expiry. Gnus' normal delay for deleting emails can be handy sometimes, but you can always force an immediate delete if you need to. The only thing I can think of that you might be missing is command line email manipulations, but you can process mark any number of articles in a group with '#' and then most of the default operations will apply to all of the marked articles. You can also set the process mark according to various criteria, and you can always apply an arbitrary function to the process marked articles via M-&. All that said, I'd also note that gnus is probably not for everyone. Anyone who prefers thunderbird/evolution style GUI clients is probably not going to be happy with gnus, and the learning curve for gnus is not nearly as shallow, but in exchange, gnus' flexibility is very high. HTH
The Grumpy Editor's guide to mail clients: introduction Posted Jun 21, 2004 22:20 UTC (Mon) by EricBackus (guest, #2816) [Link] You wrote: Gnus does handle email in a potentially unusual way by default, but it's not too difficult to change that. For example, you can change it to mark articles as dormant, rather than read by default, when you read them so that they won't be subject to expiry. This presumes that you're using total-expire for the relevant group, which means that read email expires after N days. Given that alteration, then you'll just explicitly hit 'd' to mark an article as read, which will schedule it for expiry. Gnus' normal delay for deleting emails can be handy sometimes, but you can always force an immediate delete if you need to. I think you just proved that GNUS is not a good choice for most people. I understand that the concept of expiring comes from reading usenet postings, but it definately shouldn't be applied to email, at least not by default. I've used GNUS before, even for reading email, and it really can be flexible and capable. But it's much more confusing than it needs to be.
The Grumpy Editor's guide to mail clients: introduction Posted Jun 29, 2004 21:53 UTC (Tue) by rlb (subscriber, #9072) [Link] Actually it's worth noting that total-expire is not the default for mail groups, and so a normal Gnus setup won't automatically delete your mail. It will only delete messages that you explicitly mark as expirable.
Mail clients options Posted Jun 17, 2004 18:00 UTC (Thu) by X-Nc (guest, #1661) [Link] For console/terminal mail clients I still like pine. It's really a shame that they have the whole license thing that makes it incompatable with some distros. I've tried mutt and it's an awsome mail app but I prefer the simplicity of pine. I can do all kinds of things in pine but all I really do is read email. All the commands you need are always on the screen and are fairly nmemonic and easy to remember. I don't have the two weeks to dedicate to learning how mutt does it's thing.
Mail clients options Posted Jun 18, 2004 6:10 UTC (Fri) by leonid (guest, #4891) [Link] With 'set help=yes', which is the default, Mutt shows a help line on the screen. It's context sensitive, so you can try following it. :)
The Grumpy Editor's guide to mail clients: introduction Posted Jun 18, 2004 1:59 UTC (Fri) by jayavarman (subscriber, #19600) [Link] Well, maybe you should look at Mew by Kazu Yamamoto, which is, i think, a fork of MH, but which is much better supported. It also runs on emacsen. Worth check it out. Rui
The Grumpy Editor's guide to mail clients: introduction Posted Jun 18, 2004 22:00 UTC (Fri) by mwalls (guest, #6268) [Link] Having converted to mh/sylpheed from auis/andrew, my requirements are relatively simple -a) messages are files. b) folders are directories. c) I don't care if you cheat with a hidden database to keep response times decent, but the mail software must handle rebuilding the database without complaint when it doesn't match the folder. d) mail software must know the difference between unread mail and new mail and allow me to ignore unread mail. e) and have a decent tty client for those times when I don't have my GUI handy. mh/sylpheed just barely works (has problems with idea of unread mail being ignored). So any better suggestions?
There is a nmh replacement Posted Jun 23, 2004 15:37 UTC (Wed) by jordi (subscriber, #14325) [Link] Dear Grumpy Editor, After reading your rant ;) and all the comments posted so far (57), I'm somewhat surprised nobody has noticed GNU mailutils' MH support. Debian users can access this easily: mailutils-mh - GNU mailutils-based MH utilities While the GNU implementation of these utilities are currently lacking some features, I know several people that have already replaced nmh in favour of these and are happy. The biggest feature, of course, is that mailutils are actively developed (in fact, version 0.5 will be released next weekend). The rest of the Mail Utilities suite includes a scheme frontend to mail (guimb), a reimplementation of BSD mailx, pop, comsat and imap daemons and other utilities. I know the latests MH-E releases work well with mailutils, so maybe you don't need to abandon MH after all.
mailutils Posted Jun 23, 2004 15:45 UTC (Wed) by corbet (editor, #1) [Link] I had actually seen references to MH support in mailutils. If you go to the mailutils page, however, it says absolutely nothing about MH support. The online manual is equally silent on the topic. So I gathered that any such support, if it exists, must not yet be ready for prime time.Maybe I'll take another look after the promised 0.5 release. Perhaps some documentation will be included? :)
mailutils Posted Jun 23, 2004 16:10 UTC (Wed) by jordi (subscriber, #14325) [Link] Right, I noticed the webpage doesn't mention MH at all just after posting. This is probably because the texinfo manual has a nice "FIXME" note in the mh section. :) 0.5 will still lack the info docs for mh, but all the utilities seem to have a useful --help switch. I'll see if this lack of documentation can be fixed for 0.6. In the meanwhile, I'll provide some help2man manpages in the Debian package, if I see there's demand.
GNU mailutils 0.5 Posted Jun 27, 2004 22:44 UTC (Sun) by jordi (subscriber, #14325) [Link] Just for your info, it's released. :)
fetchmail Posted Jun 24, 2004 10:10 UTC (Thu) by dunne (guest, #22552) [Link] When fetchmail is used simply to grab all the mail from the maildropand hand it over to sendmail, then in my experience it works fine -- although it's years since I've used it. As other have commented, it's, er, "security challenged", suffers from the "bells & whistles" effect, etc. So, it's probably best to give it the simple task of FETCHING the MAIL from a remote server and leave all the hard stuff to sendmail.
The Grumpy Editor's guide to mail clients: introduction Posted Jun 24, 2004 10:16 UTC (Thu) by dunne (guest, #22552) [Link] On a point of detail, the nmh home page says: "The next release of nmh, 1.1, is nearing completion. Please test So, it does seem that development is proceeding, albeit slowly.
Existing emacs commands Posted Mar 9, 2008 23:44 UTC (Sun) by donwarnersaklad (guest, #50986) [Link] Existing emacs commands. For a single session in RMAIL in EMACS, emphasis, for a single session, what already existing RMAIL or EMACS commands are there to filter all the email in RMAIL with spamassassin headers indicating spam to a separate file that can be checked anytime for false positives?...
Existing emacs commands Posted Mar 11, 2008 19:46 UTC (Tue) by nix (subscriber, #2304) [Link] And Don Saklad, net.legend, hits LWN! Don, you're more likely to get an answer if you ask on a thread less than four years old. As it is only those of us who follow the comments RSS feed are ever likely to see this.
|
|||||||||||||
![[MH-E screenshot]](/images/ns/grumpy/hot-nude-geek-sm.png)