[Rant] The Endless Search for a Mail Client That Doesn't Suck
Brian Nelson
email client out there that, after 30 years, still doesn't suck?
That's a rhetorical question. Anyone who blurts out "Mutt!" gets a
swift kick in the genitals. And if anyone even tries to utter "gnus", I
will beat them with a rolled up newspaper until they say, "No gnus is
*good* gnus" and mean it.
Here's the background to my situation:
I check my email from at least two different computers (a desktop and a
laptop computer) so I use a local IMAP server to access my mail. I've
been using this setup for around 4 years. If the world wasn't such a
cruel place, this would be the ideal setup for the situation.
Back when I started, I was a relatively modest email user. I had fewer
than 10 IMAP folders and was only subscribed to a couple mailing lists.
I started off using mutt, but I immediately discovered that mutt's IMAP
support was laughable, to put it nicely. It was extraordinarily slow,
and had absolutely no support for offline mode, which made it pretty
much useless for my laptop. Nonetheless, I put up with it for a few
months--long enough to learn how to customize it and become comfortable
with it. I was never really happy with mutt, and since I would fire up
emacs to compose mails anyway, I figured I'd give gnus a try.
I discovered gnus had several advantages over mutt. It was
significantly faster at loading folders (since it cheats and only
displays unread mails by default) and had rudimentary offline support.
Also, I didn't have to wait for emacs to load every time I wanted to
compose a mail because it was already there.
Over the years, my email usage has grown enormously. I now have 70 IMAP
folders, am subscribed to around 50 mailing lists, and receive over 2000
emails per day.
Gnus scaled, hmm, OK with this usage. It worked adequately when the
IMAP server was on a local network, but was pretty painful when I was on
the road. I would often read mail too quickly so that gnus couldn't
display the articles. And, due to the single-threaded nature of elisp,
any time gnus was busy doing something like checking for new mail in 70
folders or expiring messages in a very large folder, it would be
completely unusable, often for several minutes. Or, if the wireless
connection on my laptop dropped, gnus would be completely unusable for
10-15 minutes until the connection finally dropped.
Furthermore, I ran into problems with offline synchronization. Even on
a local network, it would take *FOREVER*, skip messages, time out, and
generally fuck up. It was pretty much useless.
I finally became fed up with gnus' IMAP support when I went to Brazil
for Debconf this spring. With my IMAP server something like 10,000
miles away, gnus was completely unusable. Synchronizing folders was
impossible; just trying to read mail in my inbox was a joke. About 95%
of the time, gnus was sitting there unresponsive, busily doing whatever
it does in elisp.
Despite the latency, offlineimap seemed to work OK from Brazil, so I
decided to make gnus switch to using a local Maildir folder. This
seemed like the ideal setup. No more of gnus just sitting there
pondering the meaning of life or whatever when there was a lot of
latency. No more completely broken offline synchronization. No more
retardation when my wireless signal flaked out. I thought I'd *finally*
have an email setup that wasn't constantly pissing me off.
Wrong... So very wrong...
Gnus uses the backend "nnmaildir" for its Maildir support. I can't say
enough bad things about nnmaildir. But, I'd like to try.
First problem: startup time. You might think gnus would be able to
startup pretty damn quickly if it only had to read a local Maildir
directly, right? Well... it takes 5-10 minutes for nnmaildir to
startup, the entire time during which the hard drive is furiously
scribbling its ass off. Really fucking lovely to happen on a laptop,
especially if I'm running on a battery. Here, nnmaildir, have 1 hour of
my battery life. I don't need it *that* badly.
Second problem: nnmaildir's memory usage makes OpenOffice.org look light
and fluffy. On my setup, it takes up, oh, a couple hundred megabytes of
memory. My laptop once had 256MB of memory, so if I started gnus, I was
automatically hitting the swap file pretty hard. I had to buy an
additional 256MB just to be able to do anything else while my mail
client was open. That is seriously fucking disturbing.
The next problem, and this one's a doozy, was its completely
non-standard use of message flags. Instead of appending flags like
",RS" to the message filename (to mark the message as "seen" and
"replied" in this case) like every other fucking Maildir-supporting
email client on the planet, it uses its own, errr, "system". In each
Maildir directory, it creates a ".nnmaildir" directory, which in turn
contains a "marks" directory, which in turn contains directories like
"read", "reply", and "ticked", which in turn contain hard links to the
original message files.
For example, if a mail was marked as seen and replied, you would find a
hard link in .nnmaildir/marks/read/1234 and a hard link in
.nnmaildir/marks/reply/1234, both of which point to cur/1234.
What the fucking shit? That bears repeating: What the fucking shit?
No, seriously: What the fucking shit?
This thoroughly broke synchronization with offlineimap. Offlineimap
would never know a message was read since gnus would never modify the
message flags, so the IMAP server would never know, and thus using
offlineimap from two different computers was useless. Not to mention
checking my mail through webmail when I didn't have my laptop with me...
However, the nnmaildir author insists it's easy to write a script to
convert the .nnmaildir/marks hard links to standard Maildir message
flags. So, I wrote such a script. Here it is, in all its glory:
Alvin Oga
hi ya nelson
On Wed, 4 Aug 2004, Brian Nelson wrote:
> It's 2004. Email has been around for what, 30+ years? Is there an
> email client out there that, after 30 years, still doesn't suck?
it sucks because of "different users" like "different
functions/features/gui"
> That's a rhetorical question. Anyone who blurts out "Mutt!" gets a
> swift kick in the genitals. And if anyone even tries to utter "gnus", I
> will beat them with a rolled up newspaper until they say, "No gnus is
> *good* gnus" and mean it.
i use old-old pine and elm :-) and mutt, so i get double kicked ..
> Over the years, my email usage has grown enormously. I now have 70 IMAP
> folders, am subscribed to around 50 mailing lists, and receive over 2000
> emails per day.
i assume you use different email accounts
brian-deb for debian lists
brian-movie for movie lists
brian-security for security updates
brian-work for work related lists
brian-save for anything you want (forever) saved
and personal emails on a personal server and domain
- lets ignore additional yahoo/hotmail related problems ..
- just more ways to manage your emails ... vs "1 email account"
and at 2,000 emails per day .. consider yourself lucky in th
that you dont get 10,000 spams a day from which to filter out
your "mailing list emails" and real emails from the 90% spams
- a good email client and spam filters won't necessarily solve the
problems of a "good email management methodology" vs depending on 3rd
party automated tools to do "everything"
> Furthermore, I ran into problems with offline synchronization.
if you are using imap, there is zero syncrhonization problems,
as your email and folders are only on the imap server
if you have more than one imap server ... that's a separate issue
to rsync emails and folders between imap servers
( work imap server vs home imap server vs mailing list imap server )
imap is good .... everything is always already syncrhonized ...
imap is bad ..... you have to maintain those large email folders
- simply rotate the ~brian/Mail folders on a monthly basis
( problem is now trivialized )
> Wrong... So very wrong...
yup ... doing things differently or customized adds to the problems
and just recreates the problems people have been trying to fix
for 30+ years ...
not having different email accounts for different purposes is the
first trivial problem to solve ... one acct for one purpose
c ya
alvin
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Gear
> It's 2004. Email has been around for what, 30+ years? Is there an
> email client out there that, after 30 years, still doesn't suck?
> thunderbird? Never tried it, doesn't support mailing lists from what
> I've heard. Most likely also suffers from the horrible editor syndrome.
Just out of curiosity, would you mind defining "support mailing lists"?
I am on a fair few (although i've just switched to using this list via
gmane.org since killing threads is a really great feature that works
more efficiently in news than mail), and i don't find it a struggle to
manage them with Mozilla Mail/Thunderbird
> I guess there's no end for my misery in sight. I hear Donald Knuth quit
> using email 14 years ago. With that kind of foresight, he really *is* a
> genius.
BTW, i really enjoyed the rant. A little too much swearing for my
liking, but the tone was one of good natured frustration with a little
humour thrown in. :-)
--
Paul
<http://paulgear.webhop.net>
--
If at first you *do* succeed, carefully check your success metrics for
accuracy.
Stefan Goessling-Reisemann
Hi Brian,
understand your agony, haven't found the almighty email client, but am
using Pine 4.58 quite happily:
BN> 1. I must be able to customize the order folders, and I don't want to
BN> give them retardedly ugly names to force a correct alphabetic order.
BN> This is very important when you have 70 freaking folders like I do.
The order of the Inboxes can be freely customized. In addition to IMAP and
POP3 folders, any file on the local file system can be an Inbox
BN> 2. I must be able to read the folders sequentially in the order I
BN> specify with minimal pain. Obviously, I read from highest priority
BN> to lowest, since I may not have time to read every single folder. I
BN> don't want to be interrupted while in the sequence, because old mails
BN> in lower priority folders are more important to me than brand new
BN> mails in higher priority ones.
At the end of the current folder press "TAB" and it will open the next
folder and display the next new message
BN> 3. I must have a powerful editor. Emacs is generally my first choice,
BN> but I'd be willing to learn another as long as it could do everything
BN> I do in emacs.
You can choose any editor you like, either by specification in the config
file or by pressing "Ctrl-_" when composing a message (which lets you then
choose an editor on the fly).
BN> 4. It must support Maildir, and must play nicely with offlineimap.
I am told it supports Maildir, don't know anything about offlineimap. I am
using multiple IMAP folders (currently about 15 IMAP and POP Inboxes and
200 folders on an IMAP server for saving and archiving) without any
problems.
BN> 5. It must have a decent summary view. I want to be able to see all of
BN> my folders, the amount of mail in each, and be able to quickly choose
BN> one to view the mail.
At least one of the developers provides patches (which are always updated
for new versions of the programme) for providing additional functionality,
like the summary view you are talking about. Have never used these though!
BN> 6. It must have a decent expiry system.
Don't exactly know what you mean. You can choose messages in a folder
according to several properties (read, new, date arrived, date sent,
number, content, headers, sender, recipient, .....), so it only takes a
few keystrokes to do the expiring. This can partly be automated by
applying filters. I don't know if these filters (which work well for me
for filtering out spam) can be dynamic (i.e. use the current date minus 2
weeks for example as the selection property)
BN> 7. It must not be dog slow. I have big folders and I don't want to wait
BN> 5 minutes to load them.
That very much depends on the speed of the connection. For local files
Pine is very fast, for slow connections, it offers a prompt ("Cancel
connection?") after a user-defined time when it is not yet finished with
downloading/searching/scanning. Still, while busy, Pine is unusable, since
it is also not working in multiple threads. The latter thing can be
annoying when sending mail over a slow link.
One of the most prominent features of Pine (which makes me stick to it
nomatterwhat) is, that you can store the configuration on a remote IMAP
server and never have to worry about synching your settings between
machines. You can use it from wherever you are (providing it is installed,
or you have it on your USB stick [the Windows version runs standalone from
a floppy/CD/USBstick]).
It also supports mailing list management functions.
Some drawbacks:
Searching and selecting over multiple folders is cumbersome and sometimes
faulty. Within one folder, searching works excellent.
The Windows version has (rare) problems with faulty SSL implementation in
Windows (really not a Pine problem).
Navigation in the included editor (Pico) is cumbersome.
Multiple attachments can only be saved one-at-a-time.
UTF-8 is not supported (in Pine 4.58, but I think it has been built into
Pine 4.61??)
You are bound to the charset encoding given in the configuration, no
on-the-fly changing.
Best regards, Stefan (debian @ goessling . de)
PS: More info here: http://www.washington.edu/pine/
Alec Berryman
I think mutt + offlineimap is what you need.
Mutt does native Maildir support, so you won't have to screw with hard
links or whatever that gnus stuff was. Just sync it up normally.
Google for 'mutt header cache' - it's _awesome_. It will cache the
maildir and imap headers so that opening up those mailboxes with 10k messages
is quick. The maintainer of that patch is hoping to get it merged
into mutt, but until then, there's a .deb of the current Debianized
mutt with the patch
(http://wwwcip.informatik.uni-erlangen.de/~sithglan/mutt/mutt_1.5.6-20040722+1_i386.deb).
See the page for instructions on use, and make sure to hold mutt so
the offical Debian package doesn't overwrite it.
I use mutt with emacs's mail mode, and it works wonderfully. I run
screen and pop back and forth between them by setting my editor to be
emacsclient.
Good luck,
Alec
Vernon Webb
I've read that Debain does not get installed with parallel support by
default and has to be enabled at the kernel level.
I'm running the woody version of Debian and am some what new to Debain as
I've mostly used Red Hat and am wondering if there is an easy way on the
first install to enable this option other than building and compiling my own
kernel. Any help would be appreciated.
Thanks
Robert Vangel
Vernon Webb said:
> I hate to keep posting new here, but I'm not getting anywhere.
>
> I've read that Debain does not get installed with parallel support by
> default and has to be enabled at the kernel level.
>
> I'm running the woody version of Debian and am some what new to Debain as
> I've mostly used Red Hat and am wondering if there is an easy way on the
> first install to enable this option other than building and compiling my own
> kernel. Any help would be appreciated.
>
> Thanks
>
>
As root, run "modconf" and go through the menu's to see if there is any module
for parallel ports.
I do not have the stock kernel (or a debian packaged kernel) on my system, so
I do not know for sure if it is there or not. If not, you may have to end up
compiling your own kernel. I would say that it has been included as a module
though (parallel ports are rather common, just not always used).
--
Robert Vangel
* RedFlag LANfest
Network Services Management
matt zagrabelny
> I hate to keep posting new here, but I'm not getting anywhere.
>
> I've read that Debain does not get installed with parallel support by
> default and has to be enabled at the kernel level.
>
> I'm running the woody version of Debian and am some what new to Debain as
> I've mostly used Red Hat and am wondering if there is an easy way on the
> first install to enable this option other than building and compiling my own
> kernel. Any help would be appreciated.
generally the install will also install necessary modules for
everything, you just have to load them.
all of the modules are in /lib/modules/`uname -r`/kernel/
you can use "modprobe <modulename>" to load them. for example "modprobe
parport"
you can list the modules you want loaded at boot in /etc/modules
-matt
Vernon Webb
> everything, you just have to load them.
> all of the modules are in /lib/modules/`uname -r`/kernel/
> you can use "modprobe <modulename>" to load them. for example "modprobe
> parport"
>
> you can list the modules you want loaded at boot in /etc/modules
I was told this as well, however, parport or partport_pc is not in there. So
now what?
Gayle Lee Fairless
port stuff helped. I also went through the packages list for stable on
debian.org and downloaded cups, foosamatic, and a few other things that
looked like they would work with my parallel printer, a HP 697C. The
thing that got it working was using the add printer wizard on KDE. Now I
just need to tweak the right margin to avoid losing the leftmost printed
column. (BTW, how do I do that?)
I have not yet been able to get the HP psc1210 on an USB port working yet.
Anyway, at least I now have the parallel printer responding to lp
commands. I wonder if I need to do anything with lpadmin or lpoptions?
I downloaded a PPD file from a website specifically for the HP 697C.
Also, there are 2 files for the parallel printer. I chose the cdj67
something or other (I can't look because I'm doing this from work.) file
that the KDE printer wizard found. (The wizard gave me a choice of 2
files to use with the HP 697C parallel printer.)
Sincerely,
(Mr.) Gayle Lee Fairless
Linux Gcomm 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 unknown
PS Please CC since I subscribe to the digest and not the list.
Alan Shutko
> Despite the latency, offlineimap seemed to work OK from Brazil, so I
> decided to make gnus switch to using a local Maildir folder.
Did you ever try using Gnus' agent support?
In general, Gnus expects to control everything in its mail backends,
so it's not surprising that it doesn't really sync with other maildir
programs. nnmaildir tries (which is probably why it is so slow) but I
don't think it's the highest on the list of priorities.
--
Alan Shutko <a...@acm.org> - I am the rocks.
Brian Nelson
> Brian Nelson <py...@debian.org> writes:
>
>> Despite the latency, offlineimap seemed to work OK from Brazil, so I
>> decided to make gnus switch to using a local Maildir folder.
>
> Did you ever try using Gnus' agent support?
Yeah, that's what I meant by "rudimentary synchronization support."
> In general, Gnus expects to control everything in its mail backends,
> so it's not surprising that it doesn't really sync with other maildir
> programs. nnmaildir tries (which is probably why it is so slow) but I
> don't think it's the highest on the list of priorities.
It tries about as hard as Microsoft tries to make a secure operating
system...
--
You win again, gravity!
Brian Nelson
> I'm going to get myself kicked in the nuts.
>
> I think mutt + offlineimap is what you need.
>
> Mutt does native Maildir support, so you won't have to screw with hard
> links or whatever that gnus stuff was. Just sync it up normally.
>
> Google for 'mutt header cache' - it's _awesome_. It will cache the
> maildir and imap headers so that opening up those mailboxes with 10k messages
> is quick. The maintainer of that patch is hoping to get it merged
> into mutt, but until then, there's a .deb of the current Debianized
> mutt with the patch
> (http://wwwcip.informatik.uni-erlangen.de/~sithglan/mutt/mutt_1.5.6-20040722+1_i386.deb).
> See the page for instructions on use, and make sure to hold mutt so
> the offical Debian package doesn't overwrite it.
Yeah, I'm aware of the patch. It's been around for many years. It was
originally written and maintained by Michael Elkins, the main author of
mutt, so why it has never been integrated is beyond me.
If that patch were all I needed to get mutt to work the way I want, that
would be fine. Unfortunately, it doesn't solve the other problems I
have with mutt.
Brian Nelson
> Brian Nelson wrote:
>> It's 2004. Email has been around for what, 30+ years? Is there an
>> email client out there that, after 30 years, still doesn't suck?
>> ...
>> thunderbird? Never tried it, doesn't support mailing lists from what
>> I've heard. Most likely also suffers from the horrible editor syndrome.
>
> Just out of curiosity, would you mind defining "support mailing lists"?
> I am on a fair few (although i've just switched to using this list via
> gmane.org since killing threads is a really great feature that works
> more efficiently in news than mail), and i don't find it a struggle to
> manage them with Mozilla Mail/Thunderbird
Basically, I want reply-to-list functionality. Also, it needs to honor
Mail-Followup-To headers.
--
You win again, gravity!
Brian Nelson
> i assume you use different email accounts
>
> brian-deb for debian lists
> brian-movie for movie lists
> brian-security for security updates
> brian-work for work related lists
>
> brian-save for anything you want (forever) saved
>
> and personal emails on a personal server and domain
>
> - lets ignore additional yahoo/hotmail related problems ..
Yeah, I use something like that. Both gnus and mutt can handle that
fine.
> and at 2,000 emails per day .. consider yourself lucky in th
> that you dont get 10,000 spams a day from which to filter out
> your "mailing list emails" and real emails from the 90% spams
Well, I meant 2,000 readable emails per day, which doesn't include spam.
> - a good email client and spam filters won't necessarily solve the
> problems of a "good email management methodology" vs depending on 3rd
> party automated tools to do "everything"
>
>> Furthermore, I ran into problems with offline synchronization.
>
> if you are using imap, there is zero syncrhonization problems,
> as your email and folders are only on the imap server
Hmm? I don't use OfflineIMAP for shits and giggles, ya know. Quoting
RFC 3501:
The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev1 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local
folders. IMAP4rev1 also provides the capability for an offline
client to resynchronize with the server.
--
You win again, gravity!
Joachim B Haga
> Over the years, my email usage has grown enormously. I now have 70 IMAP
> folders, am subscribed to around 50 mailing lists, and receive over 2000
> emails per day.
Perhaps not the answer you want, but have you considered reading the
mailing lists through a news gateway like gmane? (http://gmane.org)
They carry something like 6000 lists currently, and as far as I can
see they are willing to add any list, including automatic ones like
cvs. As long as the list admin is happy with it, anyway.
That would probably take care of most of the 2000+ messages, nntp
would be (I guess) faster than imap, and you don't have to worry about
expiry. And with the right client (gnus :-) you can mix imap/nntp
folder order as you like.
Just an idea.
--
Joachim
Joey Hess
> So now I'm seriously considering going back to mutt, but I just can't
> get into it.
FWIW, my mail setup[1] has evolved to mutt+offlineimap
(+vim+archivemail+cron+grepmail+maildrop+subversion) and I'm pretty happy
with it. The weakest link is definitly mutt.
> I have a few modest requirements that a mail client must meet:
>
> 1. I must be able to customize the order folders, and I don't want to
> give them retardedly ugly names to force a correct alphabetic order.
> This is very important when you have 70 freaking folders like I do.
From my .muttrc:
# Only problem with this is it doesn't find new mailboxes on the fly
# unless I restart mutt.
mailboxes ! `find ~/Maildir/.* -type d -maxdepth 0 -not -name .. -not -name .| xargs echo`
Of course you can expand on this to add whatever ordering you like.
> 2. I must be able to read the folders sequentially in the order I
> specify with minimal pain. Obviously, I read from highest priority
> to lowest, since I may not have time to read every single folder. I
> don't want to be interrupted while in the sequence, because old mails
> in lower priority folders are more important to me than brand new
> mails in higher priority ones.
I can't conceive of reading mail this way (I'm a modal, random access
kinda guy, not sequential, and I've never asked mutt to take me to the
"next" folder), so I can't help you.
> 5. It must have a decent summary view. I want to be able to see all of
> my folders, the amount of mail in each, and be able to quickly choose
> one to view the mail.
I used to mess with folder_format to remove some of the useless
information like owner, group, mode, etc, but I don't bother anymore.
I avoid your problems with folders that fall off the side of the screen
by rewriting names to avoid the "INBOX" thing. But I rarely use the folder
browser since I have hotkeys to take me to any of my mailboxes instantly,
and since I typically have many different instances of mutt open viewing
different folders and can see all important new mail at a glance.
> 6. It must have a decent expiry system.
>
> 7. It must not be dog slow. I have big folders and I don't want to wait
> 5 minutes to load them.
Mutt suffers from 7, but it's not a big deal if you keep the number
of messages in a folder under control. For this I use archivemail, a nice
external program which can handle flagged and unread mail. I move read mail
to the archive after three days which keeps mutt under control.
I have one general piece of advice regarding mail which I have said
before but I think bears repeating. Don't look for one program that does
it all, because when you find an area where such a program sucks, or
something it can't do, you're screwed. Pick the best programs with
well defined uses and put them together to create something that's right
for you. The set of right programs can then morph over time with minimal
pain, and just keep getting better as new programs become available.
--
see shy jo
[1] Publically available at http://svn.kitenet.net/trunk/; relevant files
include home-full/.muttrc, home-full/.offlineimaprc, bin/trimail,
cron/joey/kitenet.net, etc, etc.
Paul Johnson
>> In general, Gnus expects to control everything in its mail backends,
>> so it's not surprising that it doesn't really sync with other maildir
>> programs. nnmaildir tries (which is probably why it is so slow) but I
>> don't think it's the highest on the list of priorities.
>
> It tries about as hard as Microsoft tries to make a secure operating
> system...
Given that you can run emacs over an SSH connection, and even get a
graphical display in an X11 environment, is this really even a problem?
Brian Nelson
> Brian Nelson wrote:
>> I have a few modest requirements that a mail client must meet:
>>
>> 1. I must be able to customize the order folders, and I don't want to
>> give them retardedly ugly names to force a correct alphabetic order.
>> This is very important when you have 70 freaking folders like I do.
>
> From my .muttrc:
>
> # Only problem with this is it doesn't find new mailboxes on the fly
> # unless I restart mutt.
> mailboxes ! `find ~/Maildir/.* -type d -maxdepth 0 -not -name .. -not -name .| xargs echo`
>
> Of course you can expand on this to add whatever ordering you like.
Hmm, that's a good idea...
>> 2. I must be able to read the folders sequentially in the order I
>> specify with minimal pain. Obviously, I read from highest priority
>> to lowest, since I may not have time to read every single folder. I
>> don't want to be interrupted while in the sequence, because old mails
>> in lower priority folders are more important to me than brand new
>> mails in higher priority ones.
>
> I can't conceive of reading mail this way (I'm a modal, random access
> kinda guy, not sequential, and I've never asked mutt to take me to the
> "next" folder), so I can't help you.
You've probably been trained that way from using mutt. I never really
thought it about until I moved away from mutt.
I suppose when I want to read mail sequentially, I could just stop
offlineimap so that I don't receive new mail in the middle of the
sequence.
>> 5. It must have a decent summary view. I want to be able to see all of
>> my folders, the amount of mail in each, and be able to quickly choose
>> one to view the mail.
>
> I used to mess with folder_format to remove some of the useless
> information like owner, group, mode, etc, but I don't bother anymore.
>
> I avoid your problems with folders that fall off the side of the screen
> by rewriting names to avoid the "INBOX" thing. But I rarely use the folder
> browser since I have hotkeys to take me to any of my mailboxes instantly,
> and since I typically have many different instances of mutt open viewing
> different folders and can see all important new mail at a glance.
I used to use mutt pretty similarly. Again, I think it's a case of
adapting yourself to mutt. When I moved from mutt to gnus, it was
refreshing to have a nice summary view. I never realized how much I
missed such a feature. It saves screen real estate and can be grokked
in a glance much quicker.
It probably wouldn't be hard to just hack the mutt source to do what I
want, but I'm lazy and it's easier to complain than to actually fix it.
:)
>> 6. It must have a decent expiry system.
>>
>> 7. It must not be dog slow. I have big folders and I don't want to wait
>> 5 minutes to load them.
>
> Mutt suffers from 7, but it's not a big deal if you keep the number
> of messages in a folder under control. For this I use archivemail, a nice
> external program which can handle flagged and unread mail. I move read mail
> to the archive after three days which keeps mutt under control.
Yeah, I've thought about using archivemail to take care of message
expiry. I don't care about archiving it--deleting it is fine--and I
assume archivemail can handle this.
I've resisted up to this point because I'm already using fetchmail,
postfix, spamassassin, procmail, courier-imap, offlineimap, mutt/gnus,
and emacs just to receive, read, and compose email. Yeah, UNIX
philosophy and all that, but you have to draw the line somewhere.
--
You win again, gravity!
Brian Nelson
John Summerfield
>>>6. It must have a decent expiry system.
>>>
>>>7. It must not be dog slow. I have big folders and I don't want to wait
>>> 5 minutes to load them.
>>>
>>>
>>Mutt suffers from 7, but it's not a big deal if you keep the number
>>of messages in a folder under control. For this I use archivemail, a nice
>>external program which can handle flagged and unread mail. I move read mail
>>to the archive after three days which keeps mutt under control.
>>
>>
>
>Yeah, I've thought about using archivemail to take care of message
>expiry. I don't care about archiving it--deleting it is fine--and I
>assume archivemail can handle this.
>
>I've resisted up to this point because I'm already using fetchmail,
>postfix, spamassassin, procmail, courier-imap, offlineimap, mutt/gnus,
>and emacs just to receive, read, and compose email. Yeah, UNIX
>philosophy and all that, but you have to draw the line somewhere.
>
>
>
Some years ago, when I was on the lkml, I used to feed it into inn, then
post my replies to the Internet. I first did that on OS/2 using Changi.
I find news programs cope better with large volumes than email clients
do. And, of course, news gets expired automatically.
--
Cheers
John
-- spambait
1aaa...@computerdatasafe.com.au Z1aa...@computerdatasafe.com.au
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
Micha Feigin
> Paul Gear <pa...@gear.dyndns.org> writes:
>
> > Brian Nelson wrote:
> >> It's 2004. Email has been around for what, 30+ years? Is there an
> >> email client out there that, after 30 years, still doesn't suck?
> >> ...
> >> thunderbird? Never tried it, doesn't support mailing lists from what
> >> I've heard. Most likely also suffers from the horrible editor syndrome.
> >
> > Just out of curiosity, would you mind defining "support mailing lists"?
> > I am on a fair few (although i've just switched to using this list via
> > gmane.org since killing threads is a really great feature that works
> > more efficiently in news than mail), and i don't find it a struggle to
> > manage them with Mozilla Mail/Thunderbird
>
> Basically, I want reply-to-list functionality. Also, it needs to honor
> Mail-Followup-To headers.
>
mutt does that for me. I think gnus can also do, I mean to test it more
heavily some time, but the startup time is too big.
> --
> You win again, gravity!
>
>
> --
> To UNSUBSCRIBE, email to debian-us...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
>
>
> +++++++++++++++++++++++++++++++++++++++++++
> This Mail Was Scanned By Mail-seCure System
> at the Tel-Aviv University CC.
Mark Roach
> Brian Nelson wrote:
[...]
> > 7. It must not be dog slow. I have big folders and I don't want to wait
> > 5 minutes to load them.
>
> Mutt suffers from 7, but it's not a big deal if you keep the number
> of messages in a folder under control. For this I use archivemail, a nice
> external program which can handle flagged and unread mail. I move read mail
> to the archive after three days which keeps mutt under control.
Have you used the imap headercache patch for mutt? I have used this on
some large (by my standards ~= 18k emails or so, YMMV) mailboxes with
substantial performance improvements. It went from a good 5 minutes over
my cable + vpn connection to about 30 seconds. I seem to recall having
to massage the patch a bit for newer mutt versions, but it wasn't
anything too tricky.
-Mark
Mark Roach
> Have you used the imap headercache patch for mutt? I have used this on
I should really read the whole thread before posting noise... and
probably shouldn't have sent this one at all...
Brian Nelson
> On Thu, Aug 05, 2004 at 12:55:28PM -0700, Brian Nelson wrote:
> > Paul Gear <pa...@gear.dyndns.org> writes:
> >
> > > Brian Nelson wrote:
> > >> It's 2004. Email has been around for what, 30+ years? Is there an
> > >> email client out there that, after 30 years, still doesn't suck?
> > >> ...
> > >> thunderbird? Never tried it, doesn't support mailing lists from what
> > >> I've heard. Most likely also suffers from the horrible editor syndrome.
> > >
> > > Just out of curiosity, would you mind defining "support mailing lists"?
> > > I am on a fair few (although i've just switched to using this list via
> > > gmane.org since killing threads is a really great feature that works
> > > more efficiently in news than mail), and i don't find it a struggle to
> > > manage them with Mozilla Mail/Thunderbird
> >
> > Basically, I want reply-to-list functionality. Also, it needs to honor
> > Mail-Followup-To headers.
> >
>
> mutt does that for me. I think gnus can also do, I mean to test it more
> heavily some time, but the startup time is too big.
Must... resist... urge... to... KILL!!!
Paul Gear
> ...
>>mutt does that for me. I think gnus can also do, I mean to test it more
>>heavily some time, but the startup time is too big.
>
>
> Must... resist... urge... to... KILL!!!
http://palpatine.chez.tiscali.fr/Dilbert/CowDskArt040896.gif
--
Paul
<http://paulgear.webhop.net>
--
Everyone who voted for slavery was free. Everyone who votes for
abortion was born. That's how oppression works.
-- Matt Evans, Harvard Law Student
John L Fjellstad
> 6. It must have a decent expiry system.
You don't need a mailclient to have a decent expiry system if you are
using Maildir. Since all new mail goes into {MAILBOXNAME}/new and all
read mail goes into {MAILBOXNAME}/cur, you can use this script to delete
all read mail over a certain date:
find ~/Mail/*/cur -type f -mtime +30 -print0 | xargs -0r rm
Plug this into your cron and you have a decent expiry system. (It's
basically what I have done).
--
John L. Fjellstad
web: http://www.fjellstad.org/ Quis custodiet ipsos custodes
Greg Folkert
> Brian Nelson <py...@debian.org> writes:
>
> > 6. It must have a decent expiry system.
>
> You don't need a mailclient to have a decent expiry system if you are
> using Maildir. Since all new mail goes into {MAILBOXNAME}/new and all
> read mail goes into {MAILBOXNAME}/cur, you can use this script to delete
> all read mail over a certain date:
>
> find ~/Mail/*/cur -type f -mtime +30 -print0 | xargs -0r rm
>
> Plug this into your cron and you have a decent expiry system. (It's
> basically what I have done).
Why not just use an IMAP server that has one? Modify settings to taste.
I use courier-imap-ssl, I haven't seen a problem yet. I even have a
couple of folders with 15K+ messages and one with 23K+ messages. I also
have 34 folders, 15 the have sub-folders from there, one sub-folder with
12 sub-folders in it.
Not a problem yet.
--
greg, gr...@gregfolkert.net
The technology that is
Stronger, better, faster: Linux
Brian Nelson
> Brian Nelson <py...@debian.org> writes:
>
> > 6. It must have a decent expiry system.
>
> You don't need a mailclient to have a decent expiry system if you are
> using Maildir. Since all new mail goes into {MAILBOXNAME}/new and all
> read mail goes into {MAILBOXNAME}/cur, you can use this script to delete
> all read mail over a certain date:
That's not necessarily true. OfflineIMAP puts all mail in cur.
Generally, I think you may find "unseen" mail in new, but the MUA will
move it to cur as soon as it finds it. It may very well not be read by
you yet.
> find ~/Mail/*/cur -type f -mtime +30 -print0 | xargs -0r rm
I think the following blob be much more reliable:
find ~/Mail/*/cur -type f -mtime +30 -regex ".*:2,.*S" -print0 | xargs -0r rm
--
You win again, gravity!
John L Fjellstad
>> > 6. It must have a decent expiry system.
>>
>> You don't need a mailclient to have a decent expiry system if you are
>> using Maildir. Since all new mail goes into {MAILBOXNAME}/new and all
>> read mail goes into {MAILBOXNAME}/cur, you can use this script to delete
>> all read mail over a certain date:
>
> That's not necessarily true. OfflineIMAP puts all mail in cur.
Well, if you were using offlineimap, I would think you would do the
script on the imap server rather than the client.
> Generally, I think you may find "unseen" mail in new, but the MUA will
> move it to cur as soon as it finds it. It may very well not be read by
> you yet.
Didn't realize that. The one MUA I'm using, which shall go unmentioned
in case you decide to kick me in the nuts, don't. Probably shouldn't
have been so sure about it.
Isn't there a way to check whether a file has been looked at? Like the
difference between creation time and access time. Although I'm not sure
the creation time gets changed if a file gets moved from new to cur...
>> find ~/Mail/*/cur -type f -mtime +30 -print0 | xargs -0r rm
>
> I think the following blob be much more reliable:
>
> find ~/Mail/*/cur -type f -mtime +30 -regex ".*:2,.*S" -print0 | xargs -0r rm
Hey, cool.. Thanks for the update...
--
John L. Fjellstad
web: http://www.fjellstad.org/ Quis custodiet ipsos custodes
John L Fjellstad
> Why not just use an IMAP server that has one? Modify settings to taste.
>
> I use courier-imap-ssl, I haven't seen a problem yet.
Didn't know courier-imap actually let you do autoexpire... Actually,
right now I'm doing pop on my laptop. Won't be able to setup an imap
server until next month when I move to my new place...
Brian Nelson
> Brian Nelson <py...@debian.org> writes:
>
> >> > 6. It must have a decent expiry system.
> >>
> >> You don't need a mailclient to have a decent expiry system if you are
> >> using Maildir. Since all new mail goes into {MAILBOXNAME}/new and all
> >> read mail goes into {MAILBOXNAME}/cur, you can use this script to delete
> >> all read mail over a certain date:
> >
> > That's not necessarily true. OfflineIMAP puts all mail in cur.
>
> Well, if you were using offlineimap, I would think you would do the
> script on the imap server rather than the client.
Modifying the backend Maildir behind the IMAP server's back is A Very
Bad Idea(tm)...
> > Generally, I think you may find "unseen" mail in new, but the MUA will
> > move it to cur as soon as it finds it. It may very well not be read by
> > you yet.
>
> Didn't realize that. The one MUA I'm using, which shall go unmentioned
> in case you decide to kick me in the nuts, don't. Probably shouldn't
> have been so sure about it.
>
> Isn't there a way to check whether a file has been looked at? Like the
> difference between creation time and access time. Although I'm not sure
> the creation time gets changed if a file gets moved from new to cur...
Look at the message flags that follow the :2, in the file name. 'S'
means 'seen'.
http://cr.yp.to/proto/maildir.html
--
You win again, gravity!
Gregory Seidman
} On Sun, Aug 08, 2004 at 08:24:34PM +0200, John L Fjellstad wrote:
} > Brian Nelson <py...@debian.org> writes:
} >
} > >> > 6. It must have a decent expiry system.
} > >>
} > >> You don't need a mailclient to have a decent expiry system if you are
} > >> using Maildir. Since all new mail goes into {MAILBOXNAME}/new and all
} > >> read mail goes into {MAILBOXNAME}/cur, you can use this script to delete
} > >> all read mail over a certain date:
} > >
} > > That's not necessarily true. OfflineIMAP puts all mail in cur.
} >
} > Well, if you were using offlineimap, I would think you would do the
} > script on the imap server rather than the client.
}
} Modifying the backend Maildir behind the IMAP server's back is A Very
} Bad Idea(tm)...
Um, no, actually, it isn't. One of the big wins of maildir is that
concurrent access does not require locking. There is no reason not to
mess with the backend maildir when the IMAP server is running. Indeed, I
can run mutt on the backend maildir, Thunderbird connected via IMAP, and
squirrelmail all concurrently, and everything works just fine.
--Greg
Greg Folkert
> On Mon, Aug 09, 2004 at 01:50:15AM -0700, Brian Nelson wrote:
> } On Sun, Aug 08, 2004 at 08:24:34PM +0200, John L Fjellstad wrote:
> } > Brian Nelson <py...@debian.org> writes:
> } > >> > 6. It must have a decent expiry system.
> } > >>
> } > >> You don't need a mailclient to have a decent expiry system if you are
> } > >> using Maildir. Since all new mail goes into {MAILBOXNAME}/new and all
> } > >> read mail goes into {MAILBOXNAME}/cur, you can use this script to delete
> } > >> all read mail over a certain date:
> } > >
> } > > That's not necessarily true. OfflineIMAP puts all mail in cur.
> } >
> } > Well, if you were using offlineimap, I would think you would do the
> } > script on the imap server rather than the client.
> }
> } Modifying the backend Maildir behind the IMAP server's back is A Very
> } Bad Idea(tm)...
>
> Um, no, actually, it isn't. One of the big wins of maildir is that
> concurrent access does not require locking. There is no reason not to
> mess with the backend maildir when the IMAP server is running. Indeed, I
> can run mutt on the backend maildir, Thunderbird connected via IMAP, and
> squirrelmail all concurrently, and everything works just fine.
Actually, it'd be good if you ran some type of File Alteration Monitor
Daemon... if you know what I mean. But it is not absolutely needed.
Brian Nelson
> On Mon, Aug 09, 2004 at 01:50:15AM -0700, Brian Nelson wrote:
> } On Sun, Aug 08, 2004 at 08:24:34PM +0200, John L Fjellstad wrote:
> } > Brian Nelson <py...@debian.org> writes:
> } >
> } > >> > 6. It must have a decent expiry system.
> } > >>
> } > >> You don't need a mailclient to have a decent expiry system if you are
> } > >> using Maildir. Since all new mail goes into {MAILBOXNAME}/new and all
> } > >> read mail goes into {MAILBOXNAME}/cur, you can use this script to delete
> } > >> all read mail over a certain date:
> } > >
> } > > That's not necessarily true. OfflineIMAP puts all mail in cur.
> } >
> } > Well, if you were using offlineimap, I would think you would do the
> } > script on the imap server rather than the client.
> }
> } Modifying the backend Maildir behind the IMAP server's back is A Very
> } Bad Idea(tm)...
>
> Um, no, actually, it isn't. One of the big wins of maildir is that
> concurrent access does not require locking. There is no reason not to
> mess with the backend maildir when the IMAP server is running. Indeed, I
> can run mutt on the backend maildir, Thunderbird connected via IMAP, and
> squirrelmail all concurrently, and everything works just fine.
It's not locking problems, I thought it would screw up something to do
with the way the IMAP server (courier in my case) does caching or
something. I might be thinking of old problems I had with uw-imap
though.
--
You win again, gravity!
Edvard Majakari
> I use courier-imap-ssl, I haven't seen a problem yet. I even have a
> couple of folders with 15K+ messages and one with 23K+ messages. I also
> have 34 folders, 15 the have sub-folders from there, one sub-folder with
> 12 sub-folders in it.
Can you set per-group/sender/whatever auto-expiry policies? Gnus can, and
that's why I stick with it (eg. mail from my wife never expires, ditto
for work related, mail from my friends does expire but not very fast,
other stuff expires and junk/spam expires fast enough.
--
# Edvard Majakari Software Engineer
# PGP PUBLIC KEY available Soli Deo Gloria!
$_ = '456476617264204d616a616b6172692c20612043687269737469616e20'; print
join('',map{chr hex}(split/(\w{2})/)),uc substr(crypt(60281449,'es'),2,4),"\n";
list...@ml1.net
FWIW... maybe my demands are just too small, but I've been using
MH mail for... for.... hmmm... 25 years, now? maybe? and
because it's command-line oriented, whenever it does something I
don't like or doesn't do something I want, I write shell scripts to
bludgeon it into submission as necessary, since I can access all
its utilities from a shell script. occasionally I have to inflict
Perl or even a C program on it. At one time I wrote my own
encrypted mail system for it in C, before PGP became available... you
can use procmail to direct incoming Stuff to various folders.
(Just to strike holy fear into the hearts of any sysadmins out
there, I've been known to break security, implement an SUID shell
script to hack the sendmail.cf file to change the system identity
while I send my mail out of some unsuspecting victim's system and then
change it back when it's done, and then embed *that* in my MH
control scripts). (okay, now go change your pants...)
But I'm not sure about IMAP support... in the past when I've
wanted something like that I've been able to just mount the MH
mail directory over the network, but there are Issues (to say the
least) with trying to do that across the Internet... dep't. I
think you have to *build* MH with POP support, and I'm not sure
(yet) whether it supports IMAP at all (although I notice fetchmail
does, so there's probably a way to map MH folders to IMAP folders...
hmmm...)
John Summerfield
>But I'm not sure about IMAP support... in the past when I've
>wanted something like that I've been able to just mount the MH
>mail directory over the network, but there are Issues (to say the
>least) with trying to do that across the Internet... dep't. I
>think you have to *build* MH with POP support, and I'm not sure
>(yet) whether it supports IMAP at all (although I notice fetchmail
>does, so there's probably a way to map MH folders to IMAP folders...
>hmmm...)
>
>
>
>
Downloading the contents of imap folders goes far to defeat the purpose
of IMAP: I can read the same mail ising different IMAP clients on
different computers and across different operating systems.
--
Cheers
John
-- spambait
1aaa...@computerdatasafe.com.au Z1aa...@computerdatasafe.com.au
Tourist pics http://portgeographe.environmentaldisasters.cds.merseine.nu/
Thomas Adam
> there, I've been known to break security, implement an SUID shell
> script to hack the sendmail.cf file to change the system identity
That doesn't do anything. SUID/GID bits on shell scripts are
ignored.
-- Thomas Adam
--
"Frankly, Mr. Shankly, since you ask. You are a flatulent pain in
the arse." -- Morrissey.
Alvin Oga
hi ya "list comm"
On Mon, 9 Aug 2004 list...@ml1.net wrote:
> FWIW... maybe my demands are just too small, but I've been using
> MH mail for... for.... hmmm... 25 years, now? maybe? and
> because it's command-line oriented, whenever it does something I
there's a gui for mh too
> (Just to strike holy fear into the hearts of any sysadmins out
> there, I've been known to break security, implement an SUID shell
> script to hack the sendmail.cf file to change the system identity
> while I send my mail out of some unsuspecting victim's system and then
> change it back when it's done, and then embed *that* in my MH
> control scripts). (okay, now go change your pants...)
sounds like the mta was not hardened ... users should not be able
to change the mta config files
- guess that's half the fun
c ya
alvin
list...@ml1.net
> there's a gui for mh too
Yes... thanks for reminding me, I was going to say something about that,
for the benefit of whoever is bemoaning his mail system...
it's "exmh" (formerly "xmh"), and is implemented AFAIK entirely in TCL,
which can be customized to change the GUI (or blow it off the air and
cause you lots of work) as you please.
Thus far, I haven't Gotten Around To customizing the GUI the way I've
hacked the shell commands... but if you were bent on being able to
access whatever modifications you'd implemented for the shell commands
via the GUI, you could just add buttons to invoke them, or (presumably)
reconfigure the GUI appearance.
I've got MH and exmh installed and running on Woody, but I'm still
attempting to get outgoing mail working...
> sounds like the mta was not hardened ... users should not be able
> to change the mta config files
Oh, I know... and with good reason... but that never deterred me.
list...@ml1.net
> of IMAP: I can read the same mail ising different IMAP clients on
> different computers and across different operating systems.
Well, some of the mailers supposedly will "Synchronize" (yeah, right)
your local folder image with whatever is on the server, which would
be nice if it worked, so you could conduct interactive stuff locally
and just use the link for keeping stuff synchronized
but, yeah, in practice, unfortunately you're right...
list...@ml1.net
Joey Hess
> Well, some of the mailers supposedly will "Synchronize" (yeah, right)
> your local folder image with whatever is on the server, which would
> be nice if it worked, so you could conduct interactive stuff locally
> and just use the link for keeping stuff synchronized
>
> but, yeah, in practice, unfortunately you're right...
In practice, it works perfectly with offlineimap.
--
see shy jo
Cristian Gutierrez
[...]
>>> Furthermore, I ran into problems with offline synchronization.
>>
>> if you are using imap, there is zero syncrhonization problems,
>> as your email and folders are only on the imap server
>
> Hmm? I don't use OfflineIMAP for shits and giggles, ya know. [...]
I think I've been where you are right now. I wanted Gnus flexibility but
because nnmbox was a royal PITA, and nnmaildir didn't make it a lot
better, I envied mutt's usual performance.
So I decided to `outsource' maildir access to a dedicated
compiled-chunk-of-C-code daemon: I have courier serving IMAP to Gnus,
and offlineimap syncing the mail server with the *maildir folders*, not
the local server.
Now Gnus (via nnimap) scans, enters and exits folders blazingly fast
(unlike nnmaildir), doesn't fill up my half-gigabyte memory (as nnmbox
did), and doesn't interfere with offlineimap; instead, courier
does. Well, does not :-) Being a maildir directory, those two coexist
nicely.
Moving messages between folders can't be faster than it is now (unlike
with nnmbox), but there is a shortcoming deleting messages; somehow it
takes courier a few seconds (20 or so) to delete any number of messages
from a nnimap folder. `top' shows courier being busy during that while,
so may be there's some courier config's tweaking in order. Gnus just
wait, and if something goes wrong, I can convince it to stop waiting
with C-g (unlike before, when it seemed to be doing all the hard work
with its "utterly efficient" elisp file handling routines, and listening
to noone meanwhile ;-)
Well, I hope you save me the kicking. My gonads need some rest.
--
Cristian Gutierrez http://www.dcc.uchile.cl/~crgutier
crgutier[@]dcc.uchile.cl Jabber:crgu...@jabber.org
"Artificial Intelligence: the art of making computers that behave like
the ones in movies." -- Bill Bulko
Robert Waldner
On Tue, 10 Aug 2004 06:01:31 +0800, John Summerfield writes:
<mh>
>>But I'm not sure about IMAP support... in the past when I've
>>wanted something like that I've been able to just mount the MH
>>mail directory over the network, but there are Issues (to say the
>>least) with trying to do that across the Internet... dep't. I
>>think you have to *build* MH with POP support, and I'm not sure
>>(yet) whether it supports IMAP at all (although I notice fetchmail
>>does, so there's probably a way to map MH folders to IMAP folders...
>>hmmm...)
>Downloading the contents of imap folders goes far to defeat the purpose
>of IMAP: I can read the same mail ising different IMAP clients on
>different computers and across different operating systems.
Now, an IMAP-server whose backend is mh. That would be really useful,
especially if it'd properly use sequences.
Or is there something like that already and I just haven't found it yet?
cheers,
&r<this message brought to you via exmh>w
--
/ Ing. Robert Waldner | Security Engineer | CoreTec IT-Security \
\ <r...@coretec.at> | T +43 1 503 72 73 | F +43 1 503 72 73 x99 /
Brian Nelson
> Brian Nelson wrote:
>
> [...]
>
> >>> Furthermore, I ran into problems with offline synchronization.
> >>
> >> if you are using imap, there is zero syncrhonization problems,
> >> as your email and folders are only on the imap server
> >
> > Hmm? I don't use OfflineIMAP for shits and giggles, ya know. [...]
>
> I think I've been where you are right now. I wanted Gnus flexibility but
> because nnmbox was a royal PITA, and nnmaildir didn't make it a lot
> better, I envied mutt's usual performance.
>
> So I decided to `outsource' maildir access to a dedicated
> compiled-chunk-of-C-code daemon: I have courier serving IMAP to Gnus,
> and offlineimap syncing the mail server with the *maildir folders*, not
> the local server.
>
> Now Gnus (via nnimap) scans, enters and exits folders blazingly fast
> (unlike nnmaildir), doesn't fill up my half-gigabyte memory (as nnmbox
> did), and doesn't interfere with offlineimap; instead, courier
> does. Well, does not :-) Being a maildir directory, those two coexist
> nicely.
Interesting. Add enough levels of indirection and you will eventually
reach email nirvana. :)
--
You win again, gravity!