February 2007 - dovecot

[Dovecot] [PATCH, RFC] add APOP authentication mechanism
by Andrey Panin 14 Aug '17

14 Aug '17

Hello all, this patch add APOP authentication mechanism to dovecot 1.0-test23. Please take a look. Best regards. -- Andrey Panin | Linux and UNIX system administrator pazke(a)donpac.ru | PGP key: wwwkeys.pgp.net

3 2

[Dovecot] compressed mbox patch
by Axel Thimm 16 Jun '09

16 Jun '09

Some ages ago there existed a compressed mbox patch, but now all I can find are posting about it. Does such a beast exist and would it remotely apply to today's dovecot? If not, is there any hope that something like that emerges? Thanks! -- Axel.Thimm at ATrpms.net

3 5

[Dovecot] BUG: messages created with permissions not respecting umask
by Thomas Vander Stichele 20 Jul '08

20 Jul '08

Using dovecot 1.0rc15, together with postfix and dovecot-lda. umask is set to 0007. This should ensure directories and files get created with read/write permissions for both user and group. However, dovecot-lda writes files with 600 permissions, instead of 660. So dovecot does not seem to respect the umask configuration property for local mail delivery. In my particular case, I have vmail:vmail own the mail directories, and a backup user part of the vmail group. However the backup user cannot read the mails and thus back them up properly. Suggestions: - respect the umask for file delivery as well - alternatively, take the parent directory's permissions, strip executable bits, and apply to file Thanks Thomas

3 3

[Dovecot] Postfix & Dovecot LDA
by Jochen Schulz 18 May '08

18 May '08

Hi, before I start to write a lengthy email about something that isn't really possible anyway: can I make Postfix use Dovecot's LDA and start it with different user IDs? My scenario: Dovecot authenticates users for Postfix and itself using Postgresql. Mails for two domains should be stored under /srv/<domain>/<user> (which is the location returned by my user_sql query and mail_location). When my clients login (with usernames of the form 'user@domain'), Dovecot creates/opens the correct mailboxes for them, but I can't get LDA to deliver to these mailboxes. Whatever I try, I am always running into some kind of permission problems (either for the mailboxes, or for auth_socket). I want to use a unique UID for every virtual domain, so I guess LDA needs to have permissions for every corresponding mailbox *and* Dovecot's auth_socket_path. Is there a good solution for this which doesn't involve severe security implications? J. -- If all my friends had Playstations I would buy a Nintendo to prove my individuality. [Agree] [Disagree] <http://www.slowlydownward.com/NODATA/data_enter2.html>

6 7

[Dovecot] Another numptie question - making maildirs for shared mailboxes.
by Stroller 12 May '08

12 May '08

Hi there, Sorry to have so much trouble with my Dovecot setup & to ask so many questions, but I'm having some problems with shared folders. I've read the thread at <http://dovecot.org/pipermail/dovecot/2005-January/006079.html> and added the following lines to /etc/dovecot.conf: namespace private { separator = / prefix = inbox = yes } namespace public { separator = / prefix = General/ location = maildir:/tmp/dovecot-test/ inbox = no hidden = no } So I create a directory /tmp/dovecot-test/ and an empty file /tmp/dovecot-test/dovecot-shared with liberal (777 & 666 respectively) permissions and then try to subscribe to the "General" folder in Outlook - I get a "failed to subscribe to the folder. The server responded `the mailbox doesn't exist: General`" error message, but cur, new & tmp are created in /tmp/dovecot-test. These subfolders are owned by the user that attempted to subscribe & have 700 permissions; chmod'ing them 777 makes no difference. Since "default_mail_env = maildir:%h/.maildir" in dovecot.conf I make a directory /tmp/dovecot-test/.maildir also containing cur, new, tmp & dovecot-shared. When I select "IMAP folders" in Outlook I am still unable to subscribe to "General" but am now able to subscribe to "General/maildir". The subscribed folder is shown in Outlook underneath the users' Inbox as a sub-folder of general, screenshot at <http://linux.stroller.uk.eu.org/DovecotSharedFolders.png> - see how I can't subscribe to "General" alone, but it is "brought in" by subscribing to "General/maildir"? If I try to copy a test message into General then, after a delay of a minute or so, I get "Can't move the items - this IMAP command could not be sent to the server before the connect was terminated"; if I try to copy the test message into General/maildir then I immediately get "Can't copy the items. The server responded: `Internal error occurred. Refer to server log for more information [2005-12-20 12:05:40]". I've tried tinkering with other directory structures under /tmp/dovecot-test/ with no success - can anyone suggest what I'm doing wrong, please? It's quite important to me that the "General" folder is a fairly high-level one - only one additional folder icon should show up for the users' shared mail. At one point I managed to create a folder General/General, but that's undesirable - the users wouldn't understand the concept of having a folder showing in Outlook that they can't write to, or which is only used as a container for another folder. (In any case, I believe I was still unable to write to it). I was about to say, "I know I could resolve this with the use of a symlink-type shared folder, but that's undesirable because I'd have to manually add the symlink for each user that's added to the system", but writing this it occurs to me that I could resolve that by adding the symlink to the the etc/skel/. Nevertheless, I see the namespaces approach as more elegant, as it allows for different user groups having different shared folders. I'd appreciate any advice - I suspect I'm just getting the directory hierarchies wrong, or the syntax of dovecot.conf wrong AGAIN! If anyone with a working shared folders setup could provide a copy of the appropriate section of dovecot.conf & a listing of the appropriate directories then I'd be EXTREMELY grateful. Stroller.

