Subject: mbox and imap folder list

From: Josko Plazonic <[email-masked]>
Date: Sun, 08 Jun 2003 17:05:30 -0400

Hi,

when imap server uses mbox driver shouldn't it not list mbox as one of 
the folders, i.e. shouldn't it hide it as long as mbox driver is in use? 
  I know it is not something dangerous but it could be confusing to some 
users ("hey, what's this mbox folder, let's delete it!").

Josko

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Sun, 8 Jun 2003 14:44:12 -0700 (PDT)

> users ("hey, what's this mbox folder, let's delete it!").

Empirical evidence from the past suggests that such hiding causes more
problems than it prevents.

It is also not a trivial matter to know if the mbox driver is "in use"; in
particular, if INBOX is not selected then it is necessary to do the INBOX
selection procedure (at least to the point of identifying the driver).  A
further complexity is in knowing whether a file named "mbox" is the INBOX
or some other file that happens to have that name (remember that multiple
paths can refer to the same directory).

I can offer you some pointers as to how to go about doing this, should you
wish to undertake the effort in your own copy, but I decline to get into
that business in the official source.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Josko Plazonic <[email-masked]>
Date: Sun, 08 Jun 2003 19:10:35 -0400

>selection procedure (at least to the point of identifying the driver).  A
Isn't it just enough to a) check if name is (something like) ~/mbox and 
if so then invoke mail_valid on INBOX and check if the returned DRIVER 
is of the type mbox?  That seems rather straightforward.  Can a client 
try to list folders before it is safe to invoke mail_valid? 

>paths can refer to the same directory).
I am (or was, read on) only concerned about normal use. If some genius 
decides he wants to subscribe manually to something like 
~/mail/../mail/../mbox - that's his problem.  Most imap clients will 
just use ~/mbox or mbox (or in unlikely case /homedir/mbox). 

>that business in the official source.
I was looking into this almost by accident while looking into another 
problem (for local setup) and since then I decided on an alternative 
solution that solves both issues - therefore I don't care as much anymore. 

My real goal was to reconcile imapd and pine concept of where mbox is.  
imapd will by default look into ~ for folders, unlike pine which looks 
for them in ~/mail dir.  Yes, it can be solved by using something like
set mail-subdirectory mail
in c-client.cf but then this breaks mbox driver as it will begin looking 
for ~/mail/mbox.  One solution is to then disable mbox driver in both 
(RedHat way) but I can't do that easily as it is not obvious which 
mbox's are pine's and which unix mail's or something third.  Another 
solution (one I am ashamed of thinking of and why I was trying to hide 
mbox) would be to teach pine to look for mbox in ~/mail.  Much better is 
to change mailboxfile function used in imapd so that if it's asked for 
~/mbox then do not translate that into ~/mail/mbox but just use it as it 
is (it also requires changing mbox driver to always use ~/mbox and not 
only mbox but that's trivial too).  This also prevents display of mbox 
in folder list and it is all very easy to do.

Josko P.

P.S.  Patched, recompiled - works - I love having source code :).

---

From: Mark Crispin <[email-masked]>
Date: Sun, 8 Jun 2003 17:01:02 -0700 (PDT)

On Sun, 8 Jun 2003, Josko Plazonic wrote:
> is of the type mbox?

No it isn't.

mail_valid() on ~/mbox will not return a driver type of mbox.  It won't on
mbox, or /homedir/mbox, or any of the other names either.

~/mbox is not a particularly likely path in IMAP.

mbox is not the only special name that can be an INBOX.

mail_valid() is a slow function.

> just use ~/mbox or mbox (or in unlikely case /homedir/mbox).

You've just identified three common forms of non-INBOX mailbox reference
and one relatively uncommon one.  There are two other more-or-less common
forms.  Plus the impact of symlinks.

This is quite enough reason for me not to want to get into that business.
You may or may not accept the validity of the slippery-slope argument; but
that's my story and I'm sticking to it.

> mbox's are pine's and which unix mail's or something third.

This is doing a great job of exemplifying my slippery-slope argument...

> Another
> mbox) would be to teach pine to look for mbox in ~/mail.

Huh?  Pine and imapd, built with the same c-client, will look for the mbox
file in the same place as long as you use the name INBOX.

