Re: Attention: imapd gpoing back to $HOME as mailbox root
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 <jaldhar@debian.org>
Reply to: