Subject: hardwiring the IMAP folders directory

From: "Thomas J. Lohman" <[email-masked]>
Date: Tue, 25 May 2004 16:38:21 -0400 (EDT)

Hi, forgive me if this is in the archives or has a well
known basic solution but what I would like to do is have
the imap server always look in a fixed location outside
the users' home dirs for folders.  e.g.

UNIX home dir: /homes/<username>
imap folder dir: /mailhome/<username>/folders

irregardless of what their IMAP client has set for the IMAP
folder directory.  In addition, I'd like to also have the
imap server think their home dir is /mailhome/<username>
instead of what the system says from the passwd information.

In our current setup of UNIX machines, users' home dirs are
scattered across 50 or so machines and we use 'amd' to make
sure no matter what machine the user logs in on they always
get the same home dir.  In order to support legacy mail
readers, I'd like our post office box server (where imap/pop
run) to also give the user this home dir if they choose to
login directly to it to use a mail client that reads things
directly from their INBOX/spool.  But what I'd like to
avoid is the other 50 or so filesystems all being automounted
when users read their mail with pop/imap.  It seems that the
imap server process looks in this directory for some things
which is causing the automount to take place - even if the
user has their folder directory set to a separate fixed
location such as /mailhome/<username>/folders.

Currently, our workaround is to give folks a separate home
dir on the post office box machine which overrides the
information in our NIS database.  This works except for the
legacy folks.  So, I am wondering if there is a more
elegant solution within the imap/pop code to deal with this.
If not, then I'll know to move to Plan B. :)

We're currently testing imap-2004.RC9 and that is the code
revision level I am currently looking at.

thanks very much,

--tom

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 May 2004 14:00:25 -0700 (Pacific Daylight Time)

On Tue, 25 May 2004, Thomas J. Lohman wrote:
> the users' home dirs for folders.

The answer is the routine mymailboxdir() in env_unix.c, which returns the 
"home directory" as far as IMAP is concerned.  Normally, it returns the 
string from myhomedir() which is the UNIX home directory.  But you can 
change mymailboxdir() to be anything else you'd like.

-- Mark --

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

---

From: Thomas Lohman <[email-masked]>
Date: Wed, 26 May 2004 11:40:10 -0400

Thanks for the quick reply Mark.

I believe I now have it looking in a fixed locale for folders but in 
testing with the Mozilla mail client and setting the IMAP Server 
Directory setting, I see that that overrides whatever I have fixed in
the server code.  i.e. if I set the client setting to 
/mail/folders/<username> then my server side setup is overridden.  It 
looks as though the client is prepending the entire path onto each 
folder name and thus when the server sees it, it sees it with the entire 
path.  Is there any way to strip away absolute folder paths at the 
server side so if it sees a folder /mail/folders/<username>/foo, it 
simply processes it as 'foo' and uses the default fixed location?

thanks very much,

--tom

> The answer is the routine mymailboxdir() in env_unix.c, which returns 
> the "home directory" as far as IMAP is concerned.  Normally, it returns 
> the string from myhomedir() which is the UNIX home directory.  But you 
> can change mymailboxdir() to be anything else you'd like.
> 
> -- Mark --
>

---

From: Mark Crispin <[email-masked]>
Date: Wed, 26 May 2004 08:46:15 -0700 (PDT)

On Wed, 26 May 2004, Thomas Lohman wrote:
> Is there any 
> way to strip away absolute folder paths at the server side so if it sees a 
> folder /mail/folders/<username>/foo, it simply processes it as 'foo' and uses 
> the default fixed location?

The routine mailboxfile() in env_unix.c transforms a mailbox name into a 
file path.  You can modify it to resolve the names however you want.

I'm not convinced that you really want to do what you suggest, as opposed 
to some alternative strategy, but it's your choice.

-- Mark --

---

From: Thomas Lohman <[email-masked]>
Date: Wed, 26 May 2004 13:34:38 -0400

Mark Crispin wrote:

> I'm not convinced that you really want to do what you suggest, as 
> opposed to some alternative strategy, but it's your choice.

Thanks.  Our main goal is to avoid all the NFS mounts that take place 
due to the fact that in our environment, all UNIX home directories are 
scattered across 50-60 machines.  That latter fact is really 
unchangeable at the moment.  In the past, we've had issues with machines 
not being accessible and thus causing problems for everyone reading 
their mail off of the post office server.  In addition, we'd like to 
centralize all IMAP folders in one location so it is easier to debug 
problems/do restores, etc.  We want to avoid the situation where Joe 
User is able to specify some random location to store his IMAP folders 
yet when there are problems with these, Joe User fails to let anyone 
know this fact.

I am not sure what the best approach to "solving" these issues is but I 
am open to any ideas anyone on the list has.

thanks very much,

--tom

---

