May 2007 - dovecot - dovecot.org

[Dovecot] SHA256 password patch
by Jasper Slits 16 Jun '07

16 Jun '07

Hi, I made a patch against branch-1.0 for SHA256 password hashing support for Dovecot. Courier Authlib supports this hashing scheme and in order to migrate from Courier to Dovecot, I've added SHA256 support to Dovecot. The attached patch is based on BSD licensed code from Olivier Gay (http://www.ouah.org/ogay/sha2/). Changes made by me in Olivier's sha2{.h,.c} code: - Prototype for sha256_transf is added to sha2.h - sha256_get_digest() is added to sha2{.h,.c} - Code for UNROLL_LOOPS is removed - Support for SHA224,SHA384,SHA512 was removed - Functions are renamed to match those in sha1{.h,.c} - SHA256_DIGEST_SIZE is renamed to SHA256_RESULTLEN I can add safe_memset calls if requested. Patch is attached and can also be found at http://www.malochia.nl/dovecot/sha256.patch Kind regards, Jasper diff -r -u -N --exclude=Makefile.in --exclude=.deps --exclude=Makefile src/auth/password-scheme.c auth/password-scheme.c --- src/auth/password-scheme.c 2007-02-21 13:30:38.756711250 +0100 +++ auth/password-scheme.c 2007-02-21 14:18:49.645380500 +0100 @@ -10,6 +10,7 @@ #include "mycrypt.h" #include "randgen.h" #include "sha1.h" +#include "sha2.h" #include "str.h" #include "password-scheme.h" @@ -153,6 +154,17 @@ return str_c(str); } +static const char *sha256_generate(const char *plaintext, + const char *user __attr_unused__) +{ + unsigned char digest[SHA256_RESULTLEN]; + string_t *str; + sha256_get_digest(plaintext, strlen(plaintext), digest); + str = t_str_new(MAX_BASE64_ENCODED_SIZE(sizeof(digest)+1)); + base64_encode(digest, sizeof(digest), str); + return str_c(str); +} + static const void * password_decode(const char *password, unsigned int result_len) { @@ -196,6 +208,23 @@ return memcmp(sha1_digest, data, SHA1_RESULTLEN) == 0; } +static bool sha256_verify(const char *plaintext, const char *password, + const char *user) +{ + unsigned char sha256_digest[SHA256_RESULTLEN]; + const char *data; + + sha256_get_digest(plaintext, strlen(plaintext), sha256_digest); + + data = password_decode(password, SHA256_RESULTLEN); + if (data == NULL) { + i_error("sha256_verify(%s): Invalid password encoding", user); + return 0; + } + + return memcmp(sha256_digest, data, SHA256_RESULTLEN) == 0; +} + static const char *ssha_generate(const char *plaintext, const char *user __attr_unused__) { @@ -466,6 +495,7 @@ { "MD5-CRYPT", md5_crypt_verify, md5_crypt_generate }, { "SHA", sha1_verify, sha1_generate }, { "SHA1", sha1_verify, sha1_generate }, + { "SHA256", sha256_verify, sha256_generate }, { "SMD5", smd5_verify, smd5_generate }, { "SSHA", ssha_verify, ssha_generate }, { "PLAIN", plain_verify, plain_generate }, diff -r -u -N --exclude=Makefile.in --exclude=.deps --exclude=Makefile src/lib/Makefile.am lib/Makefile.am --- src/lib/Makefile.am 2007-02-21 13:30:38.792713500 +0100 +++ lib/Makefile.am 2007-02-21 14:21:59.437241750 +0100 @@ -73,6 +73,7 @@ sendfile-util.c \ seq-range-array.c \ sha1.c \ + sha2.c \ str.c \ str-sanitize.c \ strescape.c \ @@ -146,6 +147,7 @@ sendfile-util.h \ seq-range-array.h \ sha1.h \ + sha2.h \ str.h \ str-sanitize.h \ strescape.h \ diff -r -u -N --exclude=Makefile.in --exclude=.deps --exclude=Makefile src/lib/sha2.c lib/sha2.c --- src/lib/sha2.c 1970-01-01 01:00:00.000000000 +0100 +++ lib/sha2.c 2007-02-23 14:03:46.857739818 +0100 @@ -0,0 +1,257 @@ +/* + * FIPS 180-2 SHA-224/256/384/512 implementation + * Last update: 02/02/2007 + * Issue date: 04/30/2005 + * + * Copyright (C) 2005, 2007 Olivier Gay <olivier.gay(a)a3.epfl.ch> + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of the project nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#include <string.h> + +#include "sha2.h" + +#define SHFR(x, n) (x >> n) +#define ROTR(x, n) ((x >> n) | (x << ((sizeof(x) << 3) - n))) +#define ROTL(x, n) ((x << n) | (x >> ((sizeof(x) << 3) - n))) +#define CH(x, y, z) ((x & y) ^ (~x & z)) +#define MAJ(x, y, z) ((x & y) ^ (x & z) ^ (y & z)) + +#define SHA256_F1(x) (ROTR(x, 2) ^ ROTR(x, 13) ^ ROTR(x, 22)) +#define SHA256_F2(x) (ROTR(x, 6) ^ ROTR(x, 11) ^ ROTR(x, 25)) +#define SHA256_F3(x) (ROTR(x, 7) ^ ROTR(x, 18) ^ SHFR(x, 3)) +#define SHA256_F4(x) (ROTR(x, 17) ^ ROTR(x, 19) ^ SHFR(x, 10)) + +#define UNPACK32(x, str) \ +{ \ + *((str) + 3) = (uint8) ((x) ); \ + *((str) + 2) = (uint8) ((x) >> 8); \ + *((str) + 1) = (uint8) ((x) >> 16); \ + *((str) + 0) = (uint8) ((x) >> 24); \ +} + +#define PACK32(str, x) \ +{ \ + *(x) = ((uint32) *((str) + 3) ) \ + | ((uint32) *((str) + 2) << 8) \ + | ((uint32) *((str) + 1) << 16) \ + | ((uint32) *((str) + 0) << 24); \ +} + +#define UNPACK64(x, str) \ +{ \ + *((str) + 7) = (uint8) ((x) ); \ + *((str) + 6) = (uint8) ((x) >> 8); \ + *((str) + 5) = (uint8) ((x) >> 16); \ + *((str) + 4) = (uint8) ((x) >> 24); \ + *((str) + 3) = (uint8) ((x) >> 32); \ + *((str) + 2) = (uint8) ((x) >> 40); \ + *((str) + 1) = (uint8) ((x) >> 48); \ + *((str) + 0) = (uint8) ((x) >> 56); \ +} + +#define PACK64(str, x) \ +{ \ + *(x) = ((uint64) *((str) + 7) ) \ + | ((uint64) *((str) + 6) << 8) \ + | ((uint64) *((str) + 5) << 16) \ + | ((uint64) *((str) + 4) << 24) \ + | ((uint64) *((str) + 3) << 32) \ + | ((uint64) *((str) + 2) << 40) \ + | ((uint64) *((str) + 1) << 48) \ + | ((uint64) *((str) + 0) << 56); \ +} + +/* Macros used for loops unrolling */ + +#define SHA256_SCR(i) \ +{ \ + w[i] = SHA256_F4(w[i - 2]) + w[i - 7] \ + + SHA256_F3(w[i - 15]) + w[i - 16]; \ +} + + + +uint32 sha256_h0[8] = + {0x6a09e667, 0xbb67ae85, 0x3c6ef372, 0xa54ff53a, + 0x510e527f, 0x9b05688c, 0x1f83d9ab, 0x5be0cd19}; + + +uint32 sha256_k[64] = + {0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, + 0x3956c25b, 0x59f111f1, 0x923f82a4, 0xab1c5ed5, + 0xd807aa98, 0x12835b01, 0x243185be, 0x550c7dc3, + 0x72be5d74, 0x80deb1fe, 0x9bdc06a7, 0xc19bf174, + 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc, + 0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da, + 0x983e5152, 0xa831c66d, 0xb00327c8, 0xbf597fc7, + 0xc6e00bf3, 0xd5a79147, 0x06ca6351, 0x14292967, + 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc, 0x53380d13, + 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85, + 0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, + 0xd192e819, 0xd6990624, 0xf40e3585, 0x106aa070, + 0x19a4c116, 0x1e376c08, 0x2748774c, 0x34b0bcb5, + 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f, 0x682e6ff3, + 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208, + 0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2}; + + +/* SHA-256 functions */ + +void sha256_transf(sha256_ctx *ctx, const unsigned char *message, + unsigned int block_nb) +{ + uint32 w[64]; + uint32 wv[8]; + uint32 t1, t2; + const unsigned char *sub_block; + int i,j; + + + for (i = 0; i < (int) block_nb; i++) { + sub_block = message + (i << 6); + + for (j = 0; j < 16; j++) { + PACK32(&sub_block[j << 2], &w[j]); + } + + for (j = 16; j < 64; j++) { + SHA256_SCR(j); + } + + for (j = 0; j < 8; j++) { + wv[j] = ctx->h[j]; + } + + for (j = 0; j < 64; j++) { + t1 = wv[7] + SHA256_F2(wv[4]) + CH(wv[4], wv[5], wv[6]) + + sha256_k[j] + w[j]; + t2 = SHA256_F1(wv[0]) + MAJ(wv[0], wv[1], wv[2]); + wv[7] = wv[6]; + wv[6] = wv[5]; + wv[5] = wv[4]; + wv[4] = wv[3] + t1; + wv[3] = wv[2]; + wv[2] = wv[1]; + wv[1] = wv[0]; + wv[0] = t1 + t2; + } + + for (j = 0; j < 8; j++) { + ctx->h[j] += wv[j]; + } + } +} + +void sha256(const unsigned char *message, unsigned int len, unsigned char *digest) +{ + sha256_ctx ctx; + + sha256_init(&ctx); + sha256_loop(&ctx, message, len); + sha256_result(&ctx, digest); +} + +void sha256_init(sha256_ctx *ctx) +{ + int i; + for (i = 0; i < 8; i++) { + ctx->h[i] = sha256_h0[i]; + } + + ctx->len = 0; + ctx->tot_len = 0; +} + +void sha256_loop(sha256_ctx *ctx, const unsigned char *message, + unsigned int len) +{ + unsigned int block_nb; + unsigned int new_len, rem_len, tmp_len; + const unsigned char *shifted_message; + + tmp_len = SHA256_BLOCK_SIZE - ctx->len; + rem_len = len < tmp_len ? len : tmp_len; + + memcpy(&ctx->block[ctx->len], message, rem_len); + + if (ctx->len + len < SHA256_BLOCK_SIZE) { + ctx->len += len; + return; + } + + new_len = len - rem_len; + block_nb = new_len / SHA256_BLOCK_SIZE; + + shifted_message = message + rem_len; + + sha256_transf(ctx, ctx->block, 1); + sha256_transf(ctx, shifted_message, block_nb); + + rem_len = new_len % SHA256_BLOCK_SIZE; + + memcpy(ctx->block, &shifted_message[block_nb << 6], + rem_len); + + ctx->len = rem_len; + ctx->tot_len += (block_nb + 1) << 6; +} + +void sha256_result(sha256_ctx *ctx, unsigned char *digest) +{ + unsigned int block_nb; + unsigned int pm_len; + unsigned int len_b; + int i; + + block_nb = (1 + ((SHA256_BLOCK_SIZE - 9) + < (ctx->len % SHA256_BLOCK_SIZE))); + + len_b = (ctx->tot_len + ctx->len) << 3; + pm_len = block_nb << 6; + + memset(ctx->block + ctx->len, 0, pm_len - ctx->len); + ctx->block[ctx->len] = 0x80; + UNPACK32(len_b, ctx->block + pm_len - 4); + + sha256_transf(ctx, ctx->block, block_nb); + + for (i = 0 ; i < 8; i++) { + UNPACK32(ctx->h[i], &digest[i << 2]); + } +} + +void sha256_get_digest(const void *data, size_t size, + unsigned char result[SHA256_RESULTLEN]) +{ + sha256_ctx ctx; + + sha256_init(&ctx); + sha256_loop(&ctx, data, size); + sha256_result(&ctx, result); +} + diff -r -u -N --exclude=Makefile.in --exclude=.deps --exclude=Makefile src/lib/sha2.h lib/sha2.h --- src/lib/sha2.h 1970-01-01 01:00:00.000000000 +0100 +++ lib/sha2.h 2007-02-23 14:22:32.952116316 +0100 @@ -0,0 +1,72 @@ +/* + * FIPS 180-2 SHA-224/256/384/512 implementation + * Last update: 02/02/2007 + * Issue date: 04/30/2005 + * + * Copyright (C) 2005, 2007 Olivier Gay <olivier.gay(a)a3.epfl.ch> + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. Neither the name of the project nor the names of its contributors + * may be used to endorse or promote products derived from this software + * without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ + +#ifndef SHA2_H +#define SHA2_H + +#define SHA256_RESULTLEN ( 256 / 8) + +#define SHA256_BLOCK_SIZE ( 512 / 8) + +#ifndef SHA2_TYPES +#define SHA2_TYPES +typedef unsigned char uint8; +typedef unsigned int uint32; +typedef unsigned long long uint64; +#endif + + +typedef struct { + unsigned int tot_len; + unsigned int len; + unsigned char block[2 * SHA256_BLOCK_SIZE]; + uint32 h[8]; +} sha256_ctx; + +void sha256_transf(sha256_ctx *ctx, const unsigned char *message, + unsigned int block_nb); + + +void sha256_init(sha256_ctx * ctx); +void sha256_loop(sha256_ctx *ctx, const unsigned char *message, + unsigned int len); +void sha256_result(sha256_ctx *ctx, unsigned char *digest); +void sha256(const unsigned char *message, unsigned int len, + unsigned char *digest); +void sha256_get_digest(const void *data, size_t size, + unsigned char result[SHA256_RESULTLEN]); + + + +#endif /* !SHA2_H */ +

