[imapfilter-devel] Error: attempt to index field 'INBOX'

[David DeSimone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alejandro Jakubi <jakubi at df.uba.ar> wrote:
>
> I see, but from what he says, it seems also that changing the value of
> the options along the execution of a function allows limiting their
> scope in a time sense.

Yes, imapfilter consults these flags every time they are needed, not
just once at startup.  You can change the behavior "on the fly," as they
say.

> I wish to make imapfilter run in the background, using daemon_mode(),
> once I get it configured to make some tasks.  So, I would find very
> useful to have a log of the actions as described in my previous
> message.

I believe that the -l flag redirects the output that any print()
statements would produce, to the specified file.  Because imapfilter's
messages are just regular print() statements, just like your own script
would produce.  You can view /usr/share/imapfilter/interface.lua in
order to see what exactly imapfilter does when you call various methods
like move() and delete().

> What kind of errors?  For instance, if imapfilter tries to filter
> while Pine is open and "holding" the INBOX, would an error appear in
> the logfile?

Ah, you have hit upon a common misconception.  There is no such thing as
one process "holding" a folder, in IMAP.  IMAP is a shared resource, and
therefore you can have multiple processes all connected to the same
folder at the same time.  They will not be aware of each other's
connections, and they cannot prevent each other from making changes to
the folder.  This can lead to some timing bugs!  If you are going to
have multiple IMAP clients connected at once, you should keep this in
mind when writing your scripts.

For instance, a very nasty timing bug can appear when you are deleting
messages from a folder.  Suppose the folder has 20 messages in it,
numbered 1-20.  If you delete a message, then messages 16-20 now become
messages 15-19.  Even a very simple script like this:

    results = match(account, mbox, query)

    delete(account, mbox, results)

can have devastating effects, because the folder might change between
when your query finishes, and when the delete occurs.

Fortunately there is a way to avoid this problem, by using UID's.  You
should always set "options.uid" to "true", which causes imapfilter to
use Universal ID's for messages.  Then, if the mailbox changes between
gathering the query and deleting, all that results is an error message
about a missing UID, rather than deleting the wrong message.

Hmm, my man page tells me that this option now defaults to "true", but
this was not always the case.  Best to be sure about it rather than make
assumptions.

> So, the chance exist that a non spam message is labeled spam.  Then, I
> store these messages in a spam folder and check them before erasing. 
> But in practice, very seldom I need to rescue a message from this
> folder.  So, it becomes most convenient for me to move these messages
> to the spam folder and flag them already as deleted, so that they are
> removed when I close my desktop email client (Pine/PCPine).

I understand your reasoning here, but I share the opinion that
pre-marking messages with the \Delete flag is asking for trouble. 
Someday you might make a mistake and expunge the folder before checking
all the messages.  But, as long as you are aware of the risk, it is your
decision to make.

Are you a member of this mailing list?  I am not sure if I should simply
reply to the list, or continue to CC you on these replies.

- -- 
David DeSimone == Network Admin == fox at verio.net
"This email message is intended for the use of the person to whom
 it has been sent, and may contain information that is confidential
 or legally protected.  If you are not the intended recipient or have
 received this message in error, you are not authorized to copy, dis-
 tribute, or otherwise use this message or its attachments.  Please
 notify the sender immediately by return e-mail and permanently delete
 this message and any attachments.  Verio, Inc. makes no warranty that
 this email is error or virus free.  Thank you."  --Lawyer Bot 6000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFHGll3FSrKRjX5eCoRAv+eAKCI1lARKXniPZrEUFXvCxYWEOhDCwCePfu4
U8mSt4gSKCTBrm8pQ5JaXV4=
=eZB4
-----END PGP SIGNATURE-----