Subject: Re: Solaris imap-2004c1 can't find mailbox

From: Mark Crispin <[email-masked]>
Date: Mon, 7 Mar 2005 10:58:30 -0800 (Pacific Standard Time)

Just as a friendly reminder, the [email-masked] mailing list is for 
discussions of the IMAP protocol.  Software questions about UW imapd 
should go to [email-masked].

We're going to do something about these mailing list names.  Even though 
the actual software is called c-client, most people don't remember that 
name...

You don't need to build with SSLTYPE=none if you want to allow your Java 
client to connect with plaintext passwords.  SSLTYPE=unix will also work, 
that is:
 	make gso SSLTYPE=unix
This will build with SSL but without disabling plaintext passwords.

It should work given what you've described.  What, exactly, happens "when 
it tries to find the mailbox it can't"?  Do you get an error message?  If 
so, what is the message?  Do you get a seemingly empty INBOX?

What are the *exact* contents of the first line of a /var/mail/username 
file that exhibits this problem?

On Mon, 7 Mar 2005, Bruce Shaw wrote:
> Solaris 2.8.  Mailer is sendmail.  Mail shows up in /var/mail/username
>
>
> I'm compiling using gcc.
>
> make gso SSLTYPE=none
>
> because I need a java client to be able to connect with plaintext passwords.
> Yes I know it's bad.  We'll fix the app later.
>
> When I use mtest everything works fine.  I get prompted for a password but
> when it tries to find the mailbox it can't.  I've tried it with and without
> mbox, with and without a dummy first record (copied from another system).
> Another time I did this, pine helped me create the mailbox but this time it
> appears to have made matters worse. I've tried hardcoding the mail
> directory.
>
> Anybody got this working under Solaris 8?
>
> -- 
>
>
> This communication is intended for the use of the recipient to which it is
> addressed, and may contain confidential, personal and or privileged
> information. Please contact us immediately if you are not the intended
> recipient of this communication, and do not copy, distribute, or take action
> relying on it. Any communication received in error, or subsequent reply,
> should be deleted or destroyed.
>
> -- 
> -----------------------------------------------------------------
> For information about this mailing list, and its archives, see:
> http://www.washington.edu/imap/imap-list.html
> -----------------------------------------------------------------
>
>

-- Mark --

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

---

From: Mark Crispin <[email-masked]>
Date: Tue, 8 Mar 2005 19:12:17 -0800 (Pacific Standard Time)

On Tue, 8 Mar 2005, Bruce Shaw wrote:
> I reinstalled everything the way I figured it should be set up and left it
> overnight intending to fight with it in the morning.  During the night a
> message came in and was successfully processed.  /var/mail/username now
> appears to contain a valid "DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL
> DATA" record.  I guess IMAP just needed an incoming email message.

This is strange.  The software is supposed to work even if the mailbox is 
empty or doesn't exist.  What was the problem that you were experiencing?

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Wed, 9 Mar 2005 17:38:07 -0800 (Pacific Standard Time)

On Wed, 9 Mar 2005, Bruce Shaw wrote:
> Using mtest or pine (configured for IMAP).  It would say "mailbox does not
> exist".

There's no such message in c-client.

If the message was "no such mailbox", that message should never occur with 
INBOX, even if an underlying file does not exist.

Did you modify the software, or obtain the software from a third-party 
that modified it?  In particular, did you remove the dummy driver?  [Some 
sorcerer's apprentices claim that the dummy driver should be removed. 
They are wrong.]

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Mar 2005 08:23:32 -0800 (PST)

On Thu, 10 Mar 2005, Bruce Shaw wrote:
> I'm not using INBOX.   I'm using /var/mail/whatever-the-user-name-is.

Ah.  I understand now.

When you give a specific filename, then a file by that name must exist.

However, there is no reason why you should need to do this; to refererence 
your own mailbox, you should always use the name INBOX.

Use of the name INBOX prevents this problem.

-- Mark --

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Mar 2005 11:53:35 -0800 (PST)

On Thu, 10 Mar 2005, Bruce Shaw wrote:
> OK, now I'm confused.  Back awhile ago I was using a variant of cyrus-IMAP
> that required a specific file named "INBOX" to be sitting in your home
> directory.

Yes, you're confused, and I think that it's a good idea to resolve the 
confusion, because otherwise you may have substantial problems in the 
future.

Cyrus IMAP uses its own file structure (no home directories), so I don't 
think that you were using Cyrus (or if you were you've misunderstood what 
was going on).

> I'm relying upon sendmail to handle mail file creation.  It has a mind of
> its own.

That's unimportant.  See below.

> Sendmail does not support that AFAIK.

This is unimportant.  INBOX is not a sendmail concept; it is an IMAP 
concept.

The IMAP server accepts the name INBOX from the IMAP client, and the IMAP 
server knows how to translate the concept of INBOX into whatever your 
mailer (e.g. sendmail uses).  More importantly, IMAP knows that INBOX 
always exists (even if there is currently no corresponding file on the 
filesystem -- it treats that situation as an empty INBOX).

There is no need to reference the /var/mail/<username> file by that name 
from an IMAP client.  Use INBOX in the IMAP client, and let the IMAP 
server do the magic that it does so well.

The whole point of INBOX is that the IMAP client does not ever need to 
know what sort of mailer you have; you may have sendmail, Exchange, or 
Bombastic Blurdybloop's Best Bit Basher.  As far as the IMAP client is 
concerned, it's all INBOX.

> Hence we were creating the /var/mail/whatever file and populating it with a
> dummy record.  I suspect the nature of that dummy record may have changed
> from version 2000 to 2004.

In effect, you didn't understand the magic that was going on, and you used 
magic to try to get the right result.  Unbeknownst to you, it was black 
magic.

There is one of those fortunate cases where you can solve the problem by 
doing less instead of more.  Don't create files with those dummy records 
(just let the software do it), and don't try to use the /var/mail names; 
just use INBOX and let all the good magic work for you.  :-)

Good luck.  Please keep me informed on how it goes.

-- Mark --