Re: Emacs mailreader that doesn't move the spool

[William G Gardella <wgg2@member.fsf.org>]

Hikaru Ichijyo <ichijyo@macross.sdf.jp> writes:

[...]

> Yes, I already have an IMAP daemon setup for users, so I could use it 
> locally also.
>
> Well...I suppose I could consider it a wishlist request for VM and/or 
> Gnus then:  It would be nice if they could do in-place file locking of 
> the system mail spool, like Mutt and Alpine do.  Maybe in a future 
> version?  :)

If RMAIL can do this with a configuration variable, Gnus probably can as
well, at least from a technical standpoint.

For what it's worth, I use Gnus with its "nnmaildir" message store,
notmuch <http://notmuchmail.org/>, and notmuch-web
<https://bitbucket.org/wuzzeb/notmuch-web>, together with a
~/.procmailrc that delivers my incoming mail to a series of Maildirs in
$HOME.  The main advantages of this setup from my standpoint are that
filtering of messages into some basic categories is automatic before I
even look at my mail, and that the Maildir format itself does not
require locks; several MUAs can be refiling, marking, and adding new
messages to the Maildir at the same time without stepping on each
other's toes.  This configuration does not fulfil your requirement of
not moving the mail, but it may fulfil your requirement of sharing, as
Maildir is a lingua franca among many MUAs, mail indexing programs, and
IMAP servers these days.

The (for now very simple) ~/.procmailrc is as follows:

--8<---------------cut here---------------start------------->8---
:0 c
* ^X-Spam-Status: Yes
Maildir/spam/
:0 Ec
* ^List-Unsubscribe:.*
Maildir/lists/
:0 Ec
Maildir/mail/
:0
| notmuch new
--8<---------------cut here---------------end--------------->8---

First, spam is filtered out into its own sub-maildir for possible manual
checking (not shown: the SpamAssassin + Pyzor configuration that adds
the spam-related headers).  Second, messages with a List-Unsubscribe
header--bulk mailings--go in the "lists" maildir.  Anything else is
mail.  Finally, the notmuch indexer is run to incorporate the new mail
(pedantically speaking, this recipe runs notmuch with the new messages as
arguments, but notmuch ignores its stdin).

Of course, this setup might or might not make sense for your
requirements.  You may have some reason to prefer mbox, but consider
also that many contemporary MTAs such as Postfix are happy to deliver
directly to a maildir in $HOME, possibly without the help of an MDA
helper like procmail.

--
Best,
WGG