You're not setting Pine's inbox-path to "mbox" are you?  Haven't you
noticed that mail isn't being transferred from the spool file?

>  Much better is

You've lost me here.  I don't have a clue as to why you did this, or how
you purport that this solves your problem.

Please be sure that you change the version number in both Pine and imapd
so that they identify themselves as being hacked versions.  I will quite
annoyed if I ever find myself spending hours in investigating a bug report
that turns out to be due to a hack.

-- Mark --

---

From: Josko Plazonic <[email-masked]>
Date: Sun, 08 Jun 2003 21:05:34 -0400

>mbox, or /homedir/mbox, or any of the other names either.
I didn't explain myself carefully - mail_valid("INBOX") should return 
DRIVER*drv, if it is using mbox then drv->name=="mbox".

>noticed that mail isn't being transferred from the spool file?

First, you seem not to be aware of how pine and imapd are being 
distributed with many operating systems.  Most linuxes build and 
distribute them separately - they are therefore not using exactly the 
same code base and there are no shared libraries involved so you can 
build pine and imap separately in any way you prefer. 

Now, about the setup.  pine is essentially unchanged and no, inbox-path 
is not set to mbox (please have some faith...).  The issue here is that 
the system is for both interactive login use and allows imap access.  
Some people use pine, some imap, some both, and some something third.  
They all have million files and do not want a closed imap server but 
/var/spool/mail kind of access+procmail. Now, so far I've had 
essentially unmodified imapd that offers folders under home dir - ~.  
That has proved to be a big pain. Not only will the imapd offer every 
single file as a folder but will do so with hidden (.*) files (I know 
how to turn it off), will easily get confused by symlinks pointing back 
to subdirs (as many window managers might do) and let me not begin 
listing broken imap clients e.g. the ones that assume they should 
subscribe to *every* folder - hence every file in users homedir.  Yes, 
nothing in imapd is really to blame - if everyone wrote imap client like 
it is in pine we wouldn't have issues at all, but I have to live with 
everything from eudora to outlook.

So the solution is to set mail-subdirectory to mail to simplify imap 
users (and my) life and it also makes it easier for many of my pine 
users that do not care exactly where their folders are to find them in 
an imap client.  Remember, goal here is to make it easy on the user and 
do away with instructions on how to setup mail subdir prefix manually in 
various clients (which are not read until it's too late).

Once you set the mail-subdirectory to mail that means that imap server 
will not see anymore ~/mbox as it is now looking for ~/mail/mbox and 
that's the problem.  I can't easily get rid of mbox files hence the 
change.  

Now that I think about it, I find it slightly non consistent for pine to 
expect folders to be in mail/ and imapd in ~/ and this is essentially 
what I am addressing - once you make them expect folders in same 
location, mbox driver is broken without changes I was mentioning 
(teaching mailboxfile not to translate ~/mbox into ~/mail/mbox *only* 
for imapd).

Josko P.

---

From: Mark Crispin <[email-masked]>
Date: Sun, 8 Jun 2003 18:28:25 -0700 (PDT)

> build pine and imap separately in any way you prefer.

I am aware of how Pine and imapd are distributed in many Linux systems.

However, I expect that people who are competant enough to customize Pine
and imapd would get the authoritative (and current) sources from the UW
FTP site, and that only novice users who want a binary-only install would
rely upon third-party RPMs with unknown hacks.

Substantial problems have occurred when you run Pine and imapd that were
not built from the same code base, including interoperability problems.
Although different versions of unmodified UW software should interoperate
(we're pretty careful about this!), third-party hacks have been known to
cause serious problems.

I recently wasted many hours (days, actually) in chasing an
interoperability problem that was caused by a certain Linux vendor's
"improvement" in the c-client library.  That "improvement" rendered all
programs with that "improvement" non-interoperable with those which did
not have it.  The result was trashed mail files.

Because of such support issues, I strongly recommend that nobody run a
Pine and imapd binary on the same machine that were not built from the
same code base.  Since Pine helpfully incorporates the IMAP toolkit
(including imapd), this can be inferred as my saying "use the imapd that
you built when you built Pine."

-- Mark --