export CAMEL_VERBOSE_DEBUG=1; killev; evolution-mail

wait till evo-mail says it's ready and then start evolution

everything that gets dumped to the evoloution-mail terminal, paste it
here so we can take a look.

Created attachment 41566 [details]
output of CAMEL_VERBOSE_DEBUG=1, loading remote mailstore

Created attachment 41567 [details]
CAMEL_DEBUG_VERBOSE=1 for loading with "show only subscribed folders" active

First attachment was generated with "Override server-supplied folder
namespace" active, set to "#mh/%". (I had been playing around with
this yesterday, trying to get at my mail.)  After I realized my
mistake, I generated new output with "Show only subscribed..." active,
"Override..." disabled.  Neither configuration allowed me to select
folders in the #mh namespace, however.

I'm confused... you set the namespace to "#mh/%" ?
you should just set it to "#mh"

I'll see if I can make a mh directory structure come monday and try to
reproduce this and see what the problem is.

in the meantime, could you also get a log of what happens when you try
to select a folder? That's mostly what I wanted to see before actually :-)

not that the above info isn't also useful. sorry, I should have been
more specific.

you might also want to do fix this:

received: * NO Mailbox vulnerable - directory /var/mail must have 1777
protection

for faster LSUB responses, you might also want to edit the imap
server's ~/.mailboxlist file and remove all the duplicate "#mh"
entires (you must have like 50 of them).

I did attempt to select folders.  Nothing obvious showed up in the
logs.  However, since I cannot select those folders from within
evolution, I would not expect the IMAP machinery to be invoked.  If
there's another debug flag I should set to dump output from higher up
the food chain (i.e., closer to the GUI), let me know.

As I mentioned in my previous entry, the Override = "#mh/%" was an
attempt at getting access to my mail.  It was the last trial of
several experiments.  I posted the output before I realized my
mistake, hence the second attachment.

The ~/.mailboxlist file contains no duplicate entries.  I have not
read the code too deeply, but I don't understand what all the LSUB
requests are for.  In the 2nd attachment above, A00003 LSUB "" "*"
returns the entire subscription list (which corresponds exactly with
the contents of the ~/.mailboxlist file), at least on my UW IMAP
server. However, several subsequent LSUB requests are issued, and I
would argue that the server's response to LSUB "" "%" (the multiple
#mh entries) is correct, since it returns an item for every entry in
the subscription list up to the first delimiter.  If one wanted just
the first level folders, the request should be something along the
lines of LSUB "#mh/" "%" (again, this works according to the UW IMAP
server).

seems to be a shell issue (shell see s a # in the name and says "nope,
won't select that")

doesn't seem mailer related at all thankfully

*** bug 236625 has been marked as a duplicate of this bug. ***

Any activity on this bug?  As far as I know, even with Evolution 1.2.2
(I tried the latest RH beta) it is still not possible to use MH
folders via IMAP.  Is you are relying on this, this is an extremely
severe problem that makes Evolution useless for some people and forces
them to downgrade to 1.0.8.

If anyone did succeed in using MH folders via IMAP in Evolution 1.2.x,
please tell so.

Workaround: By replacing # by %23 in all the entries in the .mailboxlist file,  
Evolution is able to read and write in the #shared namespace on UW Imapd 
(problem mentioned in bug 236625).  
The folder then appears as %23shared, but has the expected behaviour. 
This should also be the case with the #mh namspace (not tested).  

Replacing # by %23 in the .mailboxlist file on the IMAP server does
not make the #mh folders accessible from an Evolution client:  rather,
the folders disappear altogether from the folder list.  (The % is also
an IMAP protocol metacharacter.  There may be some fluke interactions
between Evolution, the IMAP server, and a single-level directory which
allowed this workaround to work at all.)

I am having exactly the same problem on redhat 9 with evo 1.4.  I can
access the mh folders just fine with balsa.

after spending too much time just working out how to make the server
output a #mh folder, ...

This is a bug in the shell code (at least, possibly other places in
mailer), its using the decoded path directly as a url path part, and
also using a uri fragment (i.e. anything after '#') for its own purposes.

e.g. e-shell-view.c:display_uri()

there are numerous places in that file and others where uri's are
incorrectly formed by doing a strconcat or sprintf.

a quick hack might be to change the camel code not to send out encoded
#'s, but the shell code should be fixed anyway.

the problem with a quick hack solution is it will later break the imap
cache and any imap filters setup, if it gets fixed properly later on.

Created attachment 42534 [details] [review]
hacky workaround

note that you probably need to rm the
~/evolution/mail/imap/user@host/.ev-store-summary file of the given
account if you've previously accessed the folders.

imap filters and cache will also be affected (but if you couldn't open
the given folders, its not a problem).

The workaround doesn't work for me.  I applied the patch on 1.2.2,
generated an rpm, removed the .ev-store-summary file, but no MH
folders show up (I use "#mh/" as folder namespace as before).

Even with ximian built 1.4.3 on rh 9 this problem still happens.

Could someone provide a step by step procedure beginning with
cleaning up what evolution remembers thru account set up?

I've tried many combinations of #mh and #mh/ and deleting files
etc. and nothing seems to work.  It works just fine with balsa.

Thanks, Joel

*** bug 251461 has been marked as a duplicate of this bug. ***

no longer relevant to 1.5