Re: /Noinferiors on INBOX

2003-03-28 Thread Morgan Sackett
Changing altnamespace to no results in seeing the folders, but they 
appear at the same level as INBOX.  That means that I cannot select a 
subfolder called INBOX.Trash, for example.  This will break all of my users.

It seems as though this behaviour changes from version to version. 
1.5.x gave the nested subfolders with altnamespace=no.  2.0.16 gave 
nesting with altnamespace=yes.  Now, with 2.1.12, altnamespace=yes gives 
/Noinferiors, and altnamspace=no gives same level folders.  

HELP!

Ken Murchison wrote:

Morgan Sackett wrote:
 

Should this happen?  I do have subfolders in the mailbox, but clients
won't look at them.  Also, clients report errors in trying to create or
append messages into a subfolder.  However, I can create a new folder
both through cyradm, and directly logged in with a CREATE command.
   

Have you enabled altnamespace recently?

 





Can't understand

2003-03-28 Thread Sebastian Konstanty Zdrojewski
Hi,

since when I installed the server I am getting these information in my 
imapd.log file.

Mar 28 12:49:31 nexus lmtpd[9970]: lmtp connection preauth'd as postman
Mar 28 12:49:31 nexus master[10010]: about to exec /usr/cyrus/bin/lmtpd
Mar 28 12:49:31 nexus lmtpunix[10010]: executed
Mar 28 12:49:32 nexus lmtpd[9970]: duplicate_check: 
[EMAIL PROTECTED]  user.sergio_filippi  0
Mar 28 12:49:33 nexus lmtpd[9970]: mystore: starting txn 2147486981
Mar 28 12:49:33 nexus lmtpd[9970]: mystore: committing txn 2147486981
Mar 28 12:49:33 nexus lmtpd[9970]: duplicate_mark: 
[EMAIL PROTECTED]  user.sergio_filippi  1048852172
Mar 28 12:50:20 nexus master[945]: process 1 exited, status 0
Mar 28 12:51:57 nexus pop3d[9997]: accepted connection
Mar 28 12:51:57 nexus master[10012]: about to exec /usr/cyrus/bin/pop3d
Mar 28 12:51:57 nexus pop3[10012]: executed
Mar 28 12:51:57 nexus pop3d[9997]: login: [192.168.0.180] sergio_filippi 
plaintext
Mar 28 12:52:13 nexus master[945]: process 9970 exited, status 0

By the way everything works fine.

And something more. Where can I raise the timeout for an imapd daemon to 
exit. Let me explain. One user has her Outlook set to access the Imap 
server. Every some time of inactivity the client returns a Timeout 
error. As obvious, I set the idle timeout of the client to 1 minute, but 
I don't like this solution too much... any idea?

Thanks in advance,

En3pY

--

Sebastian Konstanty Zdrojewski
IT Analyst
Neticon S.r.l.
via Valtellina, 16 - 20159 Milano
Tel. +39 02 68.80.731
FAX +39 02.60.85.70.41
Cell. +39 349.33.04.311
ICQ # 97334916
--
Web: http://www.neticon.it/
E-mail: [EMAIL PROTECTED]



createmailbox in Java, possible?

2003-03-28 Thread Palle Girgensohn
Hi!

Is there any API for creating mailboxes and setting acls from Java, or C ?

/Palle



Bare newlines

2003-03-28 Thread Sebastian Konstanty Zdrojewski
I was attempting to move an email message from a local account onto an 
IMAP directory located on Cyrus. The client I am using is Netscape Mail 
and usually it gives me no problems. This time, I am not able to move 
the message because the client gives the following error:

Unable to perform operation. Message contains bare newlines.

The message has an attached PDF file (2Mb size) and a signature with 
image integrated. Any idea of what can be my problem?

TIA - En3pY

--

Sebastian Konstanty Zdrojewski
IT Analyst
Neticon S.r.l.
via Valtellina, 16 - 20159 Milano
Tel. +39 02 68.80.731
FAX +39 02.60.85.70.41
Cell. +39 349.33.04.311
ICQ # 97334916
--
Web: http://www.neticon.it/
E-mail: [EMAIL PROTECTED]



Re: createmailbox in Java, possible?

2003-03-28 Thread Rob Siemborski
On Fri, 28 Mar 2003, Palle Girgensohn wrote:

 Is there any API for creating mailboxes and setting acls from Java, or C ?