3 2

[Dovecot] SEGV with Dovecot v1.0.0 Deliver and cmusieve v1.0.1 and vacation
by Steffen Kaiser 16 Jun '07

16 Jun '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I have a small Sieve script that tries to use vacation that segfaults. The script is the one from http://wiki.dovecot.org/LDA/Sieve. When I change the email address (I changed the local part into "skai"), hence, vacation is skipped, the mail is delivered without any problem. ==== script start require ["fileinto", "vacation"]; # Move spam to spam folder if exists "X-Spam-Flag" { fileinto "spam"; # Stop here so that we do not reply on spams stop; } vacation # Reply at most once a day to a same sender :days 1 :subject "Out of office reply" # List of allowed recipient addresses from auto reply should be sent. :addresses ["ska(a)ux-2s11-9.inf.fh-bonn-rhein-sieg.de"] "I'm out of office, please contact Joan Doe instead. Best regards John Doe"; ========== END ========== Out of sieved .dovecot.sievec Sievecode version 3 4: IF (ends at 13)exists{11}X-Spam-Flag 13:JUMP 20 19: FILEINTO {4}spam 19: STOP 20: VACATION {39}ska(a)ux-2s11-9.inf.fh-bonn-rhein-sieg.de 40 SUBJ({19}Out of office reply) 60 MESG({73}I'm out of office, please contact Joan Doe instead. Best regards John Doe) DAYS(1) MIME(0) full len is: 62 ========== END gdb output: Core was generated by `/usr/local/dovecot/libexec/dovecot/deliver'. Program terminated with signal 11, Segmentation fault. #0 0xb7eef3a3 in strlen () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt full #0 0xb7eef3a3 in strlen () from /lib/tls/i686/cmov/libc.so.6 No symbol table info available. #1 0xb7e2bcf3 in sieve_execute_bytecode (bc=0x80e3eb0, interp=0x80e3de8, script_context=0xbfb57800, message_context=0xbfb577c4) at script.c:398 hash = "\000\000\000\000¸Z0F\000\000\000\000¸Z0F" actions = (action_list_t *) 0x80e3850 notify_list = (notify_list_t *) 0x80e3830 actions_string = "Action(s) taken:\n", '\0' <repeats 4078 times> errmsg = 0x0 imapflags = {flag = 0x0, nflags = 0} #2 0xb7e1eb2c in cmu_sieve_run (storage=0x80d0a20, mail=0x80e03c8, script_path=0x80cbc48 "/home/ska/.dovecot.sieve", username=0x80cb030 "ska", mailbox=0x80bae92 "INBOX") at sieve-cmu.c:573 fd = <value optimized out> interp = (sieve_interp_t *) 0x80e3de8 bytecode = (sieve_bytecode_t *) 0x80e3eb0 sdata = {username = 0x80cb030 "ska", storage = 0x80d0a20, errors = 0x0} mdata = {mail = 0x80e03c8, mailbox = 0x80bae92 "INBOX", id = 0x80e4860 "<200704260754.l3Q7sWdu002894(a)ux-2s11-9.inf.fh-bonn-rhein-sieg.de>", return_path = 0x0, authuser = 0x80cb030 "ska", temp = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}} compiled_path = 0x80cbc68 "/home/ska/.dovecot.sievec" path = 0xb7fb0ff4 "<Í\022" ret = <value optimized out> #3 0xb7e1da72 in cmusieve_deliver_mail (storage=0x80d0a20, mail=0x80e03c8, username=0x80cb030 "ska", mailbox=0x80bae92 "INBOX") at cmusieve-plugin.c:72 script_path = 0x80cbc48 "/home/ska/.dovecot.sieve" #4 0x08057536 in main (argc=Cannot access memory at address 0x0 ) at deliver.c:679 tab = (struct var_expand_table *) 0x80cb068 config_path = 0x80bb79c "/usr/local/dovecot/etc/dovecot.conf" envelope_sender = 0x80bae98 "MAILER-DAEMON" mailbox = 0x80bae92 "INBOX" auth_socket = <value optimized out> home = <value optimized out> destination = 0x80cb030 "ska" user = 0x80cb030 "ska" mail_env = <value optimized out> flags = 1025 lock_method = MAIL_STORAGE_LOCK_FCNTL storage = (struct mail_storage *) 0x80d0a20 mbox_storage = (struct mail_storage *) 0x80d2d48 box = (struct mailbox *) 0x80dcc88 input = (struct istream *) 0x80d4044 t = (struct mailbox_transaction_context *) 0x80de2a0 mail = (struct mail *) 0x80e03c8 process_euid = 30000 i = 63 ret = <value optimized out> (gdb) - -- Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBRjBdji9SORjhbDpvAQICoggAnzLxTlL8mDonntaDvwr/4JN6eWPIAm7o XP6hSw9JlbTsPY55keQMZpN/UNB/FXojcqI6lD4f/2dJqCEHmeB40NQZEMUN+f60 6+BHkE6vb2sMnXa09eQWg2d5zVKp6bHdSsbtzmWIsYX0stUFMncFTJVQgatHstDm DaSGMf6V2SwiPst/0tUbeTMqYhud9LU2YLhU3+T9AuTmcSGztohnJPGnqC1GLP+N m+KLbLF6B7ZMQ2RX+M+arzz8EQRHZ2622aqiLKoT+rVZ8LkLPzp4Whd9HK1MqMld KSjJuZBKgKuJr61SGqPboPOip635DgJH7g2BKgGnOHWvJf6E7U+Q9A== =1M3a -----END PGP SIGNATURE-----

