Subject: Re[2]: question regarding portability

From: "Chris Bartram" <[email-masked]>
Date: Tue, 10 Feb 1998 19:44:19 -0500

In <[email-masked]> [email-masked] writes:

> > From: Lyndon Nerenberg <[email-masked]>
> >
> > On 9 Feb 1998 14:37:30 -0500 Tim Showalter <[email-masked]> wrote:
> >
> > > > From: "Jack De Winter" <[email-masked]>
> > >
> > > > In 4.2, there is a specification for FileInto, and
> > > > it shows that "INBOX.harassment" is the folder.
> > > >
> > > > 1) What should happen if "INBOX.harassment" does not exist?
> > >
> > > The script shouldn't run, in my opinion.  This can be checked for before
> > > running the script.
> >
> > But you still have to deal with the case where the folder goes away
> > after the script has been installed. If this happens the message should
> > file into the default mailbox. (Possibly with some sort of diagnostic?)
>
> This can still be checked before running the script; just compile a list of
> things that have to be true (mailbox is under quota, all mentioned
> mailboxes still exist); if it's not true, don't filter the message and
> leave it in the queue.

"Leaving a message in the queue" isn't a good option (if your meaning of queue
is what I think); leaving it in the "inbox" folder might be a reasonable
option. Perhaps another option would be to define a folder name where messages
get "dropped" into in the event there is a problem with rules (which perhaps
most people would choose to use 'inbox' for). Perhaps even allow a "rule"
that would allow users to specify it; sorta like

 onerr fileinto problem-folder

and define in the spec that if this option isn't present, a default of

 onerr fileinto inbox

will apply.

Perhaps an e-mail notice sent to the inbox noting the rule that encountered
the error would be helpful as well.

                   -Chris Bartram