C-Client (http://www.washington.edu/imap/), will let you create mailboxes,
but doesn't support ACLs.

Writing an IMAP client that just handles creates and ACL manipulations is
really easy though (use imtest as a starting point, and see
doc/specs.html for the appropriate RFCs).

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper



case insensitive delivery

2003-03-28 Thread Chris Picton
Hi

I am using postfix as a MTA, and it sends emails through with the case
unchanged to cyrus (either via cyrus, or deliver).

Is there any way to get cyrus to accept for both chrisp and ChrisP, and
deliver them to the same mailbox chrisp?

Regards
-- 
-+--
Chris Picton | PGP Key ID: 9D28A988 (wwwkeys.pgp.net)
 Solutions Developer | PGP Key Fingerprint:
 Tangent Systems | 2B46 29EA D530 79EC D9EA 3ED0 229D 6DD6 9D28 A988
[EMAIL PROTECTED] | http://www.tangent.co.za/keys/chrisp.asc
-+--


signature.asc
Description: This is a digitally signed message part


Re: Bare newlines

2003-03-28 Thread John Alton Tamplin
Sebastian Konstanty Zdrojewski wrote:

I was attempting to move an email message from a local account onto an 
IMAP directory located on Cyrus. The client I am using is Netscape 
Mail and usually it gives me no problems. This time, I am not able to 
move the message because the client gives the following error:

Unable to perform operation. Message contains bare newlines.

The message has an attached PDF file (2Mb size) and a signature with 
image integrated. Any idea of what can be my problem?
In IMAP, messages are required to have \r\n as line terminators, not 
just \n.  Many other IMAP servers (or mail clients' local folders) do 
not enforce strict RFC compliance, while Cyrus does -- when we converted 
from UW-IMAP to Cyrus I had to write code to munge messages into the 
proper format (8 bit or null data in headers, and bogus headers are the 
other two issues you will likely run into).

--
John A. Tamplin   Unix System Administrator
Emory University, School of Public Health +1 404/727-9931




Re: Problem with cyradm and krb5 */admin principals

2003-03-28 Thread Paul M Fleming
I've attached the code. Put this in the lib directory as auth_regexp.c
When you configure you must do --with-auth=regexp This code requires
POSIX regex functions, you may have to include additional libraries
depending on the OS. On RedHat the regex functions are part of libc.
Someday I'll get a web page up with this code and some more
explaination.

Once compiled with this module you can use any regular expression to
match identifiers.. 

For example from my configs:

admins: regexp:.+/admin
proxyservers: regexp:murder/.+\.siumed\.edu
lmtp_admins: regexp:murder/.+\.siumed\.edu



Ben Poliakoff wrote:
 
 That certainly would explain this behavior.
 
 How involved is your regex auth module?  And would you feel comfortable
 sharing it?
 
 Ben
 
 * Paul M Fleming [EMAIL PROTECTED] [030326 13:10]:
  The / is considered an illegal character under auth_unix. I wrote a
  regular expression based auth module which will work with Kerb V. That
  is how we solved the problem..
 
 
 
  Rudolph T Maceyko wrote:
  --On Wednesday, March 26, 2003 11:47:34 -0800 Ben Poliakoff
  [EMAIL PROTECTED] wrote:
  
  Anyone out there using */admin principals with cyradm?
  
  
  I tried and gave up, so I'd like to discover the way to do this too...
  It worked under 2.0.x releases of Cyrus IMAPd.
  
  Rudy
  
  
 
 --
 ---
 Ben Poliakoff   email: [EMAIL PROTECTED]
 Reed College  tel:  (503)-788-6674
 Unix System Administrator  PGP key: http://www.reed.edu/~benp/key.html
 ---
 0x6AF52019 fingerprint = A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019/* auth_regexp.c -- Regular Expression Authorization 
   based on Unix passwd file authorization by CMU

   Paul M Fleming
   Nov 17, 2002
   Southern Illinois University
   School of Medicine
   [EMAIL PROTECTED]

*/

#include config.h
#include stdlib.h
#include ctype.h
#include string.h
#include regex.h
#include syslog.h
#include auth.h
#include xmalloc.h

const char *auth_method_desc = regexp;

struct auth_state {
char userid[81];
};

static struct auth_state auth_anonymous = {
anonymous
};

/*
 * Determine if the user is a member of 'identifier'
 * Returns one of:
 *  0   User does not match identifier
 *  1   identifier matches everybody
 *  2   User is in the group that is identifier
 *  3   User is identifer
 */
int auth_memberof(auth_state, identifier)
struct auth_state *auth_state;
const char *identifier;
{
regex_t compiled_reg;


if (!auth_state) auth_state = auth_anonymous;
 
if (strcmp(identifier, anyone) == 0) return 1;

if (strcmp(identifier, auth_state-userid) == 0) return 3;

if (strncmp(identifier, regexp:, 7) != 0) return 0;

/* we're looking at a regular expression 
   compile and compare identifier to auth_state-userid
*/

if ( regcomp(compiled_reg,identifier+7,REG_EXTENDED | REG_NOSUB) != 0 ) return 0;

/* we have a compiled reg exp. evaluate */
if ( regexec(compiled_reg,auth_state-userid,0,0,0) == 0 ) return 2;

return 0;
}

/* Map of which characters are allowed by auth_canonifyid.
 * Key: 0 - not allowed (special, ctrl, or would confuse Unix or imapd)
 *  1 - allowed, but requires an alpha somewhere else in the string
 *  2 - allowed, and is an alpha
 *
 * At least one character must be an alpha.
 *
 * This may not be restrictive enough.
 * Here are the reasons for the restrictions:
 *
 * forbidden because of MUTF-7.  (This could be fixed.)
 * :forbidden because it's special in /etc/passwd
 * /forbidden because it can't be used in a mailbox name
 * * %  forbidden because they're IMAP magic in the LIST/LSUB commands
 * ?it just scares me
 * ctrl chars, DEL
 *  can't send them as IMAP characters in plain folder names, I think
 * 80-FF forbidden because you can't send them in IMAP anyway
 *   (and they're forbidden as folder names). (This could be fixed.)
 *
 * + and - are *allowed* although '+' is probably used for userid+detail
 * subaddressing and qmail users use '-' for subaddressing.
 *
 * Identifiers don't require a digit, really, so that should probably be
 * relaxed, too.
 */
static char allowedchars[256] = {
 /* 0  1  2  3  4  5  6  7  8  9  A  B  C  D  E  F */
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 00-0F */
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 10-1F */
1, 1, 1, 1, 1, 0, 0, 1, 1, 1, 0, 1, 1, 1, 1, 1, /* 20-2F */
1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 0, 1, 1, 1, 1, 0, /* 30-3F */

1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, /* 40-4F */
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 1, /* 50-5F */
1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, /* 60-6F */
2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 1, 1, 1, 1, 0, /* 70-7F */

0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,

Re: Bare newlines

2003-03-28 Thread Bill Earle
On Fri, 28 Mar 2003, John Alton Tamplin wrote:

 Sebastian Konstanty Zdrojewski wrote:

  I was attempting to move an email message from a local account onto an
  IMAP directory located on Cyrus. The client I am using is Netscape
  Mail and usually it gives me no problems. This time, I am not able to
  move the message because the client gives the following error:
 
  Unable to perform operation. Message contains bare newlines.
 
  The message has an attached PDF file (2Mb size) and a signature with
  image integrated. Any idea of what can be my problem?

 In IMAP, messages are required to have \r\n as line terminators, not
 just \n.  Many other IMAP servers (or mail clients' local folders) do
 not enforce strict RFC compliance, while Cyrus does -- when we converted
 from UW-IMAP to Cyrus I had to write code to munge messages into the
 proper format (8 bit or null data in headers, and bogus headers are the
 other two issues you will likely run into).

John,

How are you dealing with 8 bit or null data in headers, and bogus
headers?

- Bill



 --
 John A. Tamplin   Unix System Administrator
 Emory University, School of Public Health +1 404/727-9931






/opt/cyrus/mailboxes.db: Not enough space

2003-03-28 Thread Jim Howell
Hi,
	Last night we had this happen again on one of our systems.  What is the 
current thinking as to the cause and/or fix to this problem?  I saw one 
response last time that said backing off to DB 4.0 would help.  Again the 
versions of things are:

Sendmail 8.12.8
Cyrus 2.1.11
Berkeley DB 4.1.24
Thanks.
Jim


Hi,
	I have an interesting problem.  Over the weekend our syslog forwarder went 
beserk generating over 300,000 messages to about 6 people.  This morning 
our three new Cyrus systems went belly up, (yes that is a technical term), 
actually the master daemon seemed to eventually freeze up.  The only real 
error msgs I can find are these:
Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR: 
opening /opt/cyrus/mailboxes.db: Not enough space
Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR: 
opening /opt/cyrus/mailboxes.db: Not enough space
Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR: 
opening /opt/cyrus/mailboxes.db: Not enough space
Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR: 
opening /opt/cyrus/mailboxes.db: Not enough space
Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR: 
opening /opt/cyrus/mailboxes.db: Not enough space

Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000 
messages a day with no trouble.  I don't believe space is really an issue, 
here is a df -k from one of the systems.

Filesystemkbytesused   avail capacity  Mounted on
/dev/md/dsk/d0   1984564  904568 102046047%/
/proc  0   0   0 0%/proc
fd 0   0   0 0%/dev/fd
mnttab 0   0   0 0%/etc/mnttab
/dev/md/dsk/d1962573  255248  64957129%/var
swap 28642528  32 28642496 1%/var/run
swap 28655440   12944 28642496 1%/tmp
/dev/md/dsk/d4   50408148134 4982272 1%/users
/dev/md/dsk/d3   5040814  452439 453796710%/opt
/dev/vx/dsk/po8_dg01/logvol01
 5160542  115891 4993046 3%/logs
/dev/vx/dsk/po8_dg01/mqueuevol01
 103218844986 10213680 1%/mqueue
/dev/vx/dsk/po8_dg01/cyrus_data_vol01
 41287586  126222 40748489 1%/opt/cyrus
/dev/vx/dsk/po8_dg01/sendmailvol01
 41287586  603402 40271309 2%/opt/sendmail_vol
/dev/vx/dsk/po8_dg01/cyrus_app_vol01
 41287586  147526 40727185 1%/opt/cyrus_vol
/dev/vx/dsk/po8_dg01/spoolvol01
 103218991  679107 101507695 1%/var/spool/mail
swap 28642640 144 28642496 1%/opt/cyrus/proc
/dev/vx/dsk/po8_dg01/appvol01
 20643785   54397 20382951 1%/applications
This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8 
and, Sendmail 8.12.8.  Anyone seen this before?  Thanks.
Jim 



Re: /opt/cyrus/mailboxes.db: Not enough space

2003-03-28 Thread Rob Siemborski
If you haven't had the suggestion before, it's really not recommended to
use Berkeley DB for your mailbox list.  Use skiplist instead.

-Rob

On Fri, 28 Mar 2003, Jim Howell wrote:

 Hi,
   Last night we had this happen again on one of our systems.  What is the
 current thinking as to the cause and/or fix to this problem?  I saw one
 response last time that said backing off to DB 4.0 would help.  Again the
 versions of things are:

 Sendmail 8.12.8
 Cyrus 2.1.11
 Berkeley DB 4.1.24

 Thanks.
 Jim



 Hi,
   I have an interesting problem.  Over the weekend our syslog forwarder went
 beserk generating over 300,000 messages to about 6 people.  This morning
 our three new Cyrus systems went belly up, (yes that is a technical term),
 actually the master daemon seemed to eventually freeze up.  The only real
 error msgs I can find are these:
 Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR:
 opening /opt/cyrus/mailboxes.db: Not enough space
 Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR:
 opening /opt/cyrus/mailboxes.db: Not enough space
 Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR:
 opening /opt/cyrus/mailboxes.db: Not enough space
 Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR:
 opening /opt/cyrus/mailboxes.db: Not enough space
 Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR:
 opening /opt/cyrus/mailboxes.db: Not enough space

 Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000
 messages a day with no trouble.  I don't believe space is really an issue,
 here is a df -k from one of the systems.

 Filesystemkbytesused   avail capacity  Mounted on
 /dev/md/dsk/d0   1984564  904568 102046047%/
 /proc  0   0   0 0%/proc
 fd 0   0   0 0%/dev/fd
 mnttab 0   0   0 0%/etc/mnttab
 /dev/md/dsk/d1962573  255248  64957129%/var
 swap 28642528  32 28642496 1%/var/run
 swap 28655440   12944 28642496 1%/tmp
 /dev/md/dsk/d4   50408148134 4982272 1%/users
 /dev/md/dsk/d3   5040814  452439 453796710%/opt
 /dev/vx/dsk/po8_dg01/logvol01
   5160542  115891 4993046 3%/logs
 /dev/vx/dsk/po8_dg01/mqueuevol01
   103218844986 10213680 1%/mqueue
 /dev/vx/dsk/po8_dg01/cyrus_data_vol01
   41287586  126222 40748489 1%/opt/cyrus
 /dev/vx/dsk/po8_dg01/sendmailvol01
   41287586  603402 40271309 2%/opt/sendmail_vol
 /dev/vx/dsk/po8_dg01/cyrus_app_vol01
   41287586  147526 40727185 1%/opt/cyrus_vol
 /dev/vx/dsk/po8_dg01/spoolvol01
   103218991  679107 101507695 1%/var/spool/mail
 swap 28642640 144 28642496 1%/opt/cyrus/proc
 /dev/vx/dsk/po8_dg01/appvol01
   20643785   54397 20382951 1%/applications


 This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8
 and, Sendmail 8.12.8.  Anyone seen this before?  Thanks.
 Jim




-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper



Problem with cyradm crashing

2003-03-28 Thread Marco Colombo
I've got a weird problem with cyradm crashing (SIGSEGV) while performing
a simple 'lm'. After some ugly dedugging, I've isolated the problem
in lib/imclient.c.

It seems that the call to sasl_decode() in imclient_input() sets
wrongly 'plainlen' (to some value 100). Here's the code:

if (imclient-saslcompleted == 1) {
/* decrypt what we have */
if ((result = sasl_decode(imclient-saslconn, buf, len,
plainbuf, plainlen)) != SASL_OK) {
(void) shutdown(imclient-fd, 0);
}

if (plainlen == 0) return;
} else {
plainbuf = buf;
plainlen = len;
}

Is it a known problem of SASL 2.1.12? If so, please ignore this
bug report.

Some other facts:

1) cryadm crashes only on our production mailboxes database, which
is being converted both via ctl_mboxlist -d / ctl_mboxlist -u and
cvt_cyrusdb. That initially made me focus on format problems
(tried skiplist, db3, flat), conversion problems
(tried db3 tools, too), as a fresh install (empty mailboxes.db)
always worked.
In the end I've discovered it depends on the size of the server
response to the LIST command, i.e. on the number of folders and
their depth.


2) the old cyradm binary, from a 2.0.16 installation, never crashes.
(that made me turn to the client side instead of the server side)
The old binaries were compiled vs. SASL v.1.5.26 (shared), which has
been recently upgraded to 1.5.28.


3) behaviour depends on the SASL mech used to authenticate:

LOGIN: crashes
CRAM-MD5: crashes
DIGEST-MD5: works well

I can't test PLAIN, since cyradm can't do TLS. SRP crashes, too, but
it may be another kind of problem (see below). Please note DIGEST-MD5
it's the only mech in which sasl_decode is expected to do something.
I've traced it, it gets like 2kB of input and returns about 3kB of
'plainbuf'. AFAIK, for the other mechs sasl_decode() should only copy
the input as is.


4) forcing the else part in the above code:

