Subject: query all IMAP folders via POP3

From: Florian Effenberger <[email-masked]>
Date: Sat, 21 Aug 2004 18:31:51 +0200

Hi there,

is there any option or POP3 server that has the ability to query all 
IMAP folders via POP3? I don't want to receive only the messages from 
the Inbox when doing POP3 downloads, but messages from all folders.

Is that possible? (I know that the folder structure will not be 
preserved via POP3.)

Thanks
Florian
-- 
------------------------------------------------------------------
 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: Sat, 21 Aug 2004 09:34:50 -0700 (PDT)

On Sat, 21 Aug 2004, Florian Effenberger wrote:
> is there any option or POP3 server that has the ability to query all IMAP 
> folders via POP3?

The short answer is "no".

POP3 does not have that capability.

-- Mark --

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

---

From: Florian Effenberger <[email-masked]>
Date: Sat, 21 Aug 2004 18:38:20 +0200

Hi Mark,

> POP3 does not have that capability.

Any chance that the UW IMAP pop proxy will get this functionality? What 
I thought about was doing filtering directly on the server via procmail. 
In order to have webmail and POP3 folders (=local mail program folders) 
synced a header like

	X-Folder: Foldername

would be good when messages get fetched via POP3 proxy.

What do you think about this?

Florian

---

From: Mark Crispin <[email-masked]>
Date: Sat, 21 Aug 2004 10:09:19 -0700 (PDT)

On Sat, 21 Aug 2004, Florian Effenberger wrote:
> Any chance that the UW IMAP pop proxy will get this functionality?

There's always a "chance" that anything can happen.

However, some chances are extremely small; and this is one of them.

An attempt to make POP3 support multiple IMAP mailboxes is like trying to 
make an abacus execute a large C program.  Yes, with enough contortions 
and hard work, it can be done.  But it's a pointless exercise.

The work required (both in software development) and in runtime (each time 
the POP3 server is run) is substantial.  A better use of such resources is 
in developing an IMAP client.  POP3 should be used for the purposes that 
POP3 was designed to accomplish.  If you have IMAP needs, you should use 
IMAP.

-- Mark --

---

From: Florian Effenberger <[email-masked]>
Date: Sat, 21 Aug 2004 19:21:51 +0200

Hi Marc,

thanks for making that clear. I guess I'll switch from POP3 to IMAP 
then. ;-)

Thanks!
Florian

---

From: Erik Kangas <[email-masked]>
Date: Sun, 29 Aug 2004 13:06:05 -0400

Hello List/Mark,

I am looking at ways to extend UW-IMAP soas to be able to support very 
large numbers of users on a Linux system.  The problem arises from the 
standard limit of UIDs being <= 65535 on Linux systems without re-compiling 
the kernel and "taking your chances".  There are two issues involved, 
assuming you have a large number of users:

1. Being able to put more than 65k on one machine

2. Being able to put arbitrary users on arbitrary machines where the UIDs 
of your users in your DB can be well over 65k.

We already have one solution that solves #2 partially by mapping our real 
global UIDs to local ones for Linux's use on the servers in question; we 
are looking at other possible solutions that cover both #1 and #2 while 
still using UW-IMAPd.

One idea that I have is to:

1. use pam_mysql for authentication
2. put all the email for all user in 1 nice hashed directory tree that is 
owned by a SINGLE user
3. modify UW-IMAP to construct the location of a user's subtree within the 
global tree from the user login (i.e. query mysql).
4. modify UW-IMAP to now allow any access to any files outside the user's 
subtree.
5. Add any additional code to UW-IMAP so that the users do not have to be 
in the /etc/passwd file -- all user-specific info is read from mysql.

The result, if this is doable in a way that is not very intrusive to 
UW-IMAP, would be the ability to have any number of users on a machine 
because they would all be virtual [no real linux users].

Has something like this been done?  Are there any serious concerns to be 
aware of in this type of scenario?  What are the main hooks that one should 
look at for perusing this type of patch?

Delivery of email to "virtual" users in a scenario like this is completely 
doable and we already have a solution for that.  Sending authenicated 
outbound email is very doable.  It is only the UW-IMAPd/POP3d component 
that seems tricky.

Thank you,
-Erik Kangas

PS - While certain other IMAP servers that shall remain nameless do handle 
this particular user virtualization issue innately, there are certain 
reasons why we like and want to stick with UW-IMAP.  These are mostly 
requirements such as:
* Easy integration of the email store with sendmail/procmail
* Fast shared access to email folders (i.e. mbx for indexed formats)
* SSL support
* Complete and solid and well tested IMAP v4.1 support
* Built-in full support for: SEARCH and SORT commands.

-- 

Erik Kangas, Ph.D. --- President of Lux Scientiae, Incorporated

Lux Scientiae:       1-800-441-6612        P.O. Box 326
FAX:                 1-413-332-0598        Westwood, Massachusetts
Cell:                1-617-596-9558        02090, USA
AIM Chat:            Screen Name "luxsci"

[email-masked]  ---  http://luxsci.com

---

From: Rich Graves <[email-masked]>
Date: Sun, 29 Aug 2004 13:50:20 -0400 (EDT)

> in the /etc/passwd file -- all user-specific info is read from mysql.

No modifications to imapd should be required for 1-4. Read the docs on
blackbox mode.

For 5, there are 4 simple functions you can rewrite. Read docs/CONFIG.
-- 
Rich Graves <[email-masked]>
UNet Systems Administrator

---

From: Mark Crispin <[email-masked]>
Date: Sun, 29 Aug 2004 11:09:07 -0700 (PDT)

If you need me to elaborate on Rich Graves' reply, please let me know. 
You don't really need to go as far as black box mode; but the docs/CONFIG 
file should definitely be at the top of your reading list.

The real problem that you have to face is security.  imapd uses the UNIX 
filesystem to authorize file access.  If you allow other-user access at 
all you have to have as many unique access tokens as there are unique 
users.  Otherwise joe would have free access to sally's files, just 
because joe and sally have the same UNIX UID.

If you disable other-user access in imapd (read about restrictBox), then 
you don't have to worry about this as much.  Of course, then you have to 
trust imapd to make the right checks in all circumstances and that no 
clever hacker can figure a way around it.

I personally believe in 32-bit UNIX UIDs.

-- Mark --

---

From: Erik Kangas <[email-masked]>
Date: Sun, 29 Aug 2004 14:29:06 -0400

> I personally believe in 32-bit UNIX UIDs.

I just found out that Linux kernels 2.4+ are 32bit UID native, so that 
solves much of the problem!

The only remaining issue is the fact that using an database-based 
authenticator (as opposed to a password file) can be much faster when you 
have a lot of users on one machine... so we may still persue some of the 
modifications that would enable that.

Thank you,

-Erik Kangas

--

---

From: Mark Crispin <[email-masked]>
Date: Sun, 29 Aug 2004 11:42:47 -0700 (PDT)

> modifications that would enable that.

Most Linux builds are PAM-based these days, so you're probably already set 
at the imapd end.

-- Mark --