3 3

[Dovecot] Warning about NFS but using local fs for INDEX
by Herbert Gasiorowski 12 Jun '07

12 Jun '07

I am playing around with dovecot and want to use local filesystem for indexing. But whenever I open a new imap connection the following warning is shown: Apr 30 10:14:42 beira dovecot: Mailbox indexes in /app/home/gasi are in NFS mount. You must set mmap_disable=yes to avoid index corruptions. If you're sure this check was wrong, set nfs_check=no. /app/home is a NFS mounted filesystem, but I want dovecot to use /export/dovecot/gasi for indexing (See namespaces below). I shurely can follow the hints(nfs_check=no), but I am not shure if I did something wrong or maybe someday will change the configuration and forget to enable the nfs check. dovecot version: dovecot-1.0-1.2.rc15.el5 on CentOS 5.0 (with all updates). [root@beira etc]# dovecot -n # /etc/dovecot.conf syslog_facility: local6 login_dir: /var/run/dovecot/login login_executable(default): /usr/libexec/dovecot/imap-login login_executable(imap): /usr/libexec/dovecot/imap-login login_executable(pop3): /usr/libexec/dovecot/pop3-login mail_executable(default): /usr/libexec/dovecot/imap mail_executable(imap): /usr/libexec/dovecot/imap mail_executable(pop3): /usr/libexec/dovecot/pop3 mail_plugin_dir(default): /usr/lib/dovecot/imap mail_plugin_dir(imap): /usr/lib/dovecot/imap mail_plugin_dir(pop3): /usr/lib/dovecot/pop3 namespace: type: private separator: / location: mbox:~/Mail:INBOX=/var/spool/mail/%u:INDEX=/export/dovecot/%u inbox: yes namespace: type: private separator: / prefix: #home-tmp/ location: mbox:~:INDEX=/export/dovecot/%u auth default: passdb: driver: pam args: imap userdb: driver: passwd