plainbuf = buf;
plainlen = len;

fixes the problem. Of course it is possible only if SASL uses
a mechs which does not provide any protection (when sasl_decode()
is just a noop, I think). This 'fix' works with CRAM-MD5 and LOGIN,
and of course breaks completely DIGEST-MD5 (and others, too, I guess).
Anyway it isolates the bug in sasl_decode(), apparently.


5) by extensive Debugging with printf (TM), I've discovered
the sasl_decode() misbehaviour (plainlen scrambling). It happens
if and only if the buffer is large enough. This happens only when
the server response is large, of course. A short answer (2 or 3 test
mailbox) never triggers it.
large enough means both 4096 (the default) and 2048. 1440 works well.
1024 works too. I'm sorry I can't be more precise, but debugging
a perl application that gets some .so binary modules loaded which in
turn call some shared library functions (SASL) is beyond what I can
do in a decent timeframe B-).


6) the following patch fixes the problem, for all mechs but SRP.
I've never used SRP before, I've tried it only to collect more details
on this problem, so it may be a completely unrelated problem. All other
mechs do work.


--- cyrus-imapd-2.1.12/lib/imclient.c.buf1024   Wed Nov  6 21:43:26 2002
+++ cyrus-imapd-2.1.12/lib/imclient.c   Thu Mar 27 20:40:47 2003
@@ -86,7 +86,7 @@
 #include iptostring.h
 
 /* I/O buffer size */
