failure of gnus to determine boundaries of emails

failure of gnus to determine boundaries of emails

[Martin Steffen]

Hi,

I have the following set-up: I slurp in (via fetchmail) my emails from some
server, have it spit via procmail and thus spooled into mail-files in
mbox-format at my local disk.

At that point, I want gnus to read-in those spooled mail-files, to
incorporate them (using gnus' ``nnfolder'' backend seconday-method.)

Indeed, gnus reads in the spooled files, i.e., incorporates them from the
spool directory into the target directory ~/Mail and displays them as
``groups'' in the top-level gnus buffer.

However: when entering one of those nnfolder-groups, the emails in each
folder are shown in the summary mode as simply _one big email_, i.e.,
either the gnus-incorporating-mechanism or the summary-display-mechanism
does not honor the message boundaries properly.

Any hints, what might be the problem?


Martin

PS: I'm working with emacs-version 21.4.1
    nd               gnus-version  v5.9.0

PPS: I had posted a similar enquiry some time ago, but 
     two sources of errors that I suspected at that
     time (procmail, and/or the mail-server itself)
     I think I can cancel from the list of potential culprits,
     seems like the problem lies within gnus..

Re: failure of gnus to determine boundaries of emails

[Reiner Steib]

On Sat, Oct 14 2006, Martin Steffen wrote:

> However: when entering one of those nnfolder-groups, the emails in each
> folder are shown in the summary mode as simply _one big email_, i.e.,
> either the gnus-incorporating-mechanism or the summary-display-mechanism
> does not honor the message boundaries properly.
[...]
> PS: I'm working with emacs-version 21.4.1
>     nd               gnus-version  v5.9.0

Gnus 5.9 is old.  Could you upgrade to 5.10.8 (latest stable release)
or to Emacs 22 (CVS, but quite stable; it will enter pretest soon)
which includes 5.11.

> PPS: I had posted a similar enquiry some time ago, but 
>      two sources of errors that I suspected at that
>      time (procmail, and/or the mail-server itself)
>      I think I can cancel from the list of potential culprits,
>      seems like the problem lies within gnus..

I don't think the problem lies in Gnus.  I use a similar setup (but
with nnml) without any problems:

,----[ <f1> v mail-sources RET ]
| mail-sources is a variable defined in `mail-source'.
| Its value is 
| ((file)
|  (directory :path
| 	    (concat mail-source-directory "../procmail/")
| 	    :suffix ""))
| 
| Documentation:
| *Where the mail backends will look for incoming mail.
| This variable is a list of mail source specifiers.
| See Info node `(gnus)Mail Source Specifiers'.
`----

Please show us the relevant stuff from your Gnus setup
(`mail-sources', `gnus-secondary-select-methods', ...).  Maybe you can
also send us a gzipped procmail spool file and the resulting nnfolder
file (be sure not to include private data; maybe a public mailing list
or a spam folder?).

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: failure of gnus to determine boundaries of emails

[Martin Steffen]

>>>>> "Reiner" == Reiner Steib <reinersteib+gmane@imap.cc> writes:

    Reiner> On Sat, Oct 14 2006, Martin Steffen wrote:

    >> PS: I'm working with emacs-version 21.4.1 nd gnus-version v5.9.0

    Reiner> Gnus 5.9 is old.  Could you upgrade to 5.10.8 (latest stable
    Reiner> release) or to Emacs 22 (CVS, but quite stable; it will enter
    Reiner> pretest soon) which includes 5.11.

I guess, I won't be able to convince the admins here that they should live
on the CVS cutting edge... They will support the default emacs/gnus
combination which comes shipped (resp. upgraded) with their Red-Hat
distribution, and I guess that's understandable. I might try on my laptop
though

    Reiner> I don't think the problem lies in Gnus.  I use a similar setup
    Reiner> (but with nnml) without any problems:

Actually, I at least guess, it's not a gnus/emacs-version problem, since I
use the same set-up for ages, at least since emacs-19 (or even 18) and the
corresponding neolithic gnus-version back then :-)


However, here nobody seems able to can help, all are content with
squirrel-web-access, but I'm not yet ready to give-up :-)

Maybe you are right, and the problem is not gnus. Because, at my laptop I
have in the meantime managed, and there it was _not_ the error of gnus (at
least as far as I understand).  It seems that the way I used fetchmail
caused the problem. 

To be more specific: using the following two different
.fetchmailrc-specifications:


(1) poll server.some.where with proto IMAP user 'user1' there is 'user2' here  options keep fetchall ssl 

(2) poll server.some.where with proto IMAP user 'user1' there is 'user2' here  and wants mda "/usr/bin/procmail" options keep fetchall ssl 


(1) now works at my laptop, (2) on the other hand fetches the emails, procmail split
them into nnfolder-files, and gnus reads them in, but with the mentioned problem
of not finding the boundaries appropriately.

So far, so good, the problem is that (1) does _not_ work at my desktop at work, with
the same emacs-version and the same gnus-version and the same settings. Probably, I will have to
find out how I can use fetchmail in that environment, since (1) does not work at all, and
(2) has the mentioned problem.

Anyway, my gnus settings  are:


 -  mail-source-directory =  ((directory :path "~/Mail/spool/" :suffix ".spool"))
 -  mail-sources = ((directory :path "~/Mail/spool/" :suffix ".spool"))
 - gnus-secondary-select-methods's value is 
   ((nnfolder "")
    (nntp "news.gmane.org"))
 - gnus-default-nntp-server's value is "news.uio.no"
 - gnus-directory's value is "~/Mail/spool/"

and furthermore: 

(setq nnmail-use-long-file-names   t)
(setq nnmail-tmp-directory  "~/Mail/spool")
(setq nnmail-use-procmail t)
(setq nnmail-procmail-directory "~/Mail/spool")

But, as indicated, maybe indeed gnus is not the culprit (unlike I said),
since at least on one machine the configuration works now. Only 
not yet at work.

I try to research that further, and also I try to compare the format of the
spool-files to see what influence the "mda"-specification has on it.

Martin