2 2

[Dovecot] error in logfile
by Luigi Rosa 12 Jun '07

12 Jun '07

With Dovecot 1.0.0: May 11 12:16:35 mail dovecot: IMAP(xxx): stat(/var/spool/mail2/xxx/.Trash.Squid-it/new) failed: No such file or directory With Thunderbird 2.0 IMAP client: * user deleted the mailbox * TB moved the mailbox to Trash * user asked TB to empty Trash * the above message appeared No warning/error was reported bt TB to user. I don't think it's an error and should not be logged. Ciao, luigi -- / +--[Luigi Rosa]-- \ You can tune a radio, but you can't tuna fish.

2 1

[Dovecot] Getting rid of the common newbie problems
by Timo Sirainen 12 Jun '07

12 Jun '07

I think the most common Dovecot newbie problems are: - Not looking at the (correct) logs for errors - Authentication problems - Mail location problems - Mail permission problems Below are some of my ideas how I could stop people from asking these questions with future Dovecot (v1.1+) releases. Suggestions welcome. Distribution people especially should say if they're against some change. * Logging The log file problem is the most annoying one, because a lot of the other problems can be solved once the admin figures out that Dovecot is actually giving useful error messages. Often the admin is only looking at the log file where "info" messages go (eg mail.log) because Dovecot logs its startup message and login messages there, but not where the errors go (eg mail.err). This has happened even with people who in general are experienced sysadmins. Logging to eg. /var/log/dovecot.log by default would be helpful here, but it's probably better to log via syslog by default. Cyrus logs to "local6" by default. Perhaps for Dovecot v1.1 I should make that the default too? Looks like in my Debian system the info messages then go to both /var/log/messages and /var/log/syslog. Error messages only go to /var/log/syslog. So there still isn't by default a single log file where the errors are logged, but it might help a bit. * Authentication Authentication problems can usually be solved by telling the user to set auth_debug_passwords=yes and looking at the logs. I'm not sure if there's anything that can be helped in here. Except the logging message could be updated a bit: "Aborted login: user=<asdga>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, 1 failed authentications" So the last "n failed authentications" could be added, where n could also be 0. Another possibility would be to make Dovecot remember if there have been any successful logins (/var/lib/dovecot/success file) and if not, give a bit more helpful error messages: - Client gets: "NO Authentication failed. Refer to server log for more information." instead of the normal "NO Authentication failed." - Log contains: "Aborted login: user=<asdga>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, secured, 1 failed authentications (set auth_debug_passwords=yes to debug the problem)" I'm not sure if this is a good idea. * Mail location It seems to be difficult for some people to set mail_location. I don't know if anything can be done before Dovecot v2.0 where I'll split it to multiple settings, such as: driver = maildir root_dir = ~/Maildir index_dir = /var/indexes/%u Another problem that seems to be difficult to understand is why the mail directory contains "HOME_DIRECTORY_USED_BUT_NOT_GIVEN_BY_USERDB". The whole userdb concept appears to be weird. This could anyway be fixed by giving an error message earlier and failing the login with internal error. Probably the best place to give the error message would be already in the userdb lookup in dovecot-auth, but that would require that doveoct-auth knows if the home directory is really needed, and to give a useful error message it would also need to tell where it's tried to be used (mail_location, or some namespace's location, or ..). Probably too much trouble to be worth it. So the next best thing is to give the error when it's used: "Home directory is used in mail_location, but userdb didn't return a home directory" It would be nice if it didn't say userdb, but rather the userdb's name. I guess that would be possible if dovecot-auth told master (or deliver) which userdb was used, but that would normally be just extra overhead. * Mail permissions If mail location is difficult for some, then the concept of UIDs are how they're used in Dovecot is pretty much impossible for some to understand. One of the problems is that there exists "dovecot" user. So people think that their mails should be owned by the dovecot user. Although I've mentioned in everywhere I can think of that this should not be done, it won't help because either people won't read the pages or even if they do, they somehow still fail to ignore it even though it's written in bold. So unless people (and most importantly, distributions) are against it, I think the "dovecot" user should be renamed. "dovelogin" perhaps. In future I might split dovecot-auth even more, and then I would like to create a "doveauth" user as well. Another possibility would be to drop the dovecot user completely and instead use "nobody". That would mean that other nobody processes could kill Dovecot's login processes, but that's pretty much it. Once people understand that "dovecot" isn't the right user, they hit the next problem: "How do I tell Dovecot to run as vmail user?" I can paste links to wiki pages or tell them to "make userdb return uid=vmail", but that just doesn't seem to get through. There needs to be an easier way, and I think I figured out what it is: Add new "mail_uid" and "mail_gid" settings to dovecot.conf. Deprecate user_global_uid/gid in dovecot-ldap.conf and make all the userdbs mention that the uid/gid returned by userdb can be used to override the global mail_uid/gid. Perhaps also add "mail_home" template. This change makes it unnecessary to have a userdb configured at all. - "How do I tell Dovecot to run as vmail user?" - "Set mail_uid = vmail" in dovecot.conf - "Thanks"