-#define IMCLIENT_BUFSIZE 4096
+#define IMCLIENT_BUFSIZE 1024
 
 /* Command completion callback record */
 struct imclient_cmdcallback {



sasl_decode() now gets called with a smaller buffer and plainlen
is always ok. Of course this is not a real fix, it just makes
cyradm work with the buggy sasl_decode().


7) the above (problems and fixes) has been tested on both a Red Hat
Linux 7.3 and 8.0. The SASL library has been compiled by me and upgraded
to 2.1.12 on both systems.


8) I haven't made any further investigation since I know very little of
SASL itself. I think that, if this isn't a known bug, I'd have to code
a little test program in C.


.TM.
-- 
  /  /   /
 /  /   /   Marco Colombo
___/  ___  /   /  Technical Manager
   /  /   /  ESI s.r.l.
 _/ _/  _/ [EMAIL PROTECTED]



Re: Problem with cyradm crashing

2003-03-28 Thread John Alton Tamplin
Marco Colombo wrote:

2) the old cyradm binary, from a 2.0.16 installation, never crashes.
(that made me turn to the client side instead of the server side)
The old binaries were compiled vs. SASL v.1.5.26 (shared), which has
been recently upgraded to 1.5.28.
 

Cyrus 2.x requires SASL 2.x -- if you are running it with SASL 1 perhaps 
that is your problem.  See install-prereq.html in the documentation.

