Hi, I use procmail to store incoming mail into individually numbered files in various mail directories. I use gnus nndir or nnmh to read it. I would like to use nnml because of its efficiency, but I cant get gnus to re-scan the directory. Pressing 'g' in the group buffer doesnt do it. I get the impression that the nnml backend wants to store the files there itself by reading /var/spool/mail. Is there a simple solution? Thanks, -Truxton
>>>>> In <m2adtgslce.fsf@truxton.com>
>>>>> Truxton Fulton <trux@truxton.com> wrote:
TF> Is there a simple solution?
My solution.
===> ~/.procmailrc
MAILDIR=$HOME/Mail
INCOMING=$HOME/.incoming
:0 # ding
* ^Sender: owner-ding@hpc.uh.edu
$INCOMING/ding.spool # will go to $MAILDIR/ding
===> ~/.gnus.el
(setq mail-sources '((directory :path "~/.incoming/")))
--
NAKAJI Hiroyuki
For procmail/Gnus interaction, I suggest to proceed as follows. Anything else is asking for trouble: Tell procmail to write to the file(!) ~/procmail/foo.bar. Tell Gnus to read from the directory ~/procmail: (add-to-list 'mail-sources '(directory :path "~/procmail" :suffix "")) This way, Gnus will put all messages from the file(!) ~/procmail/foo.bar into the group nnml:foo.bar. This caveat does not apply to nnmaildir. With nnmaildir, you can tell procmail to write to the directory directly. (Though I'm not sure how to get the file names right -- I don't use nnmaildir.) The caveat also does not apply to IMAP. There, you need to make sure that procmail and the IMAP server coexist. For Gnus with nnimap there will be no problem. (nnmh is the safest backend for letting Gnus write to it, so you were lucky. But don't use nnml or nnfolder or nnmbox or something like this together with procmail, except in the fashion I described.) kai -- Silence is foo!
Truxton Fulton <trux@truxton.com> wrote: > I get the impression that the nnml backend wants to store the files > there itself by reading /var/spool/mail. Right (well, by reading mail-sources anyway). You can use separate mbox spools and a 'directory mail-sources entry, as Hiroyuki described, or you could use nnmaildir. Procmail can deliver to maildirs, and nnmaildir can use those same maildirs as groups, bypassing the usual Gnus mail-splitting mechanism. This is faster and also avoids mbox "From " munging. Beware that nnmaildir is somewhat different from other backends; your config stuff will have to be tweaked to produce the same behavior you have now. The parts of nnmaildir's documentation not yet in the Gnus manual are at <URL:http://multivac.cwru.edu./nnmaildir/>. paul
Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:
> This caveat does not apply to nnmaildir. With nnmaildir, you can
> tell procmail to write to the directory directly. (Though I'm not
> sure how to get the file names right -- I don't use nnmaildir.)
At the start, the file names are handled by procmail. You just supply
the right syntax. In this case it would be:
(To put everthing in one nnmaildir group)
cat (partial) .procmailrc
[...]
MAILDIR=/my_nnmaildir/parent/directory
:0
my_big_huge_all_inclusive_nnmaildir_folder/
Note the trailing (/). That notation is all that is required to have
procmail DTR inside MAILDIR.
Harry Putnam <reader@newsguy.com> wrote:
> cat (partial) .procmailrc
>
> [...]
> MAILDIR=/my_nnmaildir/parent/directory
And I'd suggest that this should be the nnmaildir server's
"create-directory" parameter (where the real maildirs are), rather
than the "directory" parameter (where the symlinks are). If you
remove a symlink to hide the group from nnmaildir for some reason, you
probably don't want to break deliveries.
paul