nnml / nnmh

nnml / nnmh

[Truxton Fulton]

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

Re: nnml / nnmh

[NAKAJI Hiroyuki]

>>>>> 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

Re: nnml / nnmh

[Kai Großjohann]

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!

Re: nnml / nnmh

[Paul Jarc]

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

Re: nnml / nnmh

[Harry Putnam]

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.

Re: nnml / nnmh

[Paul Jarc]

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