--
John A. Tamplin   Unix System Administrator
Emory University, School of Public Health +1 404/727-9931




Re: /Noinferiors on INBOX

2003-03-28 Thread Morgan Sackett
John A. Tamplin wrote:

1.5 did not have altnamespace, it was always INBOX.Trash etc.

What exactly is the problem with having \Noinferiors set on INBOX?  In 
altnamespace, it does not have any subfolders. Ie, if I have 
user/jtampli and user/jtampli/test, that will show up as INBOX and 
test, and test is not a child of INBOX.  What client has a problem 
with this arrangement?

None so far.  It's when I have it switched around that they can't see 
it.  It seems that the default behavior changed since 2.0.16.  I would 
use that version, but I couldn't get lmtpd from that release to listen.



Re: /Noinferiors on INBOX

2003-03-28 Thread Morgan Sackett
Rob Siemborski wrote:

altnamespace=yes should give you same level folders, altnamespace=no
should give you nexting.
-Rob

 

Unfortunately, I'm seeing the opposite results.  If I have 
altnamespace=no, then I can see and sub to all of the folders and they 
are at the same level as INBOX.  Inbox has a /Haschildren flag set.

If I set altnamespace=yes, then INBOX gets the /Noinferiors flag, and I 
am not able to see any of the other folders.  ie. I can't subscribe to 
user/msackett/Sent, which should show up to my client as INBOX.Sent.




Re: Problem with cyradm crashing

2003-03-28 Thread Marco Colombo
On Fri, 28 Mar 2003, John Alton Tamplin wrote:

 Marco Colombo wrote:
 
 2) the old cyradm binary, from a 2.0.16 installation, never crashes.
 (that made me turn to the client side instead of the server side)
 The old binaries were compiled vs. SASL v.1.5.26 (shared), which has
 been recently upgraded to 1.5.28.
   
 
 Cyrus 2.x requires SASL 2.x -- if you are running it with SASL 1 perhaps 
 that is your problem.  See install-prereq.html in the documentation.


Ehm. The *old* binary, running on a completely different system, RHL62,
*never* crashes. The working cyramd is the old one, v.2.0.16, compiled
with SASL 1.5.26, now running with 1.5.28. What I do is just type
the password and then 'lm'.

I've setup 2 test systems (reading install-prereq.html, yes), RHL7.3
and RHL8.0, with SASL 2.1.12 and imapd 2.1.12.
On both the new test systems, cyradm crashes as described in my previous
message.

.TM.
-- 
  /  /   /
 /  /   /   Marco Colombo
___/  ___  /   /  Technical Manager
   /  /   /  ESI s.r.l.
 _/ _/  _/ [EMAIL PROTECTED]



Re: Problem with cyradm and krb5 */admin principals