From: Nicolas Kowalski <[email-masked]>
Date: Wed, 26 May 2004 20:02:01 +0200

Thomas Lohman <[email-masked]> writes:

[...]

> reading their mail off of the post office server.  In addition, we'd
> like to centralize all IMAP folders in one location so it is easier to
> debug problems/do restores, etc.  We want to avoid the situation where
> Joe User is able to specify some random location to store his IMAP
> folders yet when there are problems with these, Joe User fails to let
> anyone know this fact.

[...]

For my lab, I followed most of the instructions/patches found here:

http://carumba.com/imap/

It worked well for me.

Mes 2 cents.
-- 
Nicolas

---

From: Brad Arlt <[email-masked]>
Date: Thu, 27 May 2004 08:28:40 -0600

> For my lab, I followed most of the instructions/patches found here:

Two caveats with that one, EMPTYPROTO should be set to use the Unix
mailbox format, not MBX.  And clever users may create subfolders with
. as the first charactor.

-----------------------------------------------------------------------
   __o		Bradley Arlt			Security Team Lead
 _ \<_		[email-masked]		University Of Calgary
(_)/(_) 	Las hojas de coca no es droga. 	Computer Science

---

From: Nicolas Kowalski <[email-masked]>
Date: Fri, 28 May 2004 15:45:32 +0200

> . as the first charactor.

Yes, that's why I wrote "most of...". More precisely:

- I changed the definition of MyHomeDir in env_unix.c to
  /var/imap/<myusername>. 

- configured /etc/c-client.cf on the server as:

I accept the risk
set disable-automatic-shared-namespaces 1
set hide-dot-files 1
set new-folder-format mbx

- created mbx INBOX files in every /var/imap subdirectory.

-- 
Nicolas

---

From: "Shawn Walker" <[email-masked]>
Date: Fri, 28 May 2004 16:31:20 -0500

How can I get the CAPABILITY strings that is returned from the IMAP server  
 from c-client?  I want to be able to see what the IMAP server can do in  
order to vailidate that IMAP server can or cannot do.

Thanks,
Shawn

---

From: Mark Crispin <[email-masked]>
Date: Fri, 28 May 2004 14:52:36 -0700 (Pacific Daylight Time)

On Fri, 28 May 2004, Shawn Walker wrote:
> from c-client?  I want to be able to see what the IMAP server can do in order 
> to vailidate that IMAP server can or cannot do.

You can't get the capability string itself, but in imap-2004 there are 
several macros which you can use, e.g. LEVELNAMESPACE(stream) is non-zero 
if the IMAP server open on the stream has the NAMESPACE extension.

Refer to imap4r1.h for more information.  Also, look at the code which 
uses these in mtest.c.

Do not call these macros on a non-IMAP stream, or you will be promptly 
punished by a crash.

There are earlier versions of this interface in previous c-client 
releases.  Don't use those earlier interfaces.  Use the imap-2004 
interface.

You can call imap_cap(stream) directly, and in fact you have to in order 
to probe the extlevel.  Note, though, that the extlevel can change after 
the first time you call imap_structure(); basically, once c-client 
realizes that the server supports bodystructure extension data it won't do 
unnecessary HEADER.FIELDS fetching after the first time.

-- Mark --

---

From: "Shawn Walker" <[email-masked]>
Date: Wed, 02 Jun 2004 12:58:29 -0500

In imap-2004/src/osdep/nt/tcp_nt.c, tcp_open() "next" need to be initalize  
to NULL before calling ip_nametoaddr().  If gethostbyname() failed, next  
was "garbage" and so it was accessing invalid memory.

Thanks,
Shawn

---

From: Mark Crispin <[email-masked]>
Date: Wed, 2 Jun 2004 11:14:06 -0700 (PDT)

On Wed, 2 Jun 2004, Shawn Walker wrote:
> In imap-2004/src/osdep/nt/tcp_nt.c, tcp_open() "next" need to be initalize to 
> NULL before calling ip_nametoaddr().  If gethostbyname() failed, next was 
> "garbage" and so it was accessing invalid memory.

I believe that I have already fixed this in a different and more 
comprehensive way.  Please check the imap-2004a development snapshot:
 	ftp://ftp.cac.washington.edu/mail/imap-2004a.DEV.tar.Z
and verify that the problem that you observed is fixed.  Thanks.

-- Mark --

---

From: "Shawn Walker" <[email-masked]>
Date: Wed, 02 Jun 2004 14:24:06 -0500

The latest snap shot fixed the problem.

On Wed, 2 Jun 2004 11:14:06 -0700 (PDT), Mark Crispin  
<[email-masked]> wrote:

>> In imap-2004/src/osdep/nt/tcp_nt.c, tcp_open() "next" need to be  
>> initalize to NULL before calling ip_nametoaddr().  If gethostbyname()  
>> failed, next was "garbage" and so it was accessing invalid memory.
>