begin quoting Lan Barnes as of Thu, Sep 13, 2007 at 11:05:44AM -0700: > > I'm unhappy with how I handle mail. I was happy when I used fetchmail to > bring it local and used mutt/vi, but the server that I used had a crisis > and I've been living with a browser interface ever since that has all the > disadvantages of browser interfaces I dislike so much. > > My mail server supports imap I'm told, and I see the advantage of keeping > mail all in one place so I can look at it from anywhere. Actually, I could > do that before using ssh/putty to get to the home server that I kept it > on.
Have you tried mutt+imap? > I consider mail to be an important service but mail archives to be > semi-disposable. I rarely refer back to them and often can't find stuff I > saved because of topic drift or lousy subject lines. So if I lose a year's > mail, I shrug and start collecting another year's. I archive off each year's mail for much the same reason. I do, however, manage to go back and (sometimes) successfully find old email. > Anyway, MH looks interesting because of the opportunities to integrate it > into just about anything through scripting. I find the separate file for > each message problematic because I know (or think I know) that inodes are I know people who have used, and liked, mh. I have never successfully used it in anger.... elm, then mutt, do the job too well. > finite, at least in ext2/3. Can a Linux box have one mount point with an > unlimited fs (reiserfs?)? I dunno. But if MH supports imap, I suspect that > concern goes away. UNIX systems can mount each partition with a distinct filesystem. You can even use the FAT filesystem, which, IIRC, has no inodes at all. The inode exhaustion problem is often overblown ... and you can monitor all that anyway, so you can tell when it's starting to happen before you get the "cannot create file" with gigabytes of space left, allowing you to fix the problem at your convenience. > Or I could just go back to my old way. > > Just musing. Don't worry. Be happy. -- Always measure before optimizing. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