2003-03-28 Thread Ben Poliakoff
Thanks Paul!  I'm look forward to trying this out very soon!

Ben

* Paul M Fleming [EMAIL PROTECTED] [030328 07:28]:
 I've attached the code. Put this in the lib directory as auth_regexp.c
 When you configure you must do --with-auth=regexp This code requires
 POSIX regex functions, you may have to include additional libraries
 depending on the OS. On RedHat the regex functions are part of libc.
 Someday I'll get a web page up with this code and some more
 explaination.
 
 Once compiled with this module you can use any regular expression to
 match identifiers.. 
 
 For example from my configs:
 
 admins: regexp:.+/admin
 proxyservers: regexp:murder/.+\.siumed\.edu
 lmtp_admins: regexp:murder/.+\.siumed\.edu
 


-- 
---
Ben Poliakoff   email: [EMAIL PROTECTED]
Reed College  tel:  (503)-788-6674
Unix System Administrator  PGP key: http://www.reed.edu/~benp/key.html
---
0x6AF52019 fingerprint = A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019



Re: Problem with cyradm crashing

2003-03-28 Thread Rob Siemborski
On Fri, 28 Mar 2003, John Alton Tamplin wrote:

 Cyrus 2.x requires SASL 2.x -- if you are running it with SASL 1 perhaps
 that is your problem.  See install-prereq.html in the documentation.

Cyrus 2.0 requires SASL 1.x, Cyrus 2.1 requires SASL 2.x, Cyrus 2.2
requires SASL = 2.1.7.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper



Re: /opt/cyrus/mailboxes.db: Not enough space

2003-03-28 Thread Rob Siemborski
Either use the cvt_cyrusdb program or dump and undump (with a
newly-compiled version of cyrus) your mailbox list (using ctl_mboxlist)

-Rob

On Fri, 28 Mar 2003, Jim Howell wrote:

 Hi,
  No I guess I hadn't heard that suggestion before.  Thanks..   Is
 there an easy way to go from BerkeleyDB to skiplist?
 Jim

 At 11:26 AM 3/28/2003 -0500, Rob Siemborski wrote:
 If you haven't had the suggestion before, it's really not recommended to
 use Berkeley DB for your mailbox list.  Use skiplist instead.
 
 -Rob
 
 On Fri, 28 Mar 2003, Jim Howell wrote:
 
   Hi,
 Last night we had this happen again on one of our systems.  What
  is the
   current thinking as to the cause and/or fix to this problem?  I saw one
   response last time that said backing off to DB 4.0 would help.  Again the
   versions of things are:
  
   Sendmail 8.12.8
   Cyrus 2.1.11
   Berkeley DB 4.1.24
  
   Thanks.
   Jim
  
  
  
   Hi,
 I have an interesting problem.  Over the weekend our syslog
  forwarder went
   beserk generating over 300,000 messages to about 6 people.  This morning
   our three new Cyrus systems went belly up, (yes that is a technical term),
   actually the master daemon seemed to eventually freeze up.  The only real
   error msgs I can find are these:
   Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR:
   opening /opt/cyrus/mailboxes.db: Not enough space
   Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR:
   opening /opt/cyrus/mailboxes.db: Not enough space
   Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR:
   opening /opt/cyrus/mailboxes.db: Not enough space
   Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR:
   opening /opt/cyrus/mailboxes.db: Not enough space
   Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR:
   opening /opt/cyrus/mailboxes.db: Not enough space
  
   Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000
   messages a day with no trouble.  I don't believe space is really an issue,
   here is a df -k from one of the systems.
  
   Filesystemkbytesused   avail capacity  Mounted on
   /dev/md/dsk/d0   1984564  904568 102046047%/
   /proc  0   0   0 0%/proc
   fd 0   0   0 0%/dev/fd
   mnttab 0   0   0 0%/etc/mnttab
   /dev/md/dsk/d1962573  255248  64957129%/var
   swap 28642528  32 28642496 1%/var/run
   swap 28655440   12944 28642496 1%/tmp
   /dev/md/dsk/d4   50408148134 4982272 1%/users
   /dev/md/dsk/d3   5040814  452439 453796710%/opt
   /dev/vx/dsk/po8_dg01/logvol01
 5160542  115891 4993046 3%/logs
   /dev/vx/dsk/po8_dg01/mqueuevol01
 103218844986 10213680 1%/mqueue
   /dev/vx/dsk/po8_dg01/cyrus_data_vol01
 41287586  126222 40748489 1%/opt/cyrus
   /dev/vx/dsk/po8_dg01/sendmailvol01
 41287586  603402 40271309 2%/opt/sendmail_vol
   /dev/vx/dsk/po8_dg01/cyrus_app_vol01
 41287586  147526 40727185 1%/opt/cyrus_vol
   /dev/vx/dsk/po8_dg01/spoolvol01
 103218991  679107 101507695 1%/var/spool/mail
   swap 28642640 144 28642496 1%/opt/cyrus/proc
   /dev/vx/dsk/po8_dg01/appvol01
 20643785   54397 20382951 1%/applications
  
  
   This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8
   and, Sendmail 8.12.8.  Anyone seen this before?  Thanks.
   Jim
  
  
  
 
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
 Research Systems Programmer * /usr/contributed Gatekeeper




