rfc 3348 (CHILDREN extension) support?
Are there any plans to add RFC 3348 support to imapd? I'm currently
trying to improve performance in Horde IMP 4.x when accessing a
UW-IMAP server. IMP does 'LIST #shared/*' and then imapd returns a
huge list of shared folders, even though the user doesn't have access to
most of those folders.
C: a01 LIST #shared/*
S: * LIST (\NoSelect) / #shared/
* LIST (\NoSelect) / #shared/survey
* LIST (\NoSelect) / #shared/exec
* LIST (\NoSelect) / #shared/assembly
* LIST (\NoSelect) / #shared/senate
* LIST (\NoSelect) / #shared/mstu
* LIST (\NoSelect) / #shared/nct
...
a01 OK LIST completed
Our directory layout looks like this:
$ ls -ld /sharemail/shared/{,miles,admin}
drwxr-xr-x 497 imapshar staff 16384 Apr 7 18:30 /sharemail/shared/
drwxrws--- 2 imapshar miles 4096 Apr 7 15:07
/sharemail/shared/mile/
drwxrws--- 2 imapshar admit 4096 May 28 2003
/sharemail/shared/admit/
I'm not in any of these groups so I'll never have access to any
mailboxes within those directories. I'd like to have imapd not bother
returning those mailboxes at all. From playing with Cyrus imapd, which
does supprt RFC 3348, they seem to implement this behavior.
Looking at the imapd source, src/osdep/unix/dummy.c, around line 280,
seems to be the place to modify this behavior. After checking that an
object is a directory, I can check that the user actually has
permissions on the directory. Am I on the right track?
Cheers,
--
Matt
--
--
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/c-client-list.html
--
Re: rfc 3348 (CHILDREN extension) support?
Mark, Thanks for the quick response and the clarification. The way we organized our shared folders a user will never have access to a child mailbox is they don't have access to the parent and they would never create folders in #shared. Am I correct in that we'd want to modify dummy_list_work() to implement this? CHILDREN is being replaced by LISTEXT in the IETF IMAP Extensions Working Group. Among other desirable things, LISTEXT will require the client to indicate that it wants children information. The bad thing about CHILDREN is that a server that does it must always do it. With a UNIX filesystem, that means that you must open the directory and examine its contents, which means a lot more work in the case of % wildcards. You seem to be asking not about CHILDREN, but rather about suppressing listing of directories which you don't have access to. If you do that, you get into issues about why you can't create a mailbox with the name of a list-suppressed mailbox, or what about lower-level names that you can access. For example, suppose you can access /foo/bar/zap but not the superior /foo/bar -- do you really want to suppress bar from being listed in /foo? The point is, yes, you can do as you propose, but that isn't what CHILDREN is about, and you may create other problems for yourself (and your users).
can't seem to get pop starttls working
I built imap-2004a on Solaris 9 (OpenSSL 0.9.7d) like so: $ make gso PASSWDTYPE=pmb SSLTYPE=nopwd SSLDIR=/opt/local \ SSLCERTS=/var/ssl EXTRALDFLAGS='-R/opt/local/lib' I'm able to connect securely via port 995 (pop3s), but I can't connect via 110 using starttls. $ openssl s_client -connect mailtest:110 -starttls pop3 CONNECTED(0004) 16910:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: When I connect via netcat, and issue the capabilities command, I see starttls listed, but I get an immediate OK response when I issue the STLS command: $ nc mailtest 110 +OK POP3 mailtest 2004.88 server ready CAPA +OK Capability list follows: TOP LOGIN-DELAY 180 UIDL STLS . STLS +OK STLS completed IMAP is working for both starttls and ssl. How can I debug this further? Thanks. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: can't seem to get pop starttls working
pop with starttls works when I force the use of TLSv1. $ openssl s_client -connect mailtest:110 -starttls pop3 -tls1 I guess the client I was testing is broken. But my original openssl command worked for starttls against a non-UWash pop3 server. On Mon, Jul 26, 2004 at 03:27:44AM -0400, Matt Selsky wrote: I built imap-2004a on Solaris 9 (OpenSSL 0.9.7d) like so: $ make gso PASSWDTYPE=pmb SSLTYPE=nopwd SSLDIR=/opt/local \ SSLCERTS=/var/ssl EXTRALDFLAGS='-R/opt/local/lib' I'm able to connect securely via port 995 (pop3s), but I can't connect via 110 using starttls. $ openssl s_client -connect mailtest:110 -starttls pop3 CONNECTED(0004) 16910:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:226: When I connect via netcat, and issue the capabilities command, I see starttls listed, but I get an immediate OK response when I issue the STLS command: $ nc mailtest 110 +OK POP3 mailtest 2004.88 server ready CAPA +OK Capability list follows: TOP LOGIN-DELAY 180 UIDL STLS . STLS +OK STLS completed IMAP is working for both starttls and ssl. How can I debug this further? Thanks. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: [patch] hashed spool directories
My feeling about hashed spool directories is that this functionality is site-specific, with no obvious single definition of how it is to be implemented that applies in all instances. Consequently, I consider it to be something that should always be of the form of a third-party patch rather than an official part of c-client. I do encourage you to continue distributing this patch since it's likely to be useful for some people Thank you for your feedback. Procmail has included support for hashed spool directories since 3.13, so I don't think the feature is that site specific. (see procmail/src/authenticate.c #define MAILSPOOLHASH 0) For what it's worth, I suggest the following alternative implementation of your patch, which avoids needless rescans of the string: int i; char *u,*s; strcpy (tmp,MAILSPOOL); for (i = 0, u = myusername (), s = tmp + strlen (tmp); (*s++ = '/') (i spool_hash_depth) u[i]; *s++ = u[i++]); strcpy (s,u); See my new patch against imap-2004rc6. Further comments are welcome. Cheers.
Re: [patch] hashed spool directories
Sorry, I forgot to include the attachment.
Cheers.
On Sun, Feb 01, 2004 at 05:59:13PM -0500, Matt Selsky wrote:
My feeling about hashed spool directories is that this functionality is
site-specific, with no obvious single definition of how it is to be
implemented that applies in all instances. Consequently, I consider it to
be something that should always be of the form of a third-party patch
rather than an official part of c-client. I do encourage you to continue
distributing this patch since it's likely to be useful for some people
Thank you for your feedback.
Procmail has included support for hashed spool directories since 3.13,
so I don't think the feature is that site specific. (see
procmail/src/authenticate.c #define MAILSPOOLHASH 0)
For what it's worth, I suggest the following alternative implementation of
your patch, which avoids needless rescans of the string:
int i;
char *u,*s;
strcpy (tmp,MAILSPOOL);
for (i = 0, u = myusername (), s = tmp + strlen (tmp);
(*s++ = '/') (i spool_hash_depth) u[i];
*s++ = u[i++]);
strcpy (s,u);
See my new patch against imap-2004rc6. Further comments are welcome.
Cheers.
--- imap-2004.RC6/src/osdep/unix/env_unix.c 2004/02/01 21:30:40 1.2
+++ imap-2004.RC6/src/osdep/unix/env_unix.c 2004/02/01 22:55:31
@@ -92,6 +92,8 @@
/* block notification */
static blocknotify_t mailblocknotify = mm_blocknotify;
+static short spool_hash_depth = 0; /* 2 means spool is /var/mail/f/o/foo */
+
/* Note: setting disableLockWarning means that you assert that the
* so-modified copy of this software will NEVER be used:
* 1) in conjunction with any software which expects .lock files
@@ -818,7 +820,23 @@
{
char tmp[MAILTMPLEN];
if (!sysInbox) { /* initialize if first time */
-sprintf (tmp,%s/%s,MAILSPOOL,myusername ());
+int i;
+char *u,*s, c;
+static short endofstring = NIL;
+
+strcpy (tmp,MAILSPOOL);
+for (i = 0, u = myusername (), s = tmp + strlen (tmp);
+(*s++ = '/') (i spool_hash_depth);
+i++) {
+ /* deal with usernames shorter than hash depth */
+ if (u[i] !endofstring)
+ c = u[i];
+ else
+ endofstring = T;
+ *s++ = c;
+}
+strcpy (s,u);
+
sysInbox = cpystr (tmp); /* system inbox is from mail spool */
}
return sysInbox;
[patch] hashed spool directories
I noticed that some people have asked about hashed spool directories in
the past. This means the spool is /var/mail/s/e/selsky instead of
/var/mail/selsky
The attached patch against imap-2002e implements hashed spool
directories (which are disabled by default). If there are any changes
which would help this get accepted into the main distribution, please
let me know.
Cheers.
--- src/osdep/unix/env_unix.c 2003/10/04 03:51:51 1.2
+++ src/osdep/unix/env_unix.c 2004/01/06 05:25:52
@@ -92,6 +92,8 @@
/* block notification */
static blocknotify_t mailblocknotify = mm_blocknotify;
+static short spool_hash_depth = 0; /* 2 means spool is /var/mail/f/o/foo */
+
/* Note: setting disableLockWarning means that you assert that the
* so-modified copy of this software will NEVER be used:
* 1) in conjunction with any software which expects .lock files
@@ -820,7 +822,23 @@
{
char tmp[MAILTMPLEN];
if (!sysInbox) { /* initialize if first time */
-sprintf (tmp,%s/%s,MAILSPOOL,myusername ());
+int i;
+char c;
+
+sprintf (tmp,%s/,MAILSPOOL);
+
+for (i = 0; i spool_hash_depth; i++)
+{
+ /* deal with usernames shorter than hash depth */
+ if (strlen (myusername ()) i)
+ {
+c = myusername ()[i];
+ }
+ sprintf (tmp+strlen (tmp),%c/, c);
+}
+
+strcat (tmp,myusername ());
+
sysInbox = cpystr (tmp); /* system inbox is from mail spool */
}
return sysInbox;
