[Dovecot] mdbox + gzip and rsync
Hi, After reading the following paragraph from the dovecot doc, I've been wondering how it would affect rsync (when combined with gzip): "Expunging a message only decreases the message's refcount. The space is later freed in "purge" step. This is typically done in a nightly cronjob when there's less disk I/O activity. The purging first finds all files that have refcount=0 mails. Then it goes through each file and copies the refcount>0 mails to other mdbox files (to the same files as where newly saved messages would also go), updates the map index and finally deletes the original file. So there is never any overwriting or file truncation." How will the mailbox files (m.X) files be modified when I move or delete emails using mdbox+gzip. Will the resulting gzipped mdbox files be rsync-able or will they need a full re-upload? If I plan on using rsync for backups, am I better off not using the gzip feature (if i can spare the extra storage)??? Thanks, -JD
[Dovecot] nfs error fcntl(read-lock) locking failed for file
hi i am using qmailtoaster with dovecot version 2 mailbox format is maildir i have a domain with around 5000 users which are distributed over 2 servers webmail (squirrelmail) runs using dovecot v2 is being used from server number one server number 2 had all the data stored in it and also has pop and smtp running from it. i am not using dovecot for pop as yet on the server with dovecot i get such errors in the log file access to data on server number 2 is via nfs on server number 1 i get errors as such Error: fcntl(read-lock) locking failed for file Input/output error squirrelmail gives error imap connection closed and i am not able to login so i set the parameters as such in the dovecot conf file and the error stopped mmap_disable=yes dotlock_use_excl = yes lock_method = dotlock can somebody please advise me if the above is correct ? or is it preferred to use fcntl with lockd (note that my mailbox is maildir format) thanks very much for your help rajesh
Re: [Dovecot] http://xi.rename-it.nl down?
am 07.03.12 00:33 schrieb Stephan Bosch : On 3/7/2012 12:19 AM, Jim Knuth wrote: Hello, you knows, that http://xi.rename-it.nl is down? Yep, and back. Regards, Stephan. wow. Thank you -- Mit freundlichen Grüßen, with kind regards, Jim Knuth - Dilettanten erkennt man an der Plumpheit ihrer Komplimente. Der routinierte Verführer riskiert Kritik. (Cathérine Deneuve)
Re: [Dovecot] http://xi.rename-it.nl down?
On 3/7/2012 12:19 AM, Jim Knuth wrote: Hello, you knows, that http://xi.rename-it.nl is down? Yep, and back. Regards, Stephan.
[Dovecot] http://xi.rename-it.nl down?
Hello, you knows, that http://xi.rename-it.nl is down? -- Mit freundlichen Grüßen, with kind regards, Jim Knuth - Die Oper ist eine hübsche Unterhaltung, die noch besser wäre, wenn nicht dabei gesungen würde. (Claude Debussy)
[Dovecot] Fscking warnings
Google tells me that these "should go away" but they don't. Seems to happen continuously while a user is viewing email. Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Archive/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Davies/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/FieldNET/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Invoices Out/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Lawrence and Hanson/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Logger Call/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Logger Reset/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/River Murray/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/SMS Emails/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Soil Moisture Alert/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Water Management Alarm/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Water Usage/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Weather Summaries/dovecot.index Mar 7 09:29:52 server dovecot: imap(john): Warning: fscking index file /home/john/Mail/INBOX/.imap/Zerna/dovecot.index -- = Stephen Davies Consulting P/L Voice: 08-8177 1595 Adelaide, South Australia.Fax : 08-8177 0133 Records & Collections Management. Mobile:040 304 0583
[Dovecot] Log sync errors (again)
As suggested earlier, I deleted all .imap directories and the log sync errors stopped - for a while. They have now returned. It seems to happen for every mailbox that gets accessed. Dovecot version 2.1.1 with pidgeonhole 3.0.0 on Mandriva Linux. Could this interfere with sieve filters? Several users have filters but none of them seem to do anything. Mar 7 09:25:51 server dovecot: imap(john): Error: Log synchronization error at seq=2,offset=38708 for /home/john/Mail/INBOX/.imap/Weather Summaries/dovecot.index: Extension header update points outside header size Mar 7 09:25:51 server dovecot: imap(john): Error: Log synchronization error at seq=2,offset=41576 for /home/john/Mail/INBOX/.imap/Zerna/dovecot.index: Extension header update points outside header size Cheers and thanks, Stephen -- = Stephen Davies Consulting P/L Voice: 08-8177 1595 Adelaide, South Australia.Fax : 08-8177 0133 Records & Collections Management. Mobile:040 304 0583
Re: [Dovecot] Shared mboxes
On 3/6/2012 3:17 PM, Stan Hoeppner wrote: On 3/6/2012 8:28 AM, Steve Campbell wrote: http://wiki.dovecot.org/SharedMailboxes That's where most of my questions originated, but thanks for the reply. Steve, all the information you need is behind that link. I've gone over that set of links on that page a dozen times. Perhaps I'm trying to put a square peg in a round hole by using mbox, but they keep providing information on it, so I guess I was just pounding away. But then there's that "don't use maildir and mbox together". All of the accounts on this server are carry-overs from the UW-IMAP server, so perhaps I should have converted those to maildir. Seems as though it's OK when they don't apply to the same type namespace. Maybe I'm misunderstanding concepts here Very possibly. What I've done in the past with the old imap server is to create an account (unix account), so the smtp server puts the mbox (what is referred to as the INbox) in /var/spool/mail. Users who needed to "share" this mailbox would be give the account user name and the password for this account and would add an Imap account to their mail client. This would sometimes cause locking problems or client corruption due to email removals mostly. This is basically a normal, non-shared account. Locking problems with multiple users hitting mbox files is unavoidable. The same is true when a single user hits an mbox from multiple client devices simultaneously--PC, smart phone, tablet, etc. Which is why you do not want to use mbox file format for shared mailboxes, but maildir instead, because each email is a separate file. Please note, from the link I provided: I've experienced that type of locked mailbox before on the old server. Users insist on accessing their email account as a pop account on their desktop with the "check for new mail every so many minutes" turned on and still keep their smartphones on while accessing it as an imap account so they can still download the files to their desktop when they return. ** Maildir: Per-user \Seen flag With Maildir a dovecot-shared file controls if the \Seen flags are shared or private. The file must be created separately inside each Maildir, although if the file already exists in the Maildir root it's automatically copied for newly created mailboxes. If dovecot-shared file doesn't exist in Maildir, the \Seen flags are shared. If it exists, the \Seen flag state is stored only in the user's index files. By making each user have their own private index files, you can make the \Seen flag private for the users. ** Simple concept above: each user of the shared mailbox sees "new" mail. One user accessing new mail and marking it as read doesn't mark that message as read for other shared users. You can not do this with mbox file format, only maildir. ** Maildir: Keyword sharing Make sure you don't try to use per-user CONTROL directory. Otherwise dovecot-keywords file doesn't get shared and keyword mapping breaks. Other mailbox formats Currently you can't have any per-user flags with other mailbox formats than Maildir. ** So just to clarify, is it OK to have a maildir account setup on this server for these shared/imap access only accounts along with the mbox accounts already on there? Thanks for the patience and help steve
Re: [Dovecot] Shared mboxes
On 3/6/2012 8:28 AM, Steve Campbell wrote: >> http://wiki.dovecot.org/SharedMailboxes > That's where most of my questions originated, but thanks for the reply. Steve, all the information you need is behind that link. > Maybe I'm misunderstanding concepts here Very possibly. > What I've done in the past with the old imap server is to create an > account (unix account), so the smtp server puts the mbox (what is > referred to as the INbox) in /var/spool/mail. Users who needed to > "share" this mailbox would be give the account user name and the > password for this account and would add an Imap account to their mail > client. This would sometimes cause locking problems or client corruption > due to email removals mostly. This is basically a normal, non-shared > account. Locking problems with multiple users hitting mbox files is unavoidable. The same is true when a single user hits an mbox from multiple client devices simultaneously--PC, smart phone, tablet, etc. Which is why you do not want to use mbox file format for shared mailboxes, but maildir instead, because each email is a separate file. Please note, from the link I provided: ** Maildir: Per-user \Seen flag With Maildir a dovecot-shared file controls if the \Seen flags are shared or private. The file must be created separately inside each Maildir, although if the file already exists in the Maildir root it's automatically copied for newly created mailboxes. If dovecot-shared file doesn't exist in Maildir, the \Seen flags are shared. If it exists, the \Seen flag state is stored only in the user's index files. By making each user have their own private index files, you can make the \Seen flag private for the users. ** Simple concept above: each user of the shared mailbox sees "new" mail. One user accessing new mail and marking it as read doesn't mark that message as read for other shared users. You can not do this with mbox file format, only maildir. ** Maildir: Keyword sharing Make sure you don't try to use per-user CONTROL directory. Otherwise dovecot-keywords file doesn't get shared and keyword mapping breaks. Other mailbox formats Currently you can't have any per-user flags with other mailbox formats than Maildir. ** -- Stan
Re: [Dovecot] [PATCH] GSSAPI authorization and virtual users
On Mon, 2012-03-05 at 20:52 +0200, Timo Sirainen wrote:
> On 5.3.2012, at 20.45, Sam Morris wrote:
>
> > 3. The credentials lookup triggers an info log message saying that
> >credentials for GSSAPI were requested, "but we have only (e.g.)
> >MD5-CRYPT". The authplugin doesn't actually want the credential,
> >but I think that the only way the authplugin can trigger a
> >passdb lookup is by requesting it.
>
> I'll look at the rest more closely later, but this should be an easy fix:
> request "" instead of "GSSAPI".
Thanks for pointing that out. Here's a newer version of the patch with
that change. I also realised that the gss_buffer is not required in the
code that runs once the passdb lookup is complete, so I removed the code
that stashes it in struct gssapi_auth_request.
Regards,
--
Sam Morris
Index: dovecot-2.0.15/src/auth/auth-request.c
===
--- dovecot-2.0.15.orig/src/auth/auth-request.c 2012-03-06 11:01:03.0 +
+++ dovecot-2.0.15/src/auth/auth-request.c 2012-03-06 15:20:38.0 +
@@ -45,6 +45,8 @@ auth_request_new(const struct mech_modul
request->refcount = 1;
request->last_access = ioloop_time;
+ p_array_init (&request->gssapi_k5principals, request->pool, 0);
+
request->set = global_auth_settings;
request->mech = mech;
request->mech_name = mech == NULL ? NULL : mech->mech_name;
@@ -63,6 +65,8 @@ struct auth_request *auth_request_new_du
request->state = AUTH_REQUEST_STATE_NEW;
auth_request_state_count[AUTH_REQUEST_STATE_NEW]++;
+ p_array_init (&request->gssapi_k5principals, request->pool, 0);
+
request->refcount = 1;
request->last_access = ioloop_time;
request->set = global_auth_settings;
@@ -1157,6 +1161,17 @@ auth_request_try_update_username(struct
return TRUE;
}
+static void
+auth_request_store_k5principals(struct auth_request *request,
+const char* value)
+{
+ for (const char* const* pr = t_strsplit_spaces (value, ","); *pr != NULL; ++pr) {
+ char* pr_in_pool = p_strdup(request->pool, *pr);
+ auth_request_log_debug(request, "auth", "k5 principal: %s may access %s", pr_in_pool, request->user);
+ array_append(&request->gssapi_k5principals, &pr_in_pool, 1);
+ }
+}
+
void auth_request_set_field(struct auth_request *request,
const char *name, const char *value,
const char *default_scheme)
@@ -1203,6 +1218,9 @@ void auth_request_set_field(struct auth_
if (request->userdb_reply == NULL)
auth_request_init_userdb_reply(request);
auth_request_set_userdb_field(request, name + 7, value);
+ } else if (strcmp(name, "k5principals") == 0) {
+ auth_request_log_debug(request, "auth", "k5 principal: storing");
+ auth_request_store_k5principals(request, value);
} else {
/* these fields are returned to client */
auth_request_set_reply_field(request, name, value);
Index: dovecot-2.0.15/src/auth/auth-request.h
===
--- dovecot-2.0.15.orig/src/auth/auth-request.h 2012-03-06 11:01:03.0 +
+++ dovecot-2.0.15/src/auth/auth-request.h 2012-03-06 15:20:38.0 +
@@ -1,6 +1,8 @@
#ifndef AUTH_REQUEST_H
#define AUTH_REQUEST_H
+#include "../lib/array.h"
+
#include "network.h"
#include "mech.h"
#include "userdb.h"
@@ -114,6 +116,8 @@ struct auth_request {
unsigned int removed_from_handler:1;
/* ... mechanism specific data ... */
+ //char* gssapi_k5principals[];
+ ARRAY_DEFINE(gssapi_k5principals, char*);
};
extern unsigned int auth_request_state_count[AUTH_REQUEST_STATE_MAX];
Index: dovecot-2.0.15/src/auth/mech-gssapi.c
===
--- dovecot-2.0.15.orig/src/auth/mech-gssapi.c 2012-03-06 11:01:03.0 +
+++ dovecot-2.0.15/src/auth/mech-gssapi.c 2012-03-06 17:59:30.0 +
@@ -419,9 +419,23 @@ mech_gssapi_krb5_userok(struct gssapi_au
"krb5_parse_name() failed: %d",
(int)krb5_err);
} else {
+ /* See if the principal is in the list of authorized
+ * principals for the user */
+ auth_request_log_debug(&request->auth_request, "gssapi", "%u authorized princpals", array_count_i(&request->auth_request.gssapi_k5principals));
+ const char* const* authorized_principal;
+ array_foreach(&request->auth_request.gssapi_k5principals, authorized_principal) {
+ if (strcmp (princ_display_name, *authorized_principal) == 0) {
+auth_request_log_debug(&request->auth_request, "gssapi", "authorized principal: %s", *authorized_principal);
+ret = TRUE;
+break;
+ }
+ }
+
/* See if the principal is authorized to act as the
- specified user */
- ret = krb5_kuserok(ctx, princ, login_user);
+ specified (UNIX) user */
+ if (!ret)
+ ret = krb5_kuserok(ctx, princ, login_user);
+
krb5_free_principal(ctx, princ);
}
krb5_free_context(ctx);
@@ -483,11 +497,30 @@ mech_gssapi_userok(struct gssapi_auth_re
#else
Re: [Dovecot] Master Users
On 03/05/12 17:33, Kelsey Cummings wrote: I have a setup where I need to use a Master User account to login on behalf of users normally authed via PAM. Is there any existing mechanism that will allow master users to be wired down to specific ip address rather Ah, found it. http://wiki2.dovecot.org/PasswordDatabase/ExtraFields/AllowNets -K
[Dovecot] Dovecot saves mails in "wrong" folder.
Hi all I have installed dovecot 1.2.15 and try to use it together with offlineimap and gnus. my problem is that it saves emails into /var/mail/petro instead of ~/Maildir Thanks. Petro. This is my .dovecot.conf default_mail_env = maildir:%h/Maildir And this is my .offlineimaprc [general] accounts = Gmail maxsyncaccounts = 1 [Account Gmail] localrepository = Local remoterepository = Remote [Repository Local] type = IMAP remotehost = localhost port = 143 remoteuser = petro [Repository Remote] type = IMAP remotehost = imap.gmail.com remoteuser = myn...@gmail.com ssl = yes maxconnections = 1 realdelete = no folderfilter = lambda foldername: foldername in ['INBOX'] --
Re: [Dovecot] Shared mboxes
On 3/5/2012 6:16 PM, Stan Hoeppner wrote: On 3/5/2012 1:30 PM, Steve Campbell wrote: I've been looking at some documentation on shared mail accounts. But I'm getting mixed thoughts on how this can or should be done. I use mbox for all my pop and imap folders since I've converted from a uw-imap server. The first thing that makes me wonder about setup is that I've been told to not use maildir and mbox on the same machine, although I'm not really sure why since it seems this would work OK, but anyway, I'm guessing I should stick with mbox for the shared accounts. Secondly, I'm sure I'd need a namespace to use which ever format, so there's private, public, and shared types. Most of the stuff I'm reading seems to suggest "public" as a type instead of "shared". So what's shared for anyway? I want to use this shared account so that email can be sent to this account, and be shared by only a few people, but I'm reading where locks and such don't work with mbox, so in my mind, how do you avoid corruption and why not just make a normal account and let people hack away at the data? I've not even got to the questions in my mind about how to set up the account, but figured if I could get the above straight, I might be able to fuddle my way through it. Help would be truly appreciated. Start here: http://wiki.dovecot.org/SharedMailboxes That's where most of my questions originated, but thanks for the reply. (Sorry for the first response - I sent it to the poster, not the list). Maybe I'm misunderstanding concepts here and I'm trying to use something I don't need to use. I'm really new to dovecot, and as I learn all the ins and outs, I'm finding a lot of this doesn't seem to be "turning on any light bulbs" until after I've played with it a while. What I've done in the past with the old imap server is to create an account (unix account), so the smtp server puts the mbox (what is referred to as the INbox) in /var/spool/mail. Users who needed to "share" this mailbox would be give the account user name and the password for this account and would add an Imap account to their mail client. This would sometimes cause locking problems or client corruption due to email removals mostly. This is basically a normal, non-shared account. Now that I've moved to dovecot on a new, updated server, I'd like to use the facilities of dovecot for the truly shared accounts. I'm not sure if I need to create the account like before, but seems like I'd have to in order to get the smtp server to deliver new email to /var/spool/mail/%u. As I see it, I've got to create a namespace for shared accounts and configure this on the multiple-user's clients so that when they access the Inbox and imap files under /home/%u/mail, they don't butt heads, so they're some locking involved. I could use acls for this, but don't have to according to the documentation. I can grant permissions to each user that is included in the acl, and I can create dovecot "groups" to use as a basis for this permission. I'm hoping this is pretty much the way it's done, and I want to keep with mbox format for all files and folders. I'm also hoping that this is the way it's supposed to be used, but I get conflicting ideas about what the documentation is really telling me. Anyway, I'll play with this and see where I get. I've still not found out where to create these dovecot "groups" other than it seems to use a userdb file somewhere. Thanks for the help so far steve
[Dovecot] bug uni_utf8_str_is_valid(vname)
Heya, We are expiriencing issues with dovecot 2.1.1 on Linux with weird filenames in home directory of username. We are using mbox IMAP folders, with no special changes (mail_location = mbox:~/:INBOX=%h/.mailbox). Mar 6 13:37:17 machine dovecot: imap(username): Panic: file mail-storage.c: line 628 (mailbox_alloc): assertion failed: (uni_utf8_str_is_valid(vname)) Mar 6 13:37:17 machine dovecot: imap(username): Error: Raw backtrace: /opt/dovecot-2.1.1/lib/dovecot/libdovecot.so.0 [0x2ba41cb79450] -> /opt/dovecot-2.1.1/lib/dovecot/libdovecot.so.0 [0x2ba41cb794a6] -> /opt/dovecot-2.1.1/lib/dovecot/libdovecot.so.0 [0x2ba41cb78963] -> /opt/dovecot-2.1.1/lib/dovecot/libdovecot-storage.so.0 [0x2ba41c87ebd5] -> /opt/dovecot-2.1.1/lib/dovecot/libdovecot-storage.so.0 [0x2ba41c88c12c] -> /opt/dovecot-2.1.1/lib/dovecot/libdovecot-storage.so.0(fs_list_iter_next+0x1b4) [0x2ba41c88c494] -> /opt/dovecot-2.1.1/lib/dovecot/libdovecot-storage.so.0 [0x2ba41c885342] -> /opt/dovecot-2.1.1/lib/dovecot/libdovecot-storage.so.0(mailbox_list_iter_next+0x234) [0x2ba41c885604] -> dovecot/imap [0x40b2d1] -> dovecot/imap(cmd_list_full+0x520) [0x40c1f0] -> dovecot/imap(cmd_list+0xb) [0x40c3eb] -> dovecot/imap(command_exec+0x37) [0x410427] -> dovecot/imap [0x40f4cd] -> dovecot/imap [0x40f582] -> dovecot/imap(client_handle_input+0x3f) [0x40f6cf] -> dovecot/imap(client_input+0x62) [0x410052] -> /opt/dovecot Mar 6 13:37:17 machine dovecot: imap(username): Fatal: master: service(imap): child 20873 killed with signal 6 (core dumps disabled) The bug is reproducible by using home folder structure available from: http://bit.ly/x8pTXS AFAIK, the problem lies in processing the file list of home folder, which can contain filenames that do not have proper UTF-8 encoding of filenames, which causes dovecot to crash. On the other hand, UTF-8 filenames created on the system by hand (using touch), are not displayed in IMAP LIST command (sample is included in the folder structure; single letter file). Cheers, Jernej
Re: [Dovecot] LDAP auth_bind fails
On 6.3.2012, at 13.29, Pol Bettinger wrote: > I wanted to configure dovecot for using auth_bind but didn't succeed to me it > seems like it does always an anonymous bind. .. > Mar 6 12:16:34 Dell dovecot: auth: Debug: client in: AUTH#0112#011CRAM-MD5 CRAM-MD5 can't work with auth_bind. http://wiki2.dovecot.org/Authentication/Mechanisms#Non-plaintext_authentication
[Dovecot] LDAP auth_bind fails
Hello,
I wanted to configure dovecot for using auth_bind but didn't succeed to
me it seems like it does always an anonymous bind.
Dovecot version 2.1.1 (I started with 2.1.0 and hoped 2.1.1 would fix it)
I tried to play around with the base, pass_attrs,pass_filter to no avail
but didn't succeed.
Looking at a wireshark trace i only saw 7 packets and it seemed to me
dovecot did only an anonymous bind.
any help would appreciated
Sincerely
Pol Bettinger
output of mail.log:
Mar 6 12:16:34 Dell dovecot: auth: Debug: client in:
AUTH#0112#011CRAM-MD5#011service=imap#011secured#011lip=192.168.16.27#011rip=192.168.16.20#011lport=993#011rport=51838
Mar 6 12:16:34 Dell dovecot: auth: Debug: client out:
CONT#0112#011PDQ1NjgyMjE3NjYyMDk3NjkuMTMzMTAzMjU5NEBEZWxsPg==
Mar 6 12:16:34 Dell dovecot: auth: Debug: client in: CONT
Mar 6 12:16:34 Dell dovecot: auth: Debug:
password(a...@arvoreen.net,192.168.16.20): passdb doesn't support
credential lookups
Mar 6 12:16:36 Dell dovecot: auth: Debug: client out:
FAIL#0112#011user=a...@arvoreen.net
output of dovecot -n:
# 2.1.1: /etc/dovecot/dovecot.conf
# OS: Linux 3.0.0-15-generic i686 Ubuntu 11.10 ext4
auth_debug = yes
auth_default_realm = arvoreen.net
auth_mechanisms = plain digest-md5 cram-md5
auth_verbose = yes
base_dir = /var/run/dovecot/
mail_location = maildir:/var/mail/%d/%1n/%n:INDEX=/var/indexes/%d/%1n/%n
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope
encoded-character vacation subaddress comparator-i;ascii-numeric
relational regex imap4flags copy include variables body enotify
environment mailbox date ihave
namespace inbox {
inbox = yes
location =
mailbox Archive {
auto = create
special_use = \Archive
}
mailbox Drafts {
auto = create
special_use = \Drafts
}
mailbox Junk {
auto = create
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
auto = create
special_use = \Trash
}
prefix =
}
passdb {
args = /etc/dovecot/dovecot-ldap_pass.conf.ext
driver = ldap
}
plugin {
sieve = /var/sieve/%d/%1n/%n
sieve_dir = /var/sieve/%d/%1n/%n
}
protocols = imap lmtp sieve
service managesieve-login {
inet_listener sieve {
port = 4190
}
}
ssl_cert = olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
anonymou
s auth by dn="cn=admin,dc=arvoreen,dc=net" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=arvoreen,dc=net"
write by
* read
ldap_auth_bind.pcap
Description: Binary data
Re: [Dovecot] dovecot 2.1.1 + pigeonhole + avelsieve
On 3/6/2012 8:37 AM, Frank Elsner wrote:
Hello all,
I've squirrelmail-webmail-1.4.22, dovecot 2.1.1, dovecot-2.1-pigeonhole-0.3.0
installed and working. But I've problems to get the avelsieve plugin for
squirrelmail working with dovecot.
The "Message Filters" show up in "Options" of squirrelmail, but
"Could not log on to timsieved daemon on your IMAP server ."
dovecot log shows:
Mar 6 00:00:47 seymour dovecot: managesieve-login: Disconnected: Too many
invalid commands. (no auth attempts in 0 secs): 192.168.28.53, secured
You should try to capture traffic between client and server with ngrep, e.g.
sudo ngrep -d lo port 4190
However, I've noticed that avelsieve uses STARTTLS even on localhost, so
if you want to see anything intelligible, you will have to turn that off
temporarily. As far as I know, there is also a means to instruct
managesieve-login to write its traffic somewhere (a login 'rawlog'), but
I can't find where it is documented right now.
| protocol lmtp {
| mail_plugins = " notify quota quota"
| }
| protocol lda {
| mail_plugins = " notify quota quota"
| }
| protocol imap {
| imap_client_workarounds = delay-newmail tb-extra-mailbox-sep tb-lsub-flags
| imap_logout_format = [%i/%o]
| mail_max_userip_connections = 0
| mail_plugins = " notify quota mail_log quota imap_quota listescape"
| }
Why do you have duplicate "quota" entries here? Also, "sieve" plugin is
missing from lmtp and lda. Still, ManageSieve should accept connections
with this config.
Regards,
Stephan.
Re: [Dovecot] Concurrent dovecot instances on same spool?
Il 05/03/2012 18.53, Timo Sirainen ha scritto: On 5.3.2012, at 19.25, Jacek Osiecki wrote: However, if we have everything redundant, why not have the same with SMTP and POP3/IMAP? But - won't anything fail if two (or more) dovecots are accessing the same disk space, both for IMAP/POP3 and LDA/LMTP? If both servers randomly access users' mails, with NFS you'll have some trouble, with OCFS2 probably less trouble. But in both cases you'll have better performance and no problems if you use Dovecot director in both servers (install both director and backend to both servers). http://wiki2.dovecot.org/Director Thanks, I'll probably give it a try. On the other hand, it would be nice to have a possibility to allow multiple dovecot instances to access mail spool (at cost of handling some extra file/directory locks) - a bit slower, but safe... You can safely do that with director. Also the problem with NFS isn't locks, but caching. After reading a little bit, it seems that Director does the job of a decent load balancer, but in the middle instead of in front of your servers, I've limited problems with NFS by using "sticky" connections with long timeouts in my load balancer, unless they're disconnected for days, they'll always end up going through the same server for POP3/IMAP conections. Doesn't work great for the SMTP/LDA part though. Another question: as I assume, when you wrote about troubles it was applying to IMAP. How about LMTP/LDA? Can anything bad happen when one mailbox is being filled by LMTP/LDA from more than one server)? Yes, because they're still updating Dovecot index files. You could disable LMTP/LDA index updates, but I'm still not sure if it works 100% correctly (because dovecot-uidlist is appended to). In the rare case it does happen, NFS locking and concurrent_connections set to one has seemed to reduce my problems to a minimum.. I like the Director idea though, since it's content aware it isn't organizing connections based on port/IP, but on the the actual users, especially if it does so with the LDA, it seems like an excellent solution to collisions (I guess they're called this) .. I wish it had been a reality when I was building my servers.