10 36

[Dovecot] Dovecot LDA and address extensions
by Tom Metro 12 Jun '07

12 Jun '07

I'm converting over a virtual user installation that used Postfix and maildrop with a MySQL back-end for mailbox lookups to use Dovecot LDA. The maildrop setup used a database table like: +-------------------------+--------+-------------+--------------------+ | address | owner | domain | mailbox | +-------------------------+--------+-------------+--------------------+ | postmaster(a)example.com | tmetro | example.com | .admin.postmaster/ | | root(a)example.com | tmetro | example.com | .admin.root.lex/ | | tmetro(a)example.com | tmetro | example.com | .INBOX/ | | tmetro+spam(a)example.com | tmetro | example.com | .spam.tmetro/ | [...] where maildrop was handed ${recipient} from postfix, and it queries the above table matching ${recipient} to the address column, getting back the expression CONCAT_WS('/','/var/mail',domain,owner) as the home directory, and CONCAT_WS('/','/var/mail',domain,owner,mailbox) as the mailbox. The UID/GID are fixed, as this is a virtual user setup. So looking up the mailbox for the user postmaster(a)example.com returns: /var/mail/example.com/tmetro/.admin.postmaster/ Currently I'm using a static user database with Dovecot. This SQL appears to replicate the maildrop setup: user_query = SELECT CONCAT_WS('/','/var/mail',domain,owner) as home, CONCAT_WS('/','maildir:/var/mail',domain,owner,mailbox) as mail, 5000 as uid, 5000 as gid FROM vmbx2 WHERE userid = '%u' And this works for mail deliveries. The problem with this is that not only is a database lookup overkill for the IMAP server, as the root mail location for IMAP users follows a simple pattern adequately represented by the static userdb, it also breaks IMAP, because the returned 'mail' overrides mail_location, (currently set to maildir:/var/mail/%d/%n/), so for user tmetro(a)example.com it returns: maildir:/var/mail/example.com/tmetro/.INBOX/ instead of: maildir:/var/mail/example.com/tmetro/ (which is the same as the home directory). Can the "userdb sql" directive be added to the "protocol lda" section? Or perhaps instead create a new "auth lda" section, and move the "userdb sql" and "socket listen" directives to that section? The second issue is how to best deal with address extensions, something that wasn't fully implemented in the maildrop setup. Ideally I'd like a setup where a lookup is first performed for user+ext@domain, and if it fails to return a mailbox, then lookup user@domain. Assuming Dovecot can handle a multi-row query result (grabbing the first record and ignoring the rest), this can probably be hacked using an appropriate WHERE expression. But the difficulty is getting the address components. Postfix will provide them, but Dovecot's deliver doesn't seem to have a way of receiving them and passing them on to the user query. The example LDA setup shown here: http://wiki.dovecot.org/LDA/Postfix suggests passing the extension as an argument to the mailbox (-m) switch. But this assumes that one wants a one-to-one direct mapping between extensions and mailbox names. I suppose I could switch from: -d ${user}@${nexthop} to: -d ${recipient} and add even more complexity to the SQL to parse out the extension. But I'd rather avoid embedding the extension separator character in the SQL, and would rather eliminate it from the database as well. Maybe Sieve is the answer. I presume the argument to -m could be inspected in a Sieve script, which could then map to the desired target mailbox. The non-IMAP users (like postmaster(a)example.com) could be reimplemented as aliases that redirect to a user+ext(a)example.com address for the user responsible for that domain. But using Sieve scripts for extension to mailbox mappings seems far less elegant than using a database. Maybe I need to wedge a wrapper program between Postfix and deliver that will accept the address components from postfix, perform the lookup, and convert the results into a -d argument pointing to the "owner" (see table above) and a -m argument pointing to the mailbox. On a side note... When I used this command in postfix's master.cf: /usr/lib/dovecot/deliver -d ${user}@${nexthop} -n -m ${extension} as recommended in the wiki, the following error gets logged: ... status=bounced (command line usage error. Command output: Fatal: Unknown argument: -d Usage: deliver [-c <config file>] [-d <destination user>] [-m <mailbox>] [-f <envelope sender>] ) which doesn't make a lot of sense. I suspect what it is trying to say is that it didn't like something about the argument to the -d switch. Maybe that should be ${domain} instead of ${nexthop}. (What's up with all the whitespace between "[-m <mailbox>]" and "[-f <envelope sender>]"? Also, might be a good idea to have deliver always write errors - even startup errors - to the specified logging facility, given that not all programs that launch it will report what it writes to STDERR. I notice most postfix commands - even the ones people interact with - log errors.) I ended up switching to -d ${recipient} to emulate the old maildrop setup for now, and that worked fine. The sample dovecot.conf has: ## dovecot-lda specific settings ## # socket listen { # master { # path = /var/run/dovecot/auth-master I uncommented the first two lines, but left the 'path' directive commented, under the assumption that the comment was showing the default. But without it uncommented, the socket doesn't get created. This is an inconsistency compared to how defaults are shown elsewhere in dovecot.conf. -Tom