7 12

[Dovecot] Dovecot, LDAP and something akin to Postfix' "table search order" from virtual deliver.
by Pawel Sawicki 01 Feb '08

01 Feb '08

Hi. /* The short version. */ Is there a way to mimic Postfix' "table search order" in Dovecot's LDAP configuration of pass_filter/user_filter? /* Here goes the detailed description :) */ Just to quote the http://www.postfix.org/virtual.8.html: --- TABLE SEARCH ORDER (...) The search order is as follows. The search stops upon the first successful lookup. (...) o The user(a)domain.tld address, without address exten- sion, is looked up next. o Finally, the recipient @domain is looked up. --- Basicaly this allows to have separate users assigned addresses like j.doe(a)example.com (first account), j.smith(a)example.com (second account) and at the same time to have a "catch all" anything(a)example.com mailbox (for the administrator e.g.). What do I need it for? To have dovecot-lda working. Why? I want Sieve :) The test data may look as follows: account #1: + mail: j.doe(a)example.com + mailAlternateAddress: j.c.doe(a)example.com account #2: + mail: j.smith(a)example.com + mailAlternateAddress: j.t.smith(a)example.com account #3 (administrator): + mail: bofh(a)example.com + mailAlternateAddress: @example.com (means - anything possible) The filter I used is (more or less - for both pass_filter and user_filter): (|(mail=%u)(mailAlternateAddress=%u)(mailAlternateAddress=@%d)) Just for testing purposes I've stripped off some irrelevant data (like checking if the account is active), since that made the filter about 140 characters long ;) The trouble is when there're both a "catch all" and a true account that are linked to different accounts. As an example, if I try to send mail to "j.doe(a)example.com" I receive: dovecot: auth(default): ldap(j.doe(a)example.com): Multiple replies found for user Which is of course true, since the filter returns "account #2" and "account #3". What I'd like to get? I'd like to set the filter to: (|(mail=%u)(mailAlternateAddress=%u)) Where "%u" is expanded to "j.doe(a)example.com" during the first run Then, if dovecot can't find any user that would match this literaly it should retry the search operation, but now with "@example.com" as the "%u". I've tried to fiddle with the filter itself, but I see any reasonable way of doing it. I don't even know if it is possible at all. Could anyone give me a hint? Or maybe it's already on someone's whish list? Some final info. * I've followed the examples on dovecot.org website: http://wiki.dovecot.org/LDA#head-dacb9b9a1f19c3ea86bb6f8caa3d64e3ddad9ef8 * Here's the dovecot's master.conf entry: dovecot unix - n n - - pipe flags=DRhu user=mail:mail argv=/usr/libexec/dovecot/deliver -d ${recipient} Best regards! Pawel Sawicki

2 2

[Dovecot] Too many open files
by Andrew Hutchings 10 Jan '08

10 Jan '08

Hi Guys, Just got this on one of my test72 dovecot servers: - Jun 10 12:40:28 svr21 dovecot: auth(default): net_connect_unix(/var/run/dovecot/auth-worker.18818) failed: Too many open files Jun 10 12:40:28 svr21 dovecot: pop3-login: Disconnected: method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx Jun 10 12:40:28 svr21 dovecot: pop3-login: Disconnected: method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx Jun 10 12:40:28 svr21 dovecot: child 18818 (auth) returned error 89 Jun 10 12:40:29 svr21 dovecot: Auth process died too early - shutting down Jun 10 12:40:29 svr21 dovecot: auth(default): mysql: Connected to localhost (maildb) Jun 10 12:40:29 svr21 dovecot: auth(default): net_connect_unix(/var/run/dovecot/auth-worker.13784) failed: No such file or directory Jun 10 12:40:29 svr21 dovecot: child 13784 (auth) returned error 89 - Is dovecot leaving files open? Or is it a large mailbox? Regards Andrew -- Andrew Hutchings (A-Wing) Linux Guru - Netserve Consultants Ltd. - http://www.domaincity.co.uk/ Admin - North Wales Linux User Group - http://www.nwlug.org.uk/ BOFH excuse 122: because Bill Gates is a Jehovah's witness and so nothing can work on St. Swithin's day.

