Btw, the volume on debian-user is to high for me to read on a regular
basis so you should cc me if you want to get a quick(er) answer.
On Mon, 24 Jan 2000, Joe Emenaker wrote:

> Argh! Okay. Does anybody want to suggest any other imap daemons that allow
> me to set the mailroot to $HOME/mail where it's supposed to be?
> 

You can always recompile the package to do it the way you want to.  That
is one of the benefits of open source after all.  It's a one line change
and I provide instructions.

> Problem now is that, when you refresh your folder list, you see all of your
> files in your home directory. Many of these differ substantially from the
> normal "inbox" format. I wouldn't be surprised to see a new slew of
> complaints from sysadmins because all of their users are having trouble
> opening their "core" folder. :)
> 

Which client are you using?  Everyone I use (MS outlook, Netscape,
Pine) let's you set this on the client-side.  All my folders are in
$HOME/mail.  I don't see any extraneous junk.

A "sysadmin" as opposed to "some random shmoe with the root
password" should diligently read documentation.  I haven't made a secret
of what I've done so it shouldn't come as a surprise.

> In all seriousness, though... I think that one of the mantras of
> user-friendliness these days is that the user shouldn't be allowed to easily
> select something wrong. If imapd uses $HOME for its mail directories,
> there's really nothing to prevent the user from being presented with a list
> of various files when they ask for a list of their mail folders.
> 

It is the admins responsibility to see that the users have a proper setup.

> Up to this point, one of the attractive features of Debian is that it
> *fixes* the brain-dead defaults put in by the people who originally wrote
> the software.
> 

But in this case, whether or not the  default is brain-dead is not easy to
determine.  To us having the mail root be $HOME/mail seems eminently
sensible.  But believe me many people disagrreed.

> Well, you could fix that by having some sort of big warning in the postinst
> script or something that required the user to hit a return so that you could
> be sure they see it.
> 

That would be even more obnoxious.  People hate useless warnings.  
Perhaps now we have debconf this could be done in a less intrusive way but
even then I would not be sure that people saw it.  Besides I already have
a big warning in the most natural place for someone to look for it.  
README.debian.

> Actually, what we *really* need is some sort of consensus. I mean, it would
> be pretty nice if imapd and other tools (like procmail) all looked in the
> same default location without any configuration. I know Elm and Pine used
> $HOME/Mail and $HOME/mail at one time.
> 

I can't speak for all Debian developers but I have you the users interests
in mind when I work on my packages.  If there was a consensus I would
adopt it no matter what my personal feelings are.  But in this case there
simply isn't one.

> Surely, I can't be the only one who sees the benefit in having all of the
> tools look in the same location for the "Sent Mail" folder, and "Drafts",
> etc.....
> 

You should make a proposal on the debian-policy list.  

> Aside from the fact that compartmentalization is a good thing. I mean,
> heck... while we're at it, why even bother using /var/spool/mail? Just dump
> all mail into /var/spool! :)
> 

It's not symmetric.  If the root is $HOME you can store your all
you folders in a subdirectory like mail if you like.  If it is $HOME/mail
someone who wants them in $HOME is out of luck.

> But I don't expect this to change anyone's mind, I guess. What I'm really
> after is a suggestion for a replacement imapd since I'm obviously going to
> have to purge Jaldhar's. I tried the Cyrus-Imap, but wasn't able to get that
> to work right out of the box.
> 

You hardly have to take such drastic measures but if the advice above is
unsuitable you can also try courier-imapd.  Haven't used it so I
couldn't tell you its' features though.

-- 
Jaldhar H. Vyas <[EMAIL PROTECTED]>

Reply via email to