* failure of gnus to determine boundaries of emails
@ 2006-10-14 13:32 Martin Steffen
2006-10-15 10:48 ` Reiner Steib
0 siblings, 1 reply; 3+ messages in thread
From: Martin Steffen @ 2006-10-14 13:32 UTC (permalink / raw)
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..
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: failure of gnus to determine boundaries of emails
2006-10-14 13:32 failure of gnus to determine boundaries of emails Martin Steffen
@ 2006-10-15 10:48 ` Reiner Steib
2006-10-15 11:46 ` Martin Steffen
0 siblings, 1 reply; 3+ messages in thread
From: Reiner Steib @ 2006-10-15 10:48 UTC (permalink / raw)
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/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: failure of gnus to determine boundaries of emails
2006-10-15 10:48 ` Reiner Steib
@ 2006-10-15 11:46 ` Martin Steffen
0 siblings, 0 replies; 3+ messages in thread
From: Martin Steffen @ 2006-10-15 11:46 UTC (permalink / raw)
>>>>> "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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-10-15 11:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-10-14 13:32 failure of gnus to determine boundaries of emails Martin Steffen
2006-10-15 10:48 ` Reiner Steib
2006-10-15 11:46 ` Martin Steffen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).