Subject: Re: IMAP

From: Tomas Pospisek <[email-masked]>
Date: Sun, 19 Aug 2001 13:41:40 +0200 (CEST)

You wrote:

> However, Apple Mail is braindead in that it doesn't allow you to specify 
> where to look for mailboxes.
[...]
> In order to get Apple Mail to work I had t change the mailbox location. 
> With the most recent beta it's simply a compile flag (check FAQ and BUILD 
> in the docs directory).

Uhm yes. In Apple Mail you have to *simply* edit the binary and change the
mailpath I guess. So I'm not really sure who'd win in a braindamage contest.

What I want to say is, that it would be *really* useful to be able to reconfigure uw at runtime and not requiring to recompile the thing *only* because the mail's located in a different place. This even more as there
isn't such a thing as a default place for storing mail.

If every unix tool in the world would be following the same philosophy a
sysadmin would be spending 98% of his time recompiling apps.

*t

PS: Sorry for sending you a copy of the mail directly, it's what my
    ISP's braindead webmailer forces me to do. They probably ought to
    recompile it someday.

---

From: Mark Crispin <[email-masked]>
Date: Sun, 19 Aug 2001 04:43:14 -0700 (PDT)

On Sun, 19 Aug 2001 13:41:40 +0200 (CEST), Tomas Pospisek wrote:
> What I want to say is, that it would be *really* useful to be able to
> reconfigure uw at runtime and not requiring to recompile the thing *only*
> because the mail's located in a different place. This even more as there

Nobody has figured out a satisfactory means to "reconfigure UW at runtime",
otherwise it would have been done 10 years ago.

There is no default place for storing mail, but UW imapd needs to have a
default.  What's more, where mail is stored is often different from user to
user.  There is simply no good way to configure this per-user.  Remember that
most IMAP users have no shell access (or knowledge), so it does not good to
say "write a .xyzzyrc file".

If you edit UW imapd to use a different default (e.g. a subdirectory), then
you're changing it for *all* users of the system.  What's more, that new
global default applies even if the user doesn't have that subdirectory.

That's why the distribution version of UW imapd uses the home directory, which
is the closest to a reasonable default that exists, in the assumption that if
it is someplace else, a user can configure the client (which *is* under his
control) to look in that other place.

It is not an easy problem.

There is also an assumption that most programs do not do "LIST *" (the
equivalent of "ls -R") unless they are certain that this is what the user
really wants.  Would you put "ls -R" in every user's .login or .profile file?
Yet that is what Apple Mail is doing.

Blame Apple Mail, which is under the user's configuration control; not UW
imapd, which is not.

---

From: Sebastian Hagedorn <[email-masked]>
Date: Sun, 19 Aug 2001 14:53:21 +0200

-- Tomas Pospisek <[email-masked]> is rumored to have mumbled on Sonntag, 19. 
August 2001 13:41 Uhr +0200 regarding Re: IMAP:

>> With the most recent beta it's simply a compile flag (check FAQ and
>> BUILD  in the docs directory).
>

Well, the difference is that it's much harder to edit a *binary*... Please 
note that I've been an Apple user since 1987 and I love my Macs, so I do 
understand about hiding the complexity from the user, but in this case it's 
misguided. The UW imapd is *the* implementation of IMAP and while it 
doesn't explicitly say so in the RFCs (I guess) it's basically common sense 
to test your IMAP client against the reference implementation of the IMAP 
server!

>     ISP's braindead webmailer forces me to do. They probably ought to

Actually I always do that voluntarily as a courtesy to people who might be 
subscribed to the digest...

Cheers, Sebastian
--
Sebastian Hagedorn
Ehrenfeldgürtel 156, 50823 Köln, Germany
http://www.spinfo.uni-koeln.de/~hgd/
This mail was sent using Mac OS X

---

From: Jeff Zacharias <[email-masked]>
Date: Sun, 19 Aug 2001 20:13:48 -0400

I'd like to thank all of you who responded and helped me.  It's pretty 
amazing that I posted a problem at 8:30 PM on a Saturday night and by 
Sunday morning I had an explanation and a solution.  This allowed me to 
go into work today (Sonday) and fix the IMAP server to do what I needed 
while very few people were using the server.  Thanks !

For now, I made the change so that  the user's mail is stored in a 
subdirectoory in the user's account so that Apple Mail doesn't try to go 
through the whole directory.  Once I did this Apple Mail works great. In 
my case, my home directory on the mail server is the same home directory 
that I do all my work on and is over 2 GB in size with a lot of files 
and links.  We only have a few IMAP users, most don't move around and 
can use POP, so the subdirectory should not be a problem.

We all love Apple Mail so switching to Mulberry is not an option.  While 
Apple Mail may not be the most powerful IMAP client, we all really like 
the user interface and integration into Mac OS X.  I'm going to request 
the Apple Mail not do a LIST * but I don't know enough about IMAP to 
know why I would want IMAP to traverse my whole home directory.  I'm 
going to have to read up on IMAP.

