Subject: problems using Netscape Messenger with IMAP and mh

From: "Peter Derr" <[email-masked]>
Date: Mon, 07 Apr 97 13:48:26 -0400

I've been trying to use Netscape Messenger (in Communicator preview
release 3) with the UW IMAP server (latest version 4rev1) but it really
doesn't work well.   I was wondering if anyone has had any better
luck.

My mail is in mh folders and I've had good luck with Pine (using the
#mh/ prefix), although Pine doesn't appear to know how to discover
folders nested in the hierarchy.

So I told Netscape Messenger to use the #mh/ prefix.  It seems to find
all the folders (even the nested ones!).  It displays the message
headers and the first message I select OK, but then no matter what
message I pick, it always displays the first message I picked.  Also,
for some reason, the #mh/inbox folder shows no messages (although it
actually contains 700 messages).  It seems to be confusing "inbox" with
"INBOX" which it maps to the mail spool file.  It seems to need a
customizable "inbox-path" like Pine which could be used to specify the
"#MHINBOX".

It seems to work OK on flat-file mailbox format folders.

Any hints on how to make this work better?  (Other than convert from mh :-( )

Thanks,
Peter

---

From: Mark Crispin <[email-masked]>
Date: Mon, 7 Apr 1997 12:13:23 -0700 (PDT)

Netscape Messager is known to have many bugs with IMAP handling.  This isn't a
c-client issue, it's a Netscape issue.  Hopefully, the next Messager beta will
be much better; as it stands now it's unusable.

---

From: "Peter Derr" <[email-masked]>
Date: Mon, 07 Apr 97 15:32:49 -0400

> be much better; as it stands now it's unusable.

Yes, but this was the beta of Messenger that just came out in the last day
or so.  I had really hoped it would have been improved enough to be useful.
Anyway, I hope someone from Netscape is listening and tests it with the UW
server and mh folders....

Peter

---

From: Mike Macgirvin <[email-masked]>
Date: Mon, 7 Apr 1997 13:55:21 -0700 (PDT)

> customizable "inbox-path" like Pine which could be used to specify the

	First, you might try and rebuild your server with mh first on the
driver chain if this is possible. Sounds like another "fetch" driver is kicking
in on your secondary mailboxes before they reach the MH driver. 
	
	I don't think there's any quick answer to the #MHINBOX problem, because
if you use the default server-directory setting in Communicator, you'll end up
with #mh/#MHINBOX and no way to strip off the #mh without losing knowledge of
your other folders. 
	
	Although Mark claims that this isn't a c-client problem, I suggest that
it is... The server requires a non-standard string with which to designate what
is commonly referred to by the IMAP specification and other servers (including
his own) as "INBOX". It's (questionably) legal to do this, but I think you'll
find very little support for it in any clients except pine.
	In the final analysis, it doesn't matter how legal it is if other
client vendors aren't willing to perpetuate the "#MHINBOX" hack. Unfortunately,
I don't believe this particular driver of the UW server has enough of a
following to influence product decision makers.

	If MH format worked as invisibly in the UW server as the many other
mailbox drivers supported by c-client, Messenger should work with it as well as
it does them. 
;-(
	Please note: I am not directly involved with client engineering.

/* ==================== PERSONAL OPINION of ======================== */
/* Mike "The MAX" Macgirvin      mailto:[email-masked]             */
/* Postmaster General            http://www.netscape.com/people/max/ */
/* Messaging Server Development  Netscape Communications Corporation */
/* ================================================================= */

---

From: Mark Crispin <[email-masked]>
Date: Mon, 7 Apr 1997 14:01:37 -0700 (PDT)

On Mon, 7 Apr 1997 13:55:21 -0700 (PDT), Mike Macgirvin wrote:
> driver chain if this is possible. Sounds like another "fetch" driver is
> kicking in on your secondary mailboxes before they reach the MH driver.

That is extremely unlikely, since MH folders are directories, and no other
driver will respond to #mh.

> 	I don't think there's any quick answer to the #MHINBOX problem,
> because if you use the default server-directory setting in Communicator,
> you'll end up with #mh/#MHINBOX and no way to strip off the #mh without
> losing knowledge of your other folders.

This is a bug in Communicator.  If you have a default server prefix, you
should use a LIST command to have the server mash it together with user input
prior to sending it to a SELECT command.  Or, you should just not use default
server prefixes at all.

> 	Although Mark claims that this isn't a c-client problem, I suggest
> that it is... The server requires a non-standard string with which to
> designate what is commonly referred to by the IMAP specification and other
> servers (including his own) as "INBOX".

There is a good reason for this.  Many users have the remnants of an mh inbox
in their directory, from having tried mh years ago.  When c-client (in a long
ago version) automatically selected MH format for INBOX when it saw an MH
inbox, these users complained bitterly since MH format does not support sticky
flags.  Then, too, there were some people who wanted to have an INBOX separate
from an MH inbox.

That's the entire reason why #mhinbox was created.  #mhinbox means something
very special -- it means not just #mh/inbox but also "move all mail from the
real INBOX into #mh/inbox".

In any case, the fact that Netscape shows the wrong messages indicates a
definite bug in Netscape's handling of IMAP protocol.

> It's (questionably) legal to do this, but I think you'll

Every usable client allows me to specify my particular INBOX string without
having knowledge wired in that I can not change.  More importantly, usable
clients allow me to specify multiple INBOX strings, since multiple inboxes are
used frequently at UW and elsewhere.  Any client that does not do this is not,
in my opinion, usable.

"INBOX" is just a nebulous entity meaning a "primary" or "first level" INBOX.
Client vendors need to stop thinking of there being only one incoming mailbox.

> client vendors aren't willing to perpetuate the "#MHINBOX" hack.

A client which does not permit the user to issue arbitrary mailbox names is
not a complete IMAP client.  I strongly advise against trying to fob off an
incomplete IMAP client as a product, since this will give considerable aid to
your competitors.