-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper



Re: /opt/cyrus/mailboxes.db: Not enough space

2003-03-28 Thread Jim Howell
Hi,
No I guess I hadn't heard that suggestion before.  Thanks..   Is 
there an easy way to go from BerkeleyDB to skiplist?
Jim

At 11:26 AM 3/28/2003 -0500, Rob Siemborski wrote:
If you haven't had the suggestion before, it's really not recommended to
use Berkeley DB for your mailbox list.  Use skiplist instead.
-Rob

On Fri, 28 Mar 2003, Jim Howell wrote:

 Hi,
   Last night we had this happen again on one of our systems.  What 
is the
 current thinking as to the cause and/or fix to this problem?  I saw one
 response last time that said backing off to DB 4.0 would help.  Again the
 versions of things are:

 Sendmail 8.12.8
 Cyrus 2.1.11
 Berkeley DB 4.1.24

 Thanks.
 Jim



 Hi,
   I have an interesting problem.  Over the weekend our syslog 
forwarder went
 beserk generating over 300,000 messages to about 6 people.  This morning
 our three new Cyrus systems went belly up, (yes that is a technical term),
 actually the master daemon seemed to eventually freeze up.  The only real
 error msgs I can find are these:
 Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] DBERROR:
 opening /opt/cyrus/mailboxes.db: Not enough space
 Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] DBERROR:
 opening /opt/cyrus/mailboxes.db: Not enough space
 Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] DBERROR:
 opening /opt/cyrus/mailboxes.db: Not enough space
 Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] DBERROR:
 opening /opt/cyrus/mailboxes.db: Not enough space
 Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] DBERROR:
 opening /opt/cyrus/mailboxes.db: Not enough space

 Now I'm been running older versions of Cyrus (1.5.19) for years at 300,000
 messages a day with no trouble.  I don't believe space is really an issue,
 here is a df -k from one of the systems.

 Filesystemkbytesused   avail capacity  Mounted on
 /dev/md/dsk/d0   1984564  904568 102046047%/
 /proc  0   0   0 0%/proc
 fd 0   0   0 0%/dev/fd
 mnttab 0   0   0 0%/etc/mnttab
 /dev/md/dsk/d1962573  255248  64957129%/var
 swap 28642528  32 28642496 1%/var/run
 swap 28655440   12944 28642496 1%/tmp
 /dev/md/dsk/d4   50408148134 4982272 1%/users
 /dev/md/dsk/d3   5040814  452439 453796710%/opt
 /dev/vx/dsk/po8_dg01/logvol01
   5160542  115891 4993046 3%/logs
 /dev/vx/dsk/po8_dg01/mqueuevol01
   103218844986 10213680 1%/mqueue
 /dev/vx/dsk/po8_dg01/cyrus_data_vol01
   41287586  126222 40748489 1%/opt/cyrus
 /dev/vx/dsk/po8_dg01/sendmailvol01
   41287586  603402 40271309 2%/opt/sendmail_vol
 /dev/vx/dsk/po8_dg01/cyrus_app_vol01
   41287586  147526 40727185 1%/opt/cyrus_vol
 /dev/vx/dsk/po8_dg01/spoolvol01
   103218991  679107 101507695 1%/var/spool/mail
 swap 28642640 144 28642496 1%/opt/cyrus/proc
 /dev/vx/dsk/po8_dg01/appvol01
   20643785   54397 20382951 1%/applications


 This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with Solaris 8
 and, Sendmail 8.12.8.  Anyone seen this before?  Thanks.
 Jim




-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper



Re: /opt/cyrus/mailboxes.db: Not enough space

2003-03-28 Thread Jim Howell
Hi,
I was thinking the second method would work however I like the 
first one as well.  Thanks.
Jim

At 02:29 PM 3/28/2003 -0500, Rob Siemborski wrote:
Either use the cvt_cyrusdb program or dump and undump (with a
newly-compiled version of cyrus) your mailbox list (using ctl_mboxlist)
-Rob

On Fri, 28 Mar 2003, Jim Howell wrote:

 Hi,
  No I guess I hadn't heard that suggestion before.  Thanks..   Is
 there an easy way to go from BerkeleyDB to skiplist?
 Jim

 At 11:26 AM 3/28/2003 -0500, Rob Siemborski wrote:
 If you haven't had the suggestion before, it's really not recommended to
 use Berkeley DB for your mailbox list.  Use skiplist instead.
 
 -Rob
 
 On Fri, 28 Mar 2003, Jim Howell wrote:
 
   Hi,
 Last night we had this happen again on one of our systems.  What
  is the
   current thinking as to the cause and/or fix to this problem?  I saw one
   response last time that said backing off to DB 4.0 would 
help.  Again the
   versions of things are:
  
   Sendmail 8.12.8
   Cyrus 2.1.11
   Berkeley DB 4.1.24
  
   Thanks.
   Jim
  
  
  
   Hi,
 I have an interesting problem.  Over the weekend our syslog
  forwarder went
   beserk generating over 300,000 messages to about 6 people.  This 
morning
   our three new Cyrus systems went belly up, (yes that is a technical 
term),
   actually the master daemon seemed to eventually freeze up.  The 