2 1

[Dovecot] Multiple IP(or Host) listen in dovecot.conf.
by Yoshihiro Kawabe 11 Jun '07

11 Jun '07

Hi. Does someone make update for `Multiple IP(or Host) listen in dovecot.conf'? I made trivial patch so. But this patch doesn't solve `Support listening in multiple sockets' in TODO. It appends only the capability as multiple listen in dovecot.conf. So, `login_processes_count' becomes ambiguous. In CASE1, login_processes_count = 2, forked imap-login processes are 8. -- samples dovecot.conf applied this patch are following. CASE 1: listen = 127.0.0.1, 192.168.0.10, imap-server1, imap-server2.example.com or CASE 2: protocol imap { listen = 127.0.0.1:143, imap-server1:10143 ssl_listen = imap-server2:10943, 127.0.0.1 .. } protocol pop3 { listen = 127.0.0.1, pop-server1:10100 .. } -- Update brief. src/master/ master-setting.h: listen_fd and related members changed to array_t. also name add (s). master-setting.c: few member initialization delete. main.c: handle multiple IP and port, fds as array_t. resolve_ip argment change. login-process.h: add listen_fd and ssl_listen_fd member to login_group structre. login-process.c: add login_groups_create function for mapping login process to each listen fd. change dup2 source fd in create_login_process. src/lib network.c: change getnameinfo error value. -- Kawabe,Yoshihiro <sowhat(a)amnis.co.jp> As the stars blink in the night sky, our married hearts are never splitted. Even if we will unclasp each other hands, until we retain that. by H.S.

2 3

[Dovecot] Replication plans
by Timo Sirainen 05 Jun '07

05 Jun '07

