[21422] in Athena Bugs
Re: linux 9.1.24: pine and spamscreen
daemon@ATHENA.MIT.EDU (Jacob Morzinski)
Tue Feb 4 18:56:27 2003
To: Angie Kelic <sly@mit.edu>
Cc: bugs@mit.edu
From: Jacob Morzinski <jmorzins@MIT.EDU>
Date: 04 Feb 2003 18:56:25 -0500
In-Reply-To: <bugs:21399@unknown-discuss-server>
Message-ID: <w6my94vfvme.fsf@multics.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
<sly@MIT.EDU> (Angie Kelic) writes:
> To fix the problem I had to use imtest to rename INBOX.INBOX.Spamscreen
> to INBOX.foo. At which point pine showed a folder named "foo" with zero
> contents so I could delete it.
If I assume that Angie is confused about whether the created
folder was a "second INBOX with all of her inbox mail in it"
(sorry about the assumption, Angie), then I can reply to this
bug report by saying "it's not very good, but it's working as
designed". My conclusion is "don't tell users it's called
INBOX.Spamscreen, tell users it's called Spamscreen".
The root of the issue is that the user isn't expected to know
that her root folder is named "INBOX" -- the user is only
supposed know that they have a subfolder named "Spamscreen".
If you ask pine (or mozilla) to create a folder, pine and mozilla
will create this new folder as a child of the folder you are
currently viewing. So a child of INBOX, with the name
"INBOX.Spamscreen", becomes "INBOX.INBOX.Spamscreen".
But to make matters more challenging, the user has *not*
requested the creation of a folder named "INBOX.INBOX", and IMAP
servers have an actual way of handling situations like that. The
folder is labeled either \Noselect or \NonExistent or both, and
these flags are what persuade Pine not to list the folder in
its folder listing. You can use "g" to jump straight to
"INBOX.INBOX.Spamscreen", but won't be able to view "INBOX.INBOX"
since it does not, in fact, exist.
It's possible to use pine to locate and view (and rename) the too-deep
"Spamscreen" folder, if the separate-folder-and-directory-entries
configuration option is set. This makes the folder list
considerably uglier than the list without that option, at least
to my tastes, so I don't recommend enabling that option on a
site-wide basis. As Angie discovered, imtest (or mozilla)
will be able to rename the folder with less hassle.
In conclusion, all I can say is "don't tell users about an
INBOX.Spamscreen folder, because you'll cause them to hurt
themselves. Tell them it's a subfolder of their inbox named
Spamscreen."
-Jacob
Here's a protocol log of a snippet of an imap LIST request;
notice the flags on the INBOX.INBOX folder:
IMAP DEBUG 18:16:18 2/4: * LIST (\HasNoChildren) "." "INBOX.Sent"
IMAP DEBUG 18:16:18 2/4: * LIST (\NonExistent \Noselect \HasChildren) "." "INBOX.INBOX"
IMAP DEBUG 18:17:56 2/4: * LIST (\HasNoChildren) "." "INBOX.INBOX.spamseen"
<sly@MIT.EDU> (Angie Kelic) writes:
> What's wrong:
> From the pine folders view (selecting "folder list" after
> starting pine), I selected "Add" to add a new folder and
> typed in INBOX.Spamscreen.
>
> This managed to create a second pine folder named "INBOX" with
> all of my inbox in it -- despite the fact that imtest believed
> this folder was named INBOX.INBOX.Spamscreen (which wasn't
> at all what I typed).
>
> To fix the problem I had to use imtest to rename INBOX.INBOX.Spamscreen
> to INBOX.foo. At which point pine showed a folder named "foo" with zero
> contents so I could delete it.
