[EMAIL PROTECTED] wrote:
does anybody habe an idea, how to implement password changing on an cyrus
imap server? I don't want to grant my users access to a shell to call the
program saslpasswd themselves
I am using sasl with the pam_ldap patch. Using my own mailbox objectclass
enables
in .pinerc that sits in your home dir look for folder-collection.
this is my setup (my imap server is named imapserver):
# List of directories where saved-message folders may be. First one is
# the default for Saves. Example: Main {host1}mail/[], Desktop mail\[]
# Syntax: optnl-label
Or configure within Pine.
1. Choose the Setup option from the main Pine menu (S)
2. Choose C for config
3. Put something like this for inbox-path :
{your.imap.server/user=yourusername}INBOX
4. Choose E to exit config and save your changes
ronen amity wrote:
in .pinerc that sits in
Hello All,
I cannot seem to get this error to go away, even though imap is working just fine, for
some reason I cannot make this symbol resolve.
I found the symbol:
# pwd
/usr/local/openssl/lib
# /usr/ccs/bin/nm /usr/local/openssl/lib/libcrypto.a | grep des_ecb_encrypt
[19]| 192|
Fred Ball wrote:
Hi, crew. I'm going for my first installation of Cyrus imapd, running
sendmail and freeBSD 4.3.
I'm using the O'Reilly IMAP book as a guide, and everything *seemed*okay
until I hit the instructions for building the sendmail config file. It
instructs me to add the
Yes, sieve actions that are compatible with each other can be used
together. (You can't reject and keep a message, for instance.)
You can definitely keep and redirect a message and I do it all the time.
Larry
Date: Mon, 16 Jul 2001 15:29:52 -0500 (CDT)
From: [EMAIL PROTECTED]
I've
hi,
i've made a mistake here... i forgot to mention that to make this work
the way you want, you should have the accounts that you want to delegate
management in separate cyrus partitions and make the cyrus.conf access
only those partitions. besides this, the new cyrus will have access to
Nuno Silva [EMAIL PROTECTED] wrote:
any other ideas?
Hmm, perhaps do a recursive SETACL on the set of existing mailboxes to be
administered to give admin create delete rights to the (non-cyrus) admin
user.. ? Though this would need to be set for any new mailboxes/sub-folders
created
Alain,
I caught that bug myself later, and forgot to send the fix. My apologies.
I've tested the changes I made, and they seem to work properly. I've put
the changed code into production on our new imap server with the alternate
namespaces code, and I've not yet had any complaints or problems