5 5

[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] Different classes of user
by John Robinson 17 Apr '07

17 Apr '07

Hello list! Only recently joined, please excuse me if this is a stupid question. I'd like to have 2 classes of user: those with shell accounts, and those without. They'll all have "real" accounts, for which the password can be checked with PAM. I've set up SSL too. What I want to arrange is for users with shell accounts not to be succeed in logging in to Dovecot without using TLS/SSL. I'll have to allow unencrypted logins (for non-shell users), but I want to reject/refuse such a login from someone with a shell account. I've already made my exim do this, with the following logic in my authenticator there: if (pam auth ok) and ((tls) or (user's shell not listed in /etc/shells)) I haven't worked out how to make Dovecot do this, yet. So far I just tried using * as the PAM service name, in the hope that not only would pop3 or imap get passed through, but pop3s and imaps might, and I had a line in my /etc/pam.d/imap and pop like this: auth required pam_succeed_if.so debug shell notin /bin/bash:/bin/sh which worked, but unfortunately also got used for imapS logins. Then I realised this was likely to be the wrong thing anyway, because it would presumably only cover IMAPS on port 993, and not IMAP+TLS on the usual port 143. So I've had a go but got it wrong. What should I do to get it right? Cheers, John.

3 11

[Dovecot] Bug tracking system
by Timo Sirainen 26 Mar '07

26 Mar '07

There are three reasons why I haven't really bothered setting up a bug tracking system for Dovecot: 1) They're all kind of annoying to use. 2) They all require a lot of stuff like PHP, SQL server, etc. which I don't really want to put into dovecot.org. 3) Probably most importantly: If people start reporing bugs in there, I'm pretty much the only person who will ever read them and reply to them. Currently when people report bugs in here, it's quite useful to have other people read them too. They may already know the bug and say they've reported it, they may have an idea what's causing it, they may know a workaround, etc. All in all, moving things to BTS would most likely cause my life to be harder and it might be more difficult to get some bugs fixed. A couple of days ago I started thinking about this and then I figured out a way to solve all of this nicely with a new and great Dovecot based bug tracking system. :) Just so I won't forget it, here's the plan: Dovecot BTS ----------- The preferred way to report bugs is to send them to dovecot-bugs(a)dovecot.org. The only thing it does is prefix the subject line with [BUG #nnn] and forward it to dovecot(a)dovecot.org. Now everyone can reply to it just as it was a normal mailing list mail. As long the subject contains the "[BUG #nnn]" prefix, it's part of the bug. Existing mailing list threads can also be turned into bugs by replying to the thread's root message with To: dovecot-bugs(a)dovecot.org. This again causes the new reply to contain [BUG #nnn] prefix. Then comes the web part. There's no SQL database or anything, everything is stored in a mailbox in the IMAP server. The mailbox contains the whole dovecot(a)dovecot.org archive. Bug metadata such as priority, status, etc. is stored using IMAP ANNOTATE extension, which allows setting key=value pairs to messages. Unfortunately Dovecot doesn't yet support that extension. Bugs' root messages contain the annotations for the whole bug thread. So to get a list of all bugs, the BTS issues an IMAP SEARCH ANNOTATE command to list all messages with some specific "bug=yes" type of annotation. For those messages then it can fetch the subject and whatever else metadata it wants. Newly created bugs don't have annotations though. To fix that, the BTS also uses ANNOTATEMORE (or is it METADATA nowadays?) extension to keep "last seen message in BTS" state in the mailbox's annotations. It then issues a SEARCH SUBJECT "[bug #" command for the new messages and does THREAD command for them to see if they're the bug root, or if they were replies to another message which should be treated as the bug root. When viewing a bug, the bug metadata comes from the annotations. Annotation history could also be kept, possibly as messages in another history mailbox. The messages for a bug can be viewed by issuing a THREAD (REFERENCES) command and showing all the mails that exist under the bug root. So, any volunteers to implement the web part, if I implement the ANNOTATE extension? :) It would actually even be possible to implement multiple frontends. All I need to do is give you access (read-only, or read-write for some) to the bug tracking mailbox, and you can use whatever frontend you wish, even a non-web one!

17 39