Re: using movemail directly in .emacs

[Hikaru Ichijyo]

Robert Thorpe <rt@robertthorpeconsulting.com> wrote:
> lee <lee@yun.yagibdah.de> writes:
> 
>> Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:
>>> Is any of this impossible or misguided?  I'd just strongly prefer my 
>>> mailbox in the system spool area where most UNIX tools expect it to
>>> be.
>>
>> It`s not impossible, yet it doesn`t make much sense.  Using a single
>> file like the spool file is an anachronism (and apparently doesn`t work
>> too well over NFS).  A single file is very awkward to work with: When
>> you delete an email somewhere within the file or set a flag (like read,
>> answered, etc.), the whole file needs to be rewritten.  That wouldn`t be
>> ideal with a file of over 4GB.
>>
>> In any case, the file can easily be damaged, in which case you might
>> loose all your email.  What happens when your computer crashes while
>> it`s copying or rewriting your 4GB+ spool file?
> 
> Spool files are a temporary storage area for email.  A user reads 
> their mail using a program (a "Mail User Agent" or MUA) which takes 
> the mail from the spool file and stores it elsewhere.  For most MUAs 
> all mail is moved from the spool file to somewhere in the user's home 
> directory. For some MUAs the "inbox" is the spool file, normally for 
> those the user is expect to move stuff out into other files.

The main reason I initially wanted to go down this path is because Mutt 
and (Al)pine handle it gracefully, and because with their code being 
freely available, I couldn't see a good reason why a Lisp-based 
mailreader couldn't be coded to do the same thing.

Somehow, Mutt and Alpine are both able to negotiate locking on the spool 
file such that you can safely write and expunge messages while the 
system MDA is doing delivery without any fear of corruption.  Alpine 
actually handles this a little better, since whereas Mutt will handle a 
situation where you wanted to make a change on disk at the same time the 
MDA delivered a message by beeping, *not* making your change, and 
updating the display to show the new mails that just came in, Alpine's 
code seems to be able to pull the tablecloth out while the diners are 
eating -- it effects whatever change you made, *and* it updates the 
display to show the new mail.  In decades of using Pine and Alpine, I've 
never seen it screw this up.  If anyone wants a code example for how 
this could work, Alpine is under the Apache license.

I finally gave up though and changed my setup to what Emacs expects, 
since Mutt and Alpine can both be setup to do that also (they just don't 
have to be).  All my mailreaders (VM, Alpine, Mutt...) now move mail 
from the system spool to ~/mbox and work on it there...so Emacs is happy 
now.

> The problem here isn't that spool files are an anarchonism, it's that 
> they're not made for storing large amounts of mail.

It seems like most users let gigabytes of mail accumulate in their 
inbox.  The only messages I leave in mine are active items that still 
need attention.  Everything else gets moved to a folder as soon as 
possible.  I never have more than 400 messages in my inbox at its worst.

> It may now work on some system too because they have scripts that 
> delete very large spool files.  (Notice I'm not saying that spool 
> files aren't an anachonism. Multi-user *nix computers that are never 
> switched off are going the way of dinosaurs and spool files with 
> them.)

Not anywhere around me they aren't.  :)

Granted, we now store the central user databases in some kind of 
directory on a central server with something like LDAP rather than 
having a humongous /etc/passwd, but I work in academic computing, and 
universities are where big multiuser UNIX-based Internet sites have deep 
roots, not likely to go away any time soon.

-- 
He that would make his own liberty secure must guard even his enemy from
oppression; for if he violates this duty, he establishes a precedent
that will reach to himself.
                                        --Thomas Paine