only real
   error msgs I can find are these:
   Mar 10 00:18:16 postoffice8 lmtpd[27393]: [ID 729713 local6.error] 
DBERROR:
   opening /opt/cyrus/mailboxes.db: Not enough space
   Mar 10 08:04:46 postoffice8 pop3d[2183]: [ID 729713 local6.error] 
DBERROR:
   opening /opt/cyrus/mailboxes.db: Not enough space
   Mar 10 08:12:58 postoffice8 imapd[2489]: [ID 729713 local6.error] 
DBERROR:
   opening /opt/cyrus/mailboxes.db: Not enough space
   Mar 10 08:14:05 postoffice8 imapd[2731]: [ID 729713 local6.error] 
DBERROR:
   opening /opt/cyrus/mailboxes.db: Not enough space
   Mar 10 08:27:59 postoffice8 imapd[3951]: [ID 729713 local6.error] 
DBERROR:
   opening /opt/cyrus/mailboxes.db: Not enough space
  
   Now I'm been running older versions of Cyrus (1.5.19) for years at 
300,000
   messages a day with no trouble.  I don't believe space is really an 
issue,
   here is a df -k from one of the systems.
  
   Filesystemkbytesused   avail capacity  Mounted on
   /dev/md/dsk/d0   1984564  904568 102046047%/
   /proc  0   0   0 0%/proc
   fd 0   0   0 0%/dev/fd
   mnttab 0   0   0 0%/etc/mnttab
   /dev/md/dsk/d1962573  255248  64957129%/var
   swap 28642528  32 28642496 1%/var/run
   swap 28655440   12944 28642496 1%/tmp
   /dev/md/dsk/d4   50408148134 4982272 1%/users
   /dev/md/dsk/d3   5040814  452439 453796710%/opt
   /dev/vx/dsk/po8_dg01/logvol01
 5160542  115891 4993046 3%/logs
   /dev/vx/dsk/po8_dg01/mqueuevol01
 103218844986 10213680 1%/mqueue
   /dev/vx/dsk/po8_dg01/cyrus_data_vol01
 41287586  126222 40748489 1%/opt/cyrus
   /dev/vx/dsk/po8_dg01/sendmailvol01
 41287586  603402 
40271309 2%/opt/sendmail_vol
   /dev/vx/dsk/po8_dg01/cyrus_app_vol01
 41287586  147526 
40727185 1%/opt/cyrus_vol
   /dev/vx/dsk/po8_dg01/spoolvol01
 103218991  679107 
101507695 1%/var/spool/mail
   swap 28642640 144 
28642496 1%/opt/cyrus/proc
   /dev/vx/dsk/po8_dg01/appvol01
 20643785   54397 20382951 1%/applications
  
  
   This is all with Cyrus 2.1.11 on a V880 with 32GB of memory with 
Solaris 8
   and, Sendmail 8.12.8.  Anyone seen this before?  Thanks.
   Jim
  
  
  
 
 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
 Research Systems Programmer * /usr/contributed Gatekeeper




-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper



Re: /Noinferiors on INBOX

2003-03-28 Thread Morgan Sackett
Morgan Sackett wrote:

John A. Tamplin wrote:

1.5 did not have altnamespace, it was always INBOX.Trash etc.

What exactly is the problem with having \Noinferiors set on INBOX?  
In altnamespace, it does not have any subfolders. Ie, if I have 
user/jtampli and user/jtampli/test, that will show up as INBOX and 
test, and test is not a child of INBOX.  What client has a problem 
with this arrangement?

None so far.  It's when I have it switched around that they can't see 
it.  It seems that the default behavior changed since 2.0.16.  I would 
use that version, but I couldn't get lmtpd from that release to listen.

Under further investigation, it seems that with altnamespace=no, the 
clients think that the new namespace is INBOX./.   I'll look through 
the code to see if the hierarchy separators are getting set incorrectly 
anywhere.




Re: /Noinferiors on INBOX

2003-03-28 Thread Ken Murchison


Morgan Sackett wrote:
 
 Morgan Sackett wrote:
 
  John A. Tamplin wrote:
 
 
  1.5 did not have altnamespace, it was always INBOX.Trash etc.
 
  What exactly is the problem with having \Noinferiors set on INBOX?
  In altnamespace, it does not have any subfolders. Ie, if I have
  user/jtampli and user/jtampli/test, that will show up as INBOX and
  test, and test is not a child of INBOX.  What client has a problem
  with this arrangement?
 
  None so far.  It's when I have it switched around that they can't see
  it.  It seems that the default behavior changed since 2.0.16.  I would
  use that version, but I couldn't get lmtpd from that release to listen.
 
 Under further investigation, it seems that with altnamespace=no, the
 clients think that the new namespace is INBOX./.   I'll look through
 the code to see if the hierarchy separators are getting set incorrectly
 anywhere.

Your client is screwed.  The personal namespace will _never_ be shown as
INBOX./

I'm guessing that your client is not smart enough to switch namespaces
on the fly as you're changing altnamespace.

The behavior that has been explained to you by Rob and John is correct. 
I should know, I wrote the code.

-- 
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26  Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp