[imapfilter-devel] Error: attempt to index field 'INBOX'
Alejandro Jakubi
jakubi at df.uba.ar
Mon Oct 22 04:36:43 EEST 2007
David,
> If you look at the January 2007 archives, you should find a post that I
> made, where I showed a lot of my code examples and methods that I use
I will study your post.
Right now, by modifying a bit the log printing hack posted earlier by Lefteris
I have got a first operating version of the imapfilter configuration that
makes the required mail processing tasks for a pair message patterns, reports
them to a logfile and runs fine in background using daemon_mode(). What I am
currently looking for is to optimize the periodicity of filtering (the
parameter in daemon_mode): not too frequent so that it keeps filtering 0
messages and not too delayed so that many unfiltered messages accumulate in
the inbox. Also, the longer the period, smaller is the chance of collision
with Pine.
Indeed, for this tuning, the timing of the filter actions is very useful.
> This is interesting. I suppose it might be that your particular IMAP
> implementation has some restrictions. My IMAP server is actually part
It seems rather a well known issue of Pine, eg:
http://www.ii.com/internet/messaging/pine/pc/ (sect 21)
http://kb.iu.edu/data/caer.html
> Imapfilter is at the mercy of your IMAP server. If the server returns
> an error, imapfilter can't do its work. But if you are using daemon
> mode, it will just try again later.
Would this error be logged when using the option -l ?
> That is a strange problem. It reminds me of when you posted earlier,
> saying that imapfilter's man pages are corrupted on your system. I do
> not know why you see so many forms of corruption, but perhaps it is not
Not many but just these two, unrelated between them I guess. That is, I have
not read messages with this kind of problem for several years (out of
thousands that I read per year). But I do remember observing a similar problem
with a listserver many years ago.
And imapfilter 1.3 seems to have been compiled here by the system manager,
while most of the packages seem to have originated from rpms. This may be
related to this man page anomaly. As I hope that he will upgrade to the current
version of imapfilter, I will not care much about this anyway.
Alejandro
More information about the Imapfilter-devel
mailing list