Several companies have been interested in getting replication support for Dovecot. It looks like I could begin implementing it in a few months after some other changes. So here's how I'm planning on doing it: What needs to be replicated: - Saving new mails (IMAP, deliver) - Copying existing mails - Expunges - Flag and keyword changes - Mailbox creations, deletions and renames - Subscription list - IMAP extension changes, such as ACLs I'll first talk about only master/slave configuration. Later then master/multi-slave and multi-master. Comments? Basic design ------------ Since the whole point of master-slave replication would be to get a reliable service, I'll want to make the replication as reliable as possible. It would be easier to implement much simpler master-slave replication, but in error conditions that would almost guarantee that some messages get lost. I want to avoid that. Both slave and master would be running a dovecot-replication process. They would talk to each others via TCP connection. Master would be feeding changes (transactions) to slave, and slave would keep replying how far it's committed the changes. So there would be an increasing sequence number sent with each transaction. Master keeps all the changes in memory until slave has replied that it has committed the changes. If the memory buffer gets too large (1MB?) because the slave is handling the input too slowly or because it's completely dead, the master starts writing the buffer to a file. Once the slave is again responding the changes are read from the file and finally the file gets deleted. If the file gets too large (10MB?) it's deleted and slave will require a resync. Master always keeps track of "user/mailbox -> last transaction sequence" in memory. When the slave comes back up and tells the master its last committed sequence, this allows the master to resync only those mailboxes that had changed. If this mapping doesn't exist (master was restarted), all the users' mailboxes need to be resynced. The resyncing will also have to deal with new mailboxes, ACL changes and such. I'm not completely sure yet how the resyncing will work. Probably the only important thing here is that it would be good if it would resolve any message UID conflicts (even though they shouldn't happen, see below) by comparing either the messages' MD5 contents, or with maildir it would be enough to just compare the maildir filename. It's possible that the slave doesn't die completely but only some transactions fail. This shouldn't normally happen, so the easiest way to handle it would be to try a full resync, and if that still fails stop the whole slave. Another way would be to just mark that one user or mailbox as dirty and try to resync it once in a while. imap, pop3 and deliver would connect to dovecot-replication either using UNIX sockets or POSIX message queue. Queue could be faster, but sockets would allow better security checks. Or I suppose it would be possible to send some kind of a small authentication token in each message with queues. The communication protocol would be binary and the existing dovecot.index.log format would be used as much as possible (making it simple for slave to append changes to mailboxes' dovecot.index.log). dovecot-replication process would need read/write access to all users' mailboxes. So either it would run as root or it would need to have at least group-permission rights to all mailboxes. A bit more complex solution would be to use multiple processes each running with their own UIDs, but I think I won't implement this yet. The replication would require support for shared mailboxes. That way the mailboxes could be accessed using the configured shared namespaces, for example "shared/<username>/INBOX". (LMTP server could be implemented in a similar way BTW) Configuration ------------- I'm not yet sure how this should work. The simplest possibility would be just to configure a single slave and everything would be replicated there. But it should be possible to split users into multiple slaves (still one slave/user). The most configurable way to do this would be to have userdb return the slave host. Hmm. Actually that could work pretty well if the userdb returned slave's name and each slave would have a separate socket/queue where dovecot-replication listens in. I'm not sure if they could all still be handled by a single dovecot-replication process or if there should be a separate one for each of them. The configuration would then be something like: # slave for usernames beginning with letters A..K replication users_a_k { host = slave1.example.com # other options? } # L..Z and others replication users_l_z_rest { host = slave2.example.com } Saving ------ This is the most important thing to get right, and also the most complex one. Besides replicating mails that are being saved via Dovecot, I think also externally saved mails should be replicated when they're first seen. This is somewhat related to doing an initial sync to a slave. The biggest problem with saving is how to robustly handle master crashes. If you're just pushing changes from master to slave and the master dies, it's entirely possible that some of the new messages that were already saved in master didn't get through to slave. So when you switch to using slave, those messages are gone. The biggest problem with this is that when saving new mails, they'll be assigned UIDs that were already used by the original master. If a locally caching client had already seen the UID from the original master, it'll think the message is the original one instead of the new one. So the newly added message pretty much gets lost, and if the user could expunge the message (thinking it's the original one) without ever even seeing it. This UID conflict could be avoided by making the master tell slave whenever it's saving new mails. The latency between master-slave communication could be avoided with a bit of a trick: - When beginning to save/copy a mail, tell slave to increase UID counter by one. Slave replies with the new highest-seen-UID counter. - UID allocation is done after all the mails are saved/copied within a transaction. At this stage wait until slave has replied that it has reserved UIDs at least as high as we're currently allocating (other processes could have caused it to get even higher). - If save/copy is aborted, tell the slave to decrease the UID counter by the number of aborted messages. - UID counter desync shouldn't happen, but if it does handle that also somehow. Then the UID allocation latency depends on how long it takes to write the message, and where the message comes from. With IMAP APPEND there's probably no wait required, unless the APPEND command and the whole message arrives in one IP packet. With deliver and copying it might have to wait a while. So the UID allocation should work with minimal possible latency. It could use a separate TCP connection to slave and maybe a separate high priority process in the slave that would handle only UID allocations. The above will make sure that conflicting UIDs aren't used, but it doesn't make sure that messages themselves aren't lost. If the master's hard disk failed completely and it can't be resynced anymore, the messages saved there are lost. This could be avoided by making the saving wait until the message is saved to slave: - save mail to disk, and at the same time also send it to slave - allocate UID(s) and tell to slave what they were, wait for "mail saved" reply from slave before committing the messages to mailbox permanently This would however add more latency than the simpler UID allocation counter. I don't know if it should be optional which way is used. Perhaps I'll implement the full save-sync first and if it seems too slow then I'll implement optionally the UID allocation counter. Save messages from imap/deliver would contain at least: 1. user name (unless using UNIX sockets, then it's already known) 2. mailbox name 3. UIDVALIDITY 4a) UID 4b) global UID, filename, offset and size of the message 4a) would be used with the UID allocation counter behavior. The message would be sent after the message was saved and UIDs were allocated. 4b) would be used with the wait-slave-to-save behavior. The message would be sent immediately whenever new data was received for the message, so possibly multiple times for each message. The last block would then contain size=0. After saving all the mails in a transaction, there would be a separate "allocate UIDs x..y for global UIDs a, b, c, d, etc." message which the slave then replies and master forwards the reply to imap/deliver. If the slave is down, or if a timeout (a few seconds?) occurs while waiting for the reply from slave, imap/deliver could just go on saving the message. If this is done it's possible that if the master also dies soon, there will be UID conflicts. But since this should be a rare error condition, it's unlikely that the master will die soon after a misbehaving slave. Copying ------- Copying has similar UID conflict problems than saving. The main difference is that there's no need to transfer message contents, which makes it faster to handle copies reliably. Copying could be handled with the UID allocation counter way described above. Since the message already exists in the server, there's no way that the message gets lost. So it would be possible to allow master and slave to go into desync, because the user would still find the message from the original mailbox. Move operation is done with "copy + mark \deleted + expunge" combination. This could be problematic if the master had managed to do all that before slave saw the COPY at all. Since the message isn't yet copied to the new mailbox in slave, clients wouldn't see it there, but locally caching clients might not see the message in the original mailbox either because they had already received EXPUNGE notification for it. So this should be avoided in some way. Perhaps it would be better to just treat copies the same way as saves: Require a notification from slave before replying to client with OK message. Alternatively the wait could be done at EXPUNGE command, as described below. Expunges -------- Losing expunge transactions wouldn't be too bad, because the worst that can happen is that the user needs to expunge the message again. Except that having an expunged message suddenly appear again in the middle of the mailbox violates IMAP protocol. I don't know if/how that will break clients. Solution here would again be that before EXPUNGE notifications are sent to client we'll wait for reply from slave that it had also processed the expunge. Flag and keyword changes ------------------------ Most likely doesn't matter if some of them are lost. If someone really cares about them, it would be possible to again do the slave-waiting for either all the changes or just when some specific flags/keywords change. Other changes ------------- Mailbox creations, deletions, renames and subscription changes could all be handled in a similiar way to flag/keyword changes. Handling changes implemented by IMAP extensions such as ACL is another thing. It's probably not worth the trouble to implement a special replication handler for each plugin. These changes most likely will happen somewhat rarely though, so they could be implemented by sending the whole IMAP command to slave and have it execute the command using a regular imap process. The commands could be marked with some "replication" flag so Dovecot knows that they need to be sent to slave. Although instead of executing a new imap process for each user (probably each command), it could be possible to use one imap process and just change the mailbox name in the command. So instead of eg. "setacl mailbox (whatever)" the IMAP process would execute "setacl shared/username/mailbox (whatever)". That would require telling Dovecot what parameter contains the mailbox name. Should be pretty easy to implement, unless some IMAP extensions want multiple mailbox names or the position isn't static. I can't think of any such extensions right now though. Master/multi-slave ------------------ Once the master/slave is working, support for multiple slaves could be added. The main thing to be done here is to have the slaves select which one of them is the new master, and then they'll have to sync the mailboxes with each others, because each of them might have seen some messages that others hadn't. This is assuming that save/etc. operations that are waiting for a reply from slave would wait for only one reply from the first slave that happens to respond. The number of slave replies to wait for could be also configurable, in case you're worried of a simultaneous master+slave crash. Multi-master ------------ After master/multi-slave is working, we're nearly ready for a full multi-master operation. The master farm will need global locking. Perhaps there is a usable existing implementation which could be used. In any case there needs to be a way to keeps track of what master owns what locks. The easiest way to implement multi-master is to assume that a single user isn't normally accessed from different servers at the same time. This wouldn't be a requirement, but it would make the performance better. For most users you could handle this by making sure that load balancer transfers all connections from the same IP to the same server. Or you could use a Dovecot proxy that transfers the connections. So, once the user is accessed only from one server, the operation becomes pretty much like master/multi-slave. You'll just need to be able to dynamically change the current master server for the user. This can be done by grabbing a global per-user lock before modifying the mailbox. The lock wouldn't have to be released immediately though. If no other server needs the lock, there's no point in locking/unlocking constantly. Instead the lock server could request the current lock owner to release the lock whenever another server wants it.

8 20

[Dovecot] IMAP traffic logging
by Chris Laif 05 Jun '07

05 Jun '07

Hi. I wonder if it is possible to log the number of bytes send in response to IMAP commands. Unfortunately there seems to be no config option similar to "pop3_logout_format". Courier writes a log file like this (header/body bytes): imaplogin: DISCONNECTED, ip=[::ffff:10.123.0.234], headers=0, body=0 Chris

3 4

[Dovecot] AIX mail quota plugin problems
by Stewart Dean 05 Jun '07

05 Jun '07

From reading the wiki for a filesystem quota, I took my shot at 1) building my binaries using the mods in AIXPluginsSupport 2) changing dovecot.conf and 3) putting the plugins in the library But I'm getting this error message when I invoke dovecot: Plugin imap_quota not found from directory /usr/local/lib/dovecot Error: imap dump-capability process returned 89 It would seem that a) I have the syntax or the parameters wrong b) I didn't get the changes to the AIX build environment right I've attached the dovecot -n output. Here are the details of what I did. 1) dovecot.conf =========== within the imap config section =========== # Support for dynamically loadable plugins. mail_plugins is a space separated # list of plugins to load. #mail_plugins = #mail_plugin_dir = /usr/lib/dovecot/imap # SD 5/24/07 tryout FS quota plugin mail_plugins = quota imap_quota mail_plugin_dir = /usr/local/lib/dovecot/imap plugin { # Here you can give some extra environment variables to mail processes. # This is mostly meant for passing parameters to plugins. %variable # expansion is done for all values. # Quota plugin. Multiple backends are supported: # dirsize: Find and sum all the files found from mail directory. # Extremely SLOW with Maildir. It'll eat your CPU and disk I/O. # dict: Keep quota stored in dictionary (eg. SQL) # maildir: Maildir++ quota # fs: Read-only support for filesystem quota #quota = maildir # SD 5/24/07 Try FS quota support quota = fs I've tried it as both mail_plugin_dir = /usr/local/lib/dovecot/imap and mail_plugin_dir = /usr/local/lib/dovecot 2) Both ways I see this error message: > 4229 root@mercury:/usr/local/etc ## dovecot > ILoading modules from directory: /usr/local/lib/dovecot > IModule loaded: /usr/local/lib/dovecot/lib10_quota_plugin.so > FPlugin imap_quota not found from directory /usr/local/lib/dovecot > Error: imap dump-capability process returned 89 > > 4272 root@mercury:/usr/local/lib/dovecot/imap ## dovecot > ILoading modules from directory: /usr/local/lib/dovecot/imap > IModule loaded: /usr/local/lib/dovecot/imap/lib10_quota_plugin.so > FPlugin imap_quota not found from directory /usr/local/lib/dovecot/imap > Error: imap dump-capability process returned 89 > 3) These directories have the following contents: 4292 root@mercury:/usr/local/lib/dovecot ## ls -al total 1168 drwxr-xr-x 3 root system 512 May 24 12:36 ./ drwxr-xr-x 7 root system 512 May 21 14:31 ../ -rw-r--r-- 1 root sys 292522 May 22 15:12 052207-1455-64bit-ssl.lib10_quota_plugin.a -rwxr-xr-x 1 root sys 904 May 22 15:12 052207-1455-64bit-ssl.lib10_quota_plugin.la* -rwxr-xr-x 1 root sys 270499 May 22 15:12 052207-1455-64bit-ssl.lib10_quota_plugin.so* drwxr-xr-x 2 root system 512 May 24 12:41 imap/ lrwxrwxrwx 1 root system 65 May 24 12:36 lib10_quota_plugin.a@ -> /usr/local/lib/dovecot/052207-1 455-64bit-ssl.lib10_quota_plugin.a lrwxrwxrwx 1 root system 66 May 24 12:36 lib10_quota_plugin.la@ -> /usr/local/lib/dovecot/052207- 1455-64bit-ssl.lib10_quota_plugin.la* lrwxrwxrwx 1 root system 66 May 24 12:36 lib10_quota_plugin.so@ -> /usr/local/lib/dovecot/052207- 1455-64bit-ssl.lib10_quota_plugin.so* root@mercury:/usr/local/lib/dovecot/imap ## ls -al total 152 drwxr-xr-x 2 root system 512 May 24 12:41 ./ drwxr-xr-x 3 root system 512 May 24 12:36 ../ -rw-r--r-- 1 root system 19250 May 22 15:12 052207-1455-64bit-ssl.lib11_imap_quota_plugin.a -rwxr-xr-x 1 root system 944 May 22 15:12 052207-1455-64bit-ssl.lib11_imap_quota_plugin.la* -rwxr-xr-x 1 root system 28645 May 22 15:12 052207-1455-64bit-ssl.lib11_imap_quota_plugin.so* lrwxrwxrwx 1 root system 66 May 24 12:36 lib10_quota_plugin.so@ -> /usr/local/lib/dovecot/052207- 1455-64bit-ssl.lib10_quota_plugin.so* lrwxrwxrwx 1 root system 75 May 24 12:36 lib11_imap_quota_plugin.a@ -> /usr/local/lib/dovecot/ima p/052207-1455-64bit-ssl.lib11_imap_quota_plugin.a lrwxrwxrwx 1 root system 76 May 24 12:36 lib11_imap_quota_plugin.la@ -> /usr/local/lib/dovecot/im ap/052207-1455-64bit-ssl.lib11_imap_quota_plugin.la* lrwxrwxrwx 1 root system 76 May 24 12:36 lib11_imap_quota_plugins.so@ -> /usr/local/lib/dovecot/i Any suggestions? -- ==== Stewart Dean, Unix System Admin, Henderson Computer Resources Center of Bard College, Annandale-on-Hudson, New York 12504 sdean(a)bard.edu voice: 845-758-7475, fax: 845-758-7035

2 2