Jeff Z

---

From: Chris Newman <[email-masked]>
Date: Mon, 20 Aug 2001 09:52:10 -0700

--On Sunday, August 19, 2001 4:43 -0700 Mark Crispin 
<[email-masked]> wrote:
> That's why the distribution version of UW imapd uses the home directory,
> which is the closest to a reasonable default that exists, in the
> assumption that if it is someplace else, a user can configure the client
> (which *is* under his control) to look in that other place.
>

This is a hard problem.  Indeed it may be one of those nasty "pick two of 
three" situations.  There are three desirable properties:

(1) All legacy Unix user mail files will be visible to IMAP client.
(2) No server side configuration
(3) No client side configuration: standard IMAP client will always work 
out-of-the-box with UW server

But only two of the three can be achieved with unextended IMAP.  The UW 
IMAP default achieves 1 and 2 and thus can not achieve 3.  Personally, I 
think 3 is the most important of these properties today (although probably 
not 5-10 years ago when this work was initially done) and it would benefit 
the IMAP community if the UW IMAP server implemented property 3.

It may also be possible to achieve all three properties if the IMAP server 
uses the NAMESPACE extension in a clever way.  If the UW IMAP server always 
creates a "mail" subdirectory and lists "mail/" as the personal namespace, 
I think that would be a much better default.  A compile switch for legacy 
installations of UW IMAP would be necessary, but with time it could be 
forgotten.

		- Chris

---

From: Mark Crispin <[email-masked]>
Date: Mon, 20 Aug 2001 10:00:01 -0700 (PDT)

On Mon, 20 Aug 2001 09:52:10 -0700, Chris Newman wrote:
> I think that would be a much better default.

I wish that it was that easy.  Pine makes that very decision, but Pine is a UI
and thus is at great liberty.

The problem with choosing/making a "mail" subdirectory is that not everybody
agrees that mail/ is the one true subdirectory.  It's certainly one of the
most popular choices (and probably the most popular choice).  But there are
partisans of other choices: Mail/, .mail/, Mailboxes/, Mailbox Files/, etc.

This isn't a "legacy IMAP" issue.  This is an issue of 30 years of UNIX MUAs,
all of which have their own ideas.  To make things worse, new UNIX MUAs with
new (and yet more bizarre) ideas pop up all the time; there's no standard to
use as ammunition to suppress "Mailbox Files/" (remember, you're talking about
people who don't care whether something is convenient from the shell).

Then comes the question of INBOX.  UW likes to have INBOX and other "incoming
folders" in the home directory on its dedicated IMAP servers, and other
(secondary) mailboxes in a mail/ subdirectory (and sometimes in multiple
subdirectories of that).  This isn't my preferred way of doing things, but
everybody else likes it a lot and it works well for them.

Last but not least, I want to preserve "no server-side configuration
required."  Sites may *opt* to do a server-side configuration; but it is never
required.  A server binary will work everywhere, out of the box; it just may
be that some client-side configuration is desirable.

As bad as the current situation may be, I can not make a change that will make
a modest increase in convenience for one portion of the community at the cost
of making things much worse for another portion.

I want to emphasize I am *always* interested in hearing suggestions for a
solution to this problem, and will always seriously consider any suggestion.
There is no need to convince me that a solution to this problem is desirable.
It's just a matter of finding the right solution.

Chris' suggestion was a clever one, with a twist (the use of NAMESPACE) that I
haven't seen before.  I'm not sure that NAMESPACE will solve it for us, due to
the way a certain client (possibly heading towards extinction) handles it.
But it's worth some additional musing.

So, thank you Chris, for pointing out a new direction that hadn't been
considered before.

---

From: "T.Pospisek's MailLists" <[email-masked]>
Date: Tue, 21 Aug 2001 12:13:53 +0200 (CEST)

> global default applies even if the user doesn't have that subdirectory.

Yes and IMO that default location should be configurable. Why?
Because most people nowadays install prepacked binary packages. And that
means that if you drop in that package it will "just not fit" the default
mail location of your users. So it'd be really nice (!) if one could just
change that location by reconfiguring uw. (uw-imapd stop; reconfigure;
uw-imapd-start). The alternative is either recompiling it every time
one needs to update or change that location or to configure/bend all the
other tools to comply to uw-imapd's (or the packager's) idea of where
email should be.

If there wouldn't be any reason to configure stuff, there wouldn't be the
need for a compile-option either. So there clearly is a need to keep this
configurable...

Please consider it. It would make uw-imapd a lot easier to
reconfigure, handle, try out, use for replacement of other mailserver
software, etc...

My 0.0125$
*t

----------------------------------------------------------------------------
             Tomas Pospisek
	     SourcePole   -  Linux & Open Source Solutions
	     http://sourcepole.ch
	     Elestastrasse 18, 7310 Bad Ragaz, Switzerland
	     Tel: +41 (81) 330 77 11
----------------------------------------------------------------------------