Re: [Dovecot] Disallow POP3 from deleting messages
On Mar 22, 2013, at 2:47 AM, Timo Sirainen wrote: > On Wed, 2013-03-20 at 17:40 -0600, dormitionsk...@hotmail.com wrote: >> On Mar 20, 2013, at 8:59 AM, Timo Sirainen wrote: >> >>> On Wed, 2013-03-20 at 08:15 -0600, dormitionsk...@hotmail.com wrote: >>> My experience with IMAP over the internet with a couple of servers outside our monastery (while I was in it, and we have considerably better download speeds than upload) has always been that IMAP has always been incredibly slow. So, I've always just allowed users to connect to the IMAP server via webmail. It's slow, but usable. >>> >>> Another idea: Get some cheap server from outside, use dsync replication >>> to keep it synced with your internal one, and set up DNS so that users >>> get directed to the fastest server. http://wiki2.dovecot.org/Replication >>> >>> >> >> I LIKE this idea, but I have a few questions about it to see if it >> would be appropriate for our situation. There are a few other things >> to consider that I didn't mention before because they did not seem >> relevant earlier. >> >> First off, I'd just like to say that we have a web server set up at a >> location outside of our monastery that hosts all of our websites. I'm >> currently in the process of building new servers to replace both it >> and our current email server. So, assuming this is both plausible for >> our situation, and within my capabilities, I should be able to work on >> this at my leisure, and get the initial sync of our emails done while >> on the same LAN. >> >> So, the additional info and questions are the following: >> >> 1.) Our download speeds are decent enough, but in addition to having >> poor upload speeds, we also have very strict limits on how much we are >> able to download. And we use almost every bit of it every day. We >> cannot get more, either. We have unlimited downloads for four hours >> at night, however. > > If a delayed sync isn't a problem, you could do it only once at nights. > You wouldn't need to use the replicator service at all, just run > "doveadm sync -f -A -d" in a cronjob. > >> 2.) We have very large message archives. We basically have 95% of >> the emails we've received for the past 16 years. So, the sync *must* >> only update items that have been changed. Is this how it it would >> work? > > dsync can do full sync (= all messages' metadata is sent + new messages' > contents), "changed sync" (= same as full sync, but only for changed > folders) or incremental sync (= only new messages' metadata + contents > are sent). The incremental sync is what replicator service does while > it's running, but it's still currently doing a full sync at startup. > > A nightly cronjob could do incremental syncing also, but it would have > to run dsync separately for each user and store the sync state to some > file. > > The "changed sync" works well enough usually, but it has a problem if > both replicas have had exactly the same amount of changes it doesn't > realize that there may be differences between them and skip it. > >> 3.) We are currently using uw-imap with mbox. If we switch to >> Dovecot, using Maildir format, will the sync only update the new >> messages and the header files for any folders that have been changed? > > It works the same with all mailbox formats. Headers and bodies aren't > synced separately, but metadata (= ~100 bytes/msg maybe) is. > >> 4.) I thought I read somewhere in Dovecot's documentation last night >> that it has a 50 mb limit on folders. It can't write anything larger >> than that. Does this sound familiar? (Now I can't find it!) If so, >> is that for mbox? We currently have some mbox folders whose files are >> significantly larger than that. If we convert to Maildir format, >> where the individual messages are in their own files, could a folder >> contain messages totaling more than 50 MB using Dovecot? > > Dovecot has no such limit. Postfix by default has set a file size limit > for 50 MB, which effectively limits mbox sizes to 50 MB, but it can be > removed with Postfix mailbox_size_limit setting. > >>4a. -- Oops. I just noticed this: "NOTE2: sdbox/mdbox mailbox >> formats are recommended for replication. Maildir still has some issues >> (although probably not noticeable in normal use)." Should I consider >> this a show-stopper for syncing like this? > > With v2.2 I don't think there's much of a difference anymore. > >> 5.) In the http://wiki2.dovecot.org/Replication page, would this be >> continuously synced each time a user sends, receives, deletes, or >> moves messages, etc.? Or would it be periodically synced? > > With replicator it syncs immediately when something changes. > >> 6.) Also, that page does not make it clear if one server is like the >> "master" and the other the "slave". Do I do the same changes to both >> servers? > > Both servers are equal. Setup both servers exactly the same. > >> If, given the above a
Re: [Dovecot] Reduce logging auth-worker
>> [root@mail:~]$ cat /etc/rsyslog.conf | grep database >> :msg, contains, "Connected to database dbmail" ~ was not helpful? well, not if you insist in not use syslog maybe you should explain why not using syslog as everybody else to taken serious because "i do not want" in case where it is clear you need is no reason Am 23.03.2013 02:58, schrieb Nick Edwards: > As usual you post with nothing helpful to say, I wont dignify your > regular trolling by commenting any further > > On 3/23/13, Reindl Harald wrote: >> >> >> Am 23.03.2013 02:31, schrieb Nick Edwards: >>> Hello Timo >>> >>> We would like to reduce the logging by increasing severity, we don't >>> use syslog since we use >>> >>> log_path = /var/log/dovecot/pop3.log >> >> why? >> >>> Is there a way auth-worker can be made to log warn|error instead of >>> info? >>> >>> Constantly 1/5th of the log file is filled with auth-work info >>> connecting to mysql socket, which we do not need to see unless, well, >>> we need to see it either via debug, or if there is a problem, I know >>> this can be done from syslog, but we prefer not to use syslog, and the >>> wiki does not indicate it can be done? >> >> but that is exactly why syslog exists instead re-invent the wheel >> >> [root@mail:~]$ cat /etc/rsyslog.conf | grep database >> :msg, contains, "Connected to database dbmail" ~ signature.asc Description: OpenPGP digital signature
Re: [Dovecot] Reduce logging auth-worker
As usual you post with nothing helpful to say, I wont dignify your regular trolling by commenting any further On 3/23/13, Reindl Harald wrote: > > > Am 23.03.2013 02:31, schrieb Nick Edwards: >> Hello Timo >> >> We would like to reduce the logging by increasing severity, we don't >> use syslog since we use >> >> log_path = /var/log/dovecot/pop3.log > > why? > >> Is there a way auth-worker can be made to log warn|error instead of >> info? >> >> Constantly 1/5th of the log file is filled with auth-work info >> connecting to mysql socket, which we do not need to see unless, well, >> we need to see it either via debug, or if there is a problem, I know >> this can be done from syslog, but we prefer not to use syslog, and the >> wiki does not indicate it can be done? > > but that is exactly why syslog exists instead re-invent the wheel > > [root@mail:~]$ cat /etc/rsyslog.conf | grep database > :msg, contains, "Connected to database dbmail" ~ > >
Re: [Dovecot] Reduce logging auth-worker
Am 23.03.2013 02:31, schrieb Nick Edwards: > Hello Timo > > We would like to reduce the logging by increasing severity, we don't > use syslog since we use > > log_path = /var/log/dovecot/pop3.log why? > Is there a way auth-worker can be made to log warn|error instead of info? > > Constantly 1/5th of the log file is filled with auth-work info > connecting to mysql socket, which we do not need to see unless, well, > we need to see it either via debug, or if there is a problem, I know > this can be done from syslog, but we prefer not to use syslog, and the > wiki does not indicate it can be done? but that is exactly why syslog exists instead re-invent the wheel [root@mail:~]$ cat /etc/rsyslog.conf | grep database :msg, contains, "Connected to database dbmail" ~ signature.asc Description: OpenPGP digital signature
[Dovecot] Reduce logging auth-worker
Hello Timo We would like to reduce the logging by increasing severity, we don't use syslog since we use log_path = /var/log/dovecot/pop3.log Is there a way auth-worker can be made to log warn|error instead of info? Constantly 1/5th of the log file is filled with auth-work info connecting to mysql socket, which we do not need to see unless, well, we need to see it either via debug, or if there is a problem, I know this can be done from syslog, but we prefer not to use syslog, and the wiki does not indicate it can be done? Niki
Re: [Dovecot] discarding vacation response for message implicitly delivered
On 3/22/13 12:23 AM, dove...@noboost.org wrote: Challenge: Does anyone have an explination regarding this message? --- "Mar 22 12:15:22 chtvm dovecot: lmtp(7004, cht): C+EZBuObS1FcGwAAlnPEfg: sieve: msgid=<20130322011522.6d55d40...@chtvm.noboost.org>: discarding vacation response for message implicitly delivered to " --- It seems like Postfix is stripping the domain from the destination address. The envelope address (reduced to just "cht" as LMTP receives it), needs to be among the recipients in the headers. it's not, so Dovecot assumes "cht" was a BCC recipient and suppresses the vacation response.
[Dovecot] Dovecot 2.2, Thunderbird And Client Certificates -> Login fails
Hello,
I stucked in Thunderbird authentication with X.509 client certs.
This is my config (dovecot -n):
$ /opt/dovecot/sbin/dovecot -n
# 2.2.rc3: /opt/dovecot-2.2.rc3/etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-amd64 x86_64 Debian 7.0
auth_debug = yes
auth_ssl_require_client_cert = yes
auth_ssl_username_from_cert = yes
auth_verbose = yes
base_dir = /home/dovecot/
hostname = mail.ip6.li
instance_name = dovecot-01
lda_mailbox_autocreate = yes
mail_gid = dovecot
mail_uid = dovecot
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 {
list = children
location = maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u
prefix = shared/%%u/
separator = /
subscriptions = no
type = shared
}
namespace inbox {
inbox = yes
location =
mailbox Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix =
separator = /
type = private
}
passdb {
args = scheme=CRYPT username_format=%u
/opt/dovecot/etc/dovecot/mailusers.993
driver = passwd-file
}
plugin {
acl = vfile:/etc/dovecot/global-acls:cache_secs=300
acl_shared_dict = file:/home/dovecot/shared-mailboxes
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
postmaster_address = postmas...@ip6.li
protocols = imap pop3 lmtp sieve
quota_full_tempfail = yes
sendmail_path = /usr/lib/sendmail
service managesieve-login {
inet_listener sieve {
port = 4190
}
inet_listener sieve_deprecated {
port = 2000
}
}
ssl_ca = , rip=192.168.200.6, lip=192.168.200.22,
TLS, session=
seems client cert is ok, but Dovecot does not like Thunderbirds method
to handle TLS-Cert login w/o username and password.
Hint http://dovecot.org/list/dovecot/2012-December/069771.html does not
seem to be valid for Dovecot 2.2
On the other hand I think it is not a suitable method to include CRLs
into CA file. Certificate should include a link to CRL or - better - an
URL to OCSP. Does Dovecot support OCSP?
best regards
Christian
Re: [Dovecot] Migarting password scheme
On 21/03/2013 17:39, Timo Sirainen wrote: > userdb_plain_pass method requires that you use userdb prefetch. And > Daryl's method of using %w in regular userdb .. I'm not really sure > how well that works. Could easily be that different Dovecot versions > behave differently. So, basically what I am doing may fail at any time? Guess it's time to go play with config. BTW, I'm using 2.1.15 so it still works there...
Re: [Dovecot] Altmove doesn't working after a dsync.
Timo, I updated my dovecot to 2.2.rc3 (b436c1f6bd06) but the problem still happens. There is some info that I can send you to clarify the problem? Thanks, On Fri, Mar 22, 2013 at 11:43 AM, Timo Sirainen wrote: > On Fri, 2013-03-22 at 11:36 -0300, Breno Moreira wrote: > > > The most strange thing is that even if I use the filter ALL, the emails > are > > not moved. > > Sounds like a bug. Before wondering about it further, try upgrading to > v2.1.15. I remember some versions having bugs related to altmoving. > > > Just for example, using my test user I get the following logs: > > > > root@mail0:~/# doveadm -Dv altmove -u te...@supramail.com.br all > > doveadm(root): Debug: Loading modules from directory: > > /usr/lib/dovecot/modules > > doveadm(root): Debug: Module loaded: > > /usr/lib/dovecot/modules/lib10_quota_plugin.so > > doveadm(root): Debug: Loading modules from directory: > > /usr/lib/dovecot/modules/doveadm > > doveadm(root): Debug: Skipping module doveadm_acl_plugin, because > dlopen() > > failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: > > undefined symbol: acl_user_module (this is usually intentional, so just > > ignore this message) > > doveadm(root): Debug: Skipping module doveadm_expire_plugin, because > > dlopen() failed: > > /usr/lib/dovecot/modules/doveadm/lib10_doveadm_expire_plugin.so: > undefined > > symbol: expire_set_deinit (this is usually intentional, so just ignore > this > > message) > > doveadm(root): Debug: Module loaded: > > /usr/lib/dovecot/modules/doveadm/lib10_doveadm_quota_plugin.so > > doveadm(root): Debug: Skipping module doveadm_zlib_plugin, because > dlopen() > > failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_zlib_plugin.so: > > undefined symbol: i_stream_create_deflate (this is usually intentional, > so > > just ignore this message) > > doveadm(root): Debug: Skipping module doveadm_fts_plugin, because > dlopen() > > failed: /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_plugin.so: > > undefined symbol: fts_backend_rescan (this is usually intentional, so > just > > ignore this message) > > doveadm(te...@supramail.com.br): Debug: Added userdb setting: > > mail=sdbox:~/:ALT=/mnt/hd/dovecot/supramail.com.br/teste > > doveadm(te...@supramail.com.br): Debug: Effective uid=5000, gid=5000, > > home=/mnt/ssd/dovecot/supramail.com.br/teste > > doveadm(te...@supramail.com.br): Debug: Quota root: name=Quota > > backend=maildir args= > > doveadm(te...@supramail.com.br): Debug: fs: root=/mnt/ssd/dovecot/ > > supramail.com.br/teste, index=, control=, inbox=, alt=/mnt/hd/dovecot/ > > supramail.com.br/teste > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=1 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=2 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=3 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=4 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=5 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=6 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=7 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=8 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=9 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=10 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=11 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=12 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=13 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=14 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=15 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=16 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=17 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=18 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=19 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=20 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=21 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=22 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=23 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=24 > > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=25 > > doveadm(te...@supramail.com.br): Debug: altmove: box=Sent uid=1 > > > > And the fetch of the saved date is: > > > > root@mail0:~/# doveadm -Dv fetch -u te...@supramail.com.br date.saved > > mailbox inbox all > > date.saved: 2012-10-31 23:53:35 > > date.saved: 2012-10-31 23:53:35 > > date.saved: 2012-10-31 23:53:35 > > date.saved: 2012-10-31 23:53:35 > > date.saved: 2012-10-31 23:53:35 > > date.saved: 2012-10-31 23:53:35 > > date.saved: 2012-10-31 23:53:35 > > date.saved: 2012-10-31 23:53:35 > > date.saved: 2012-10-31 23:53:35 > > date.saved: 2012-10-31 23:53:36 > > date.saved: 2012-10-31 23:53:37 > > date.saved: 2012-10-31 23:53:37 >
Re: [Dovecot] v2.2 getting NULL pointer reference with shared namespace in mailbox_tree?
> You most likely want to have subscriptions=no for your shared namespace. Also > you most likely want to enable ACL plugin. Yes - thank you for your comment! The ACLs I had configured before are not enabled in this minimalistic configuration because of crashes when running doveadm backup -R ... imapc: with ACLs enabled. You wrote that you are continuing debugging "my problem". Regardless of this, should I investigate / file this ACL (related) bug? With todays nightly: dsync(wsunp...@iai.uni-bonn.de): Debug: acl: initializing backend with data: vfile:/m/d/etc/acl:cache_secs=300 dsync(wsunp...@iai.uni-bonn.de): Debug: acl: acl username = wsunp...@iai.uni-bonn.de dsync(wsunp...@iai.uni-bonn.de): Debug: acl: owner = 0 dsync(wsunp...@iai.uni-bonn.de): Debug: acl vfile: Global ACL directory: /m/d/etc/acl dsync(wsunp...@iai.uni-bonn.de): Debug: brain M: in state=recv_handshake dsync(wsunp...@iai.uni-bonn.de): Debug: brain M: out state=send_mailbox_tree_deletes changed=1 dsync(wsunp...@iai.uni-bonn.de): Panic: file imapc-list.c: line 199 (imapc_list_get_vname): assertion failed: (strncmp(prefix, storage_name, prefix_len) == 0 && storage_name[prefix_len] == list->sep) dsync(wsunp...@iai.uni-bonn.de): Error: Raw backtrace: /m/sw/dc/2.2-20130322/lib/dovecot/libdovecot.so.0.0.0'default_fatal_finish+0x26 [0xffff80ffb60c4d34] -> /m/sw/dc/2.2-20130322/lib/dovecot/libdovecot.so.0.0.0'default_error_handler+0x0 [0xffff80ffb60c4dc3] -> /m/sw/dc/2.2-20130322/lib/dovecot/libdovecot.so.0.0.0'i_fatal+0x0 [0x80ffb60c50a4] -> /m/sw/dc/2.2-20130322/lib/dovecot/libdovecot-storage.so.0.0.0'imapc_list_get_vname+0xdb [0x80ffb5f4c4ce] -> /m/sw/dc/2.2-20130322/lib/dovecot/libdovecot-storage.so.0.0.0'mailbox_list_get_vname+0x28 [0x80ffb5f75ebb] -> /m/sw/dc/2.2-20130322/lib/dovecot/lib01_acl_plugin.so'acl_backend_vfile_object_init+0x92 [0x80ffb5e3d0fa] -> /m/sw/dc/2.2-20130322/lib/dovecot/lib01_acl_plugin.so'acl_object_init_from_name+0x2b [0x80ffb5e3ad88] -> /m/sw/dc/2.2-20130322/lib/dovecot/lib01_acl_plugin.so'acl_backend_get_default_rights+0x30 [0x80ffb5e3c9b4] -> /m/sw/dc/2.2-20130322/lib/dovecot/lib01_acl_plugin.so'acl_mailbox_try_list_fast+0xb2 [0x80ffb5e44b77] -> /m/sw/dc/2.2-20130322/lib/dovecot/lib01_acl_plugin.so'acl_mailbox_list_iter_init+0x188 [0x80ffb5e44efa] -> /m/sw/dc/2.2-20130322/lib/dovecot/libdovecot-storage.so.0.0.0'mailbox_list_iter_init_multiple+0x91 [0x80ffb5f8aa20] -> /m/sw/dc/2.2-20130322/lib/dovecot/libdovecot-storage.so.0.0.0'mailbox_list_iter_init+0x39 [0xffff80ffb5f8a596] -> /m/sw/dc/2.2-20130322/bin/doveadm'dsync_mailbox_tree_fill+0x103 [0x456acf] -> /m/sw/dc/2.2-20130322/bin/doveadm'dsync_brain_mailbox_trees_init+0x114 [0x449f74] -> /m/sw/dc/2.2-20130322/bin/doveadm'dsync_brain_slave_recv_handshake+0x18d [0x447703] -> /m/sw/dc/2.2-20130322/bin/doveadm'dsync_brain_run_real+0xe7 [0x447a4c] -> /m/sw/dc/2.2-20130322/bin/doveadm'dsync_brain_run+0x61 [0x447bf6] -> /m/sw/dc/2.2-20130322/bin/doveadm'cmd_dsync_run_local+0x325 [0x444b1e] -> /m/sw/dc/2.2-20130322/bin/doveadm'cmd_dsync_run+0x272 [0x445156] -> /m/sw/dc/2.2-20130322/bin/doveadm'doveadm_mail_next_user+0x189 [0x4294ba] -> /m/sw/dc/2.2-20130322/bin/doveadm'doveadm_mail_single_user+0x157 [0x429680] -> /m/sw/dc/2.2-20130322/bin/doveadm'doveadm_mail_cmd+0x3bc [0x429f24] -> /m/sw/dc/2.2-20130322/bin/doveadm'doveadm_mail_try_run+0xac [0x42a19b] -> /m/sw/dc/2.2-20130322/bin/doveadm'main+0x286 [0x4342b7] -> /m/sw/dc/2.2-20130322/bin/doveadm'_start+0x6c [0x428a8c] Abort (core dumped)
Re: [Dovecot] v2.2 getting NULL pointer reference with shared namespace in mailbox_tree?
On 22.3.2013, at 17.29, Walter Steiner wrote: >> I can't seem to be able to reproduce this. What's in the user's >> subscriptions file? > > Did some doveadm mailbox (un)subscribe -u ... > > If the file subscriptions in the mailbox of this user is > > a) > empty > => crash Oh, figured out the crash: http://hg.dovecot.org/dovecot-2.2/rev/6f5b14d4ad56 You most likely want to have subscriptions=no for your shared namespace. Also you most likely want to enable ACL plugin. > b) > user.otherexistinguser.existingfolder > => crash Note that this should be user/otherexistinguser/existingfolder
Re: [Dovecot] v2.2 getting NULL pointer reference with shared namespace in mailbox_tree?
> I can't seem to be able to reproduce this. What's in the user's subscriptions > file? Did some doveadm mailbox (un)subscribe -u ... If the file subscriptions in the mailbox of this user is a) empty => crash b) user.otherexistinguser.existingfolder => crash c) user.other... INBOX => okay d) INBOX => okay d) test => okay It seems that with an active shared namespace one needs to have at least one folder in the private namespace in this file. With no shared namespace the list may be empty. (the client did not automatically subscribe to mailboxes (before the lsub))
Re: [Dovecot] v2.2 getting NULL pointer reference with shared namespace in mailbox_tree?
On 22.3.2013, at 16.35, Walter Steiner wrote: > I stumbled over another segmentation fault: .. > . lsub "" * > Segmentation fault (core dumped) I can't seem to be able to reproduce this. What's in the user's subscriptions file? > I'm not familiar with gdb / debugging. gdb bt full is following but I'm > afraid line numbers are not yet correct, are they? Yeah, for some reason they're wrong.
Re: [Dovecot] Altmove doesn't working after a dsync.
On Fri, 2013-03-22 at 11:36 -0300, Breno Moreira wrote: > The most strange thing is that even if I use the filter ALL, the emails are > not moved. Sounds like a bug. Before wondering about it further, try upgrading to v2.1.15. I remember some versions having bugs related to altmoving. > Just for example, using my test user I get the following logs: > > root@mail0:~/# doveadm -Dv altmove -u te...@supramail.com.br all > doveadm(root): Debug: Loading modules from directory: > /usr/lib/dovecot/modules > doveadm(root): Debug: Module loaded: > /usr/lib/dovecot/modules/lib10_quota_plugin.so > doveadm(root): Debug: Loading modules from directory: > /usr/lib/dovecot/modules/doveadm > doveadm(root): Debug: Skipping module doveadm_acl_plugin, because dlopen() > failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: > undefined symbol: acl_user_module (this is usually intentional, so just > ignore this message) > doveadm(root): Debug: Skipping module doveadm_expire_plugin, because > dlopen() failed: > /usr/lib/dovecot/modules/doveadm/lib10_doveadm_expire_plugin.so: undefined > symbol: expire_set_deinit (this is usually intentional, so just ignore this > message) > doveadm(root): Debug: Module loaded: > /usr/lib/dovecot/modules/doveadm/lib10_doveadm_quota_plugin.so > doveadm(root): Debug: Skipping module doveadm_zlib_plugin, because dlopen() > failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_zlib_plugin.so: > undefined symbol: i_stream_create_deflate (this is usually intentional, so > just ignore this message) > doveadm(root): Debug: Skipping module doveadm_fts_plugin, because dlopen() > failed: /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_plugin.so: > undefined symbol: fts_backend_rescan (this is usually intentional, so just > ignore this message) > doveadm(te...@supramail.com.br): Debug: Added userdb setting: > mail=sdbox:~/:ALT=/mnt/hd/dovecot/supramail.com.br/teste > doveadm(te...@supramail.com.br): Debug: Effective uid=5000, gid=5000, > home=/mnt/ssd/dovecot/supramail.com.br/teste > doveadm(te...@supramail.com.br): Debug: Quota root: name=Quota > backend=maildir args= > doveadm(te...@supramail.com.br): Debug: fs: root=/mnt/ssd/dovecot/ > supramail.com.br/teste, index=, control=, inbox=, alt=/mnt/hd/dovecot/ > supramail.com.br/teste > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=1 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=2 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=3 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=4 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=5 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=6 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=7 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=8 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=9 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=10 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=11 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=12 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=13 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=14 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=15 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=16 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=17 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=18 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=19 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=20 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=21 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=22 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=23 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=24 > doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=25 > doveadm(te...@supramail.com.br): Debug: altmove: box=Sent uid=1 > > And the fetch of the saved date is: > > root@mail0:~/# doveadm -Dv fetch -u te...@supramail.com.br date.saved > mailbox inbox all > date.saved: 2012-10-31 23:53:35 > date.saved: 2012-10-31 23:53:35 > date.saved: 2012-10-31 23:53:35 > date.saved: 2012-10-31 23:53:35 > date.saved: 2012-10-31 23:53:35 > date.saved: 2012-10-31 23:53:35 > date.saved: 2012-10-31 23:53:35 > date.saved: 2012-10-31 23:53:35 > date.saved: 2012-10-31 23:53:35 > date.saved: 2012-10-31 23:53:36 > date.saved: 2012-10-31 23:53:37 > date.saved: 2012-10-31 23:53:37 > date.saved: 2012-10-31 23:53:38 > date.saved: 2012-10-31 23:53:39 > date.saved: 2012-10-31 23:53:39 > date.saved: 2012-10-31 23:53:39 > date.saved: 2012-10-31 23:53:39 > date.saved: 2012-10-31 23:53:40 > date.saved: 2012-10-31 23:53:40 > date.saved: 2012-10-31 23:53:40 > date.saved: 2012-10-31 23:53:40 > date.saved: 2012-10-31 23:53:41 > date.saved: 2013-01-04 11:28:02 > date.saved: 2013-01-17 15:3
Re: [Dovecot] Altmove doesn't working after a dsync.
Timo, The most strange thing is that even if I use the filter ALL, the emails are not moved. Just for example, using my test user I get the following logs: root@mail0:~/# doveadm -Dv altmove -u te...@supramail.com.br all doveadm(root): Debug: Loading modules from directory: /usr/lib/dovecot/modules doveadm(root): Debug: Module loaded: /usr/lib/dovecot/modules/lib10_quota_plugin.so doveadm(root): Debug: Loading modules from directory: /usr/lib/dovecot/modules/doveadm doveadm(root): Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: undefined symbol: acl_user_module (this is usually intentional, so just ignore this message) doveadm(root): Debug: Skipping module doveadm_expire_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_expire_plugin.so: undefined symbol: expire_set_deinit (this is usually intentional, so just ignore this message) doveadm(root): Debug: Module loaded: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_quota_plugin.so doveadm(root): Debug: Skipping module doveadm_zlib_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_zlib_plugin.so: undefined symbol: i_stream_create_deflate (this is usually intentional, so just ignore this message) doveadm(root): Debug: Skipping module doveadm_fts_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_plugin.so: undefined symbol: fts_backend_rescan (this is usually intentional, so just ignore this message) doveadm(te...@supramail.com.br): Debug: Added userdb setting: mail=sdbox:~/:ALT=/mnt/hd/dovecot/supramail.com.br/teste doveadm(te...@supramail.com.br): Debug: Effective uid=5000, gid=5000, home=/mnt/ssd/dovecot/supramail.com.br/teste doveadm(te...@supramail.com.br): Debug: Quota root: name=Quota backend=maildir args= doveadm(te...@supramail.com.br): Debug: fs: root=/mnt/ssd/dovecot/ supramail.com.br/teste, index=, control=, inbox=, alt=/mnt/hd/dovecot/ supramail.com.br/teste doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=1 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=2 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=3 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=4 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=5 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=6 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=7 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=8 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=9 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=10 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=11 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=12 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=13 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=14 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=15 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=16 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=17 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=18 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=19 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=20 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=21 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=22 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=23 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=24 doveadm(te...@supramail.com.br): Debug: altmove: box=INBOX uid=25 doveadm(te...@supramail.com.br): Debug: altmove: box=Sent uid=1 And the fetch of the saved date is: root@mail0:~/# doveadm -Dv fetch -u te...@supramail.com.br date.saved mailbox inbox all date.saved: 2012-10-31 23:53:35 date.saved: 2012-10-31 23:53:35 date.saved: 2012-10-31 23:53:35 date.saved: 2012-10-31 23:53:35 date.saved: 2012-10-31 23:53:35 date.saved: 2012-10-31 23:53:35 date.saved: 2012-10-31 23:53:35 date.saved: 2012-10-31 23:53:35 date.saved: 2012-10-31 23:53:35 date.saved: 2012-10-31 23:53:36 date.saved: 2012-10-31 23:53:37 date.saved: 2012-10-31 23:53:37 date.saved: 2012-10-31 23:53:38 date.saved: 2012-10-31 23:53:39 date.saved: 2012-10-31 23:53:39 date.saved: 2012-10-31 23:53:39 date.saved: 2012-10-31 23:53:39 date.saved: 2012-10-31 23:53:40 date.saved: 2012-10-31 23:53:40 date.saved: 2012-10-31 23:53:40 date.saved: 2012-10-31 23:53:40 date.saved: 2012-10-31 23:53:41 date.saved: 2013-01-04 11:28:02 date.saved: 2013-01-17 15:38:39 date.saved: 2013-03-07 11:44:18 Thanks for your help, Breno Moreira On Thu, Mar 21, 2013 at 6:41 PM, Timo Sirainen wrote: > I guess the save date gets reset. You can verify that with e.g.: > > doveadm fetch date.saved mailbox inbox all > > dsync is supposed to preserve the save date though. Might be broken in > your version. > > On 21.3.2013, at 22.59, Breno Moreira
[Dovecot] v2.2 getting NULL pointer reference with shared namespace in mailbox_tree?
I stumbled over another segmentation fault:
# /m/sw/dc/a/libexec/dovecot/imap -u cyrtest1
Debug: Loading modules from directory: /m/sw/dc/2.2-20130322/lib/dovecot
Debug: Module loaded: /m/sw/dc/2.2-20130322/lib/dovecot/lib15_notify_plugin.so
Debug: Module loaded: /m/sw/dc/2.2-20130322/lib/dovecot/lib20_mail_log_plugin.so
Debug: auth input: cyrte...@iai.uni-bonn.de uid=13004 gid=13004
home=/m/d/user/cyrtest1
Debug: changed username to cyrte...@iai.uni-bonn.de
Debug: Effective uid=13004, gid=13004, home=/m/d/user/cyrtest1
Debug: Namespace inbox: type=private, prefix=, sep=/, inbox=yes, hidden=no,
list=yes, subscriptions=yes location=sdbox:/m/d/imap/mbox/m/cyrtest1
Debug: fs: root=/m/d/imap/mbox/m/cyrtest1, index=, indexpvt=, control=, inbox=,
alt=
Debug: Namespace user: type=shared, prefix=user/%u/, sep=/, inbox=no,
hidden=no, list=children, subscriptions=yes location=sdbox:/m/d/imap/mbox/m/%n
Debug: shared: root=/var/run/dovecot/, index=, indexpvt=, control=, inbox=, alt=
* PREAUTH [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE
SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT
MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS
LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN
CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE] Logged in as
cyrte...@iai.uni-bonn.de
. namespace
* NAMESPACE (("" "/")) (("user/" "/")) NIL
. OK Namespace completed.
. lsub "" *
Segmentation fault (core dumped)
I'm not familiar with gdb / debugging. gdb bt full is following but I'm
afraid line numbers are not yet correct, are they?
Compiler is gcc 4.5.2
output of make command while building dovecot does not show "-O"...
(also tried "-O0" before ... as mentioned on some web pages)
file src/lib-storage/mailbox-tree.c
function mailbox_tree_traverse()
line number 103:
for (name = path;; path++) {
if (*path != tree->separator && *path != '\0')
^^^ and tree is 0x0
#0 0x80ffb73d91cb in mailbox_tree_traverse (tree=0x0, path=0x472830
"user", create=false, created_r=0x80ffb187) at mailbox-tree.c:41
41 i_assert(mailbox_node_size >= sizeof(struct mailbox_node));
(gdb) bt full
#0 0x80ffb73d91cb in mailbox_tree_traverse (tree=0x0, path=0x472830
"user", create=false, created_r=0x80ffb187) at mailbox-tree.c:41
node = (struct mailbox_node **) 0x10
parent = (struct mailbox_node *) 0x0
name = 0x472830 "user"
str = (string_t *) 0x44d658
#1 0x80ffb73d9417 in mailbox_tree_lookup (tree=0x0, path=0x472830 "user")
at mailbox-tree.c:41
_data_stack_cur_id = 5
node = (struct mailbox_node *) 0x0
created = false
#2 0x80ffb73f01c6 in mailbox_list_set_subscription_flags (list=0x46c4d0,
vname=0x472830 "user", flags=0x4725e8) at mailbox-list-subscriptions.c:47
node = (struct mailbox_node *) 0x80ffbf760030
#3 0x80ffb73eb4bc in mailbox_list_ns_prefix_return (ctx=0x472540,
ns=0x46c400, has_children=false) at mailbox-list-iter.c:98
subs_ns = (struct mail_namespace *) 0x46c400
box = (struct mailbox *) 0x80ffb73ecae8
existence = 4294934783
ret = 0
__FUNCTION__ = "mailbox_list_ns_prefix_return"
#4 0x80ffb73eb9d8 in mailbox_list_ns_iter_try_next (_ctx=0x472540,
info_r=0x80ffb2c8) at mailbox-list-iter.c:98
ctx = (struct ns_list_iterate_context *) 0x472540
ns = (struct mail_namespace *) 0x3
info = (const struct mailbox_info *) 0x0
error = MAIL_ERROR_NONE
errstr = 0x472540 "(&G"
has_children = false
__FUNCTION__ = "mailbox_list_ns_iter_try_next"
#5 0x80ffb73ebb8d in mailbox_list_ns_iter_next (_ctx=0x472540) at
mailbox-list-iter.c:98
info = (const struct mailbox_info *) 0x0
#6 0x80ffb73ec7f7 in mailbox_list_iter_next_call (ctx=0x472540) at
mailbox-list-iter.c:98
info = (const struct mailbox_info *) 0x63207361206e6920
set = (const struct mailbox_settings *) 0x646567676f4c205d
#7 0x80ffb73ecad8 in mailbox_list_iter_next (ctx=0x472540) at
mailbox-list-iter.c:98
_data_stack_cur_id = 4
info = (const struct mailbox_info *) 0x80ffbf770030
#8 0x0041ac70 in cmd_list_continue (cmd=0x46d900) at
../../src/lib/array.h:197
ctx = (struct cmd_list_context *) 0x46d9f8
info = (const struct mailbox_info *) 0x41ae1a
flags = 0
str = (string_t *) 0x44d410
mutf7_name = (string_t *) 0x44d560
name = 0x80ffb3a0 "0ôÿ¿ÿ\200ÿÿ!µA"
ret = 0
#9 0x0041b521 in cmd_list_full (cmd=0x46d900, lsub=true) at
../../src/lib/array.h:197
client = (struct client *) 0x46d0f
Re: [Dovecot] sieve-filter ignoring separator
Stephan Bosch-2 wrote > On 3/4/2013 9:21 PM, Isak Rubin wrote: >> >> # dovecot --version >> 2.1.9 > > This Dovecot is very old, so is probably your Pigeonhole version. Recent > versions should work fine in this regard. > > Regards, > > Stephan. Upgraded to # dovecot --version 2.2.rc3 still same issue :/ -- View this message in context: http://dovecot.2317879.n4.nabble.com/sieve-filter-ignoring-separator-tp40612p41000.html Sent from the Dovecot mailing list archive at Nabble.com.
Re: [Dovecot] Migarting password scheme
Zitat von Timo Sirainen : On 21.3.2013, at 18.51, lst_ho...@kwsoft.de wrote: Hello, by the move to Dovecot we try to alter the password encryption stored in the database from MD5 to CRYPT-SHA256 along the Guide at http://wiki2.dovecot.org/HowTo/ConvertPasswordSchemes. It's mostly working but i still have not found out how to pass the cleartext password to the re-encrypting script. According to the HowTo it should be enough to add "'%w' AS userdb_plain_pass" to the passdb query, to get a environment variable $PLAIN_PASS in the post-login script to pass along. This does not work eg. PLAIN_PASS is always empty. This is Dovecot 2.0.19 from Ubuntu 12.04 LTS. userdb_plain_pass method requires that you use userdb prefetch. And Daryl's method of using %w in regular userdb .. I'm not really sure how well that works. Could easily be that different Dovecot versions behave differently. Hello, with "userdb prefetch" it works. Sorry it was not clear to me that userdb prefetch *must* be used to get *this* userdb setting to work. Maybe it should be listed at http://wiki2.dovecot.org/HowTo/ConvertPasswordSchemes. Furthermore the example listed there does a migration from CRYPT to SHA256 (salted) but not CRYPT-SHA256 which is recommended, no? Regards Andreas
[Dovecot] How do I enable dsync sieve script replication?
Hi all,
Thank you Timo for adding sieve script replication to dsync, much
appreciated! Should this run out of the box with 2.2.rc3 and latest
pigeonhole+patch or does this have to be enabled in the configuration
somehow?
I upgraded my dsync replication test setup, but it doesn't sync sieve
so far, so I'm not sure if this is a config issue or if I maybe made a
mistake while upgrading/patching.
btw: not sure if you saw this bugreport, dsync over tcp still produces
"no command given" errors randomly
(http://www.dovecot.org/list/dovecot/2013-March/088751.html)
Thanks
Oli
#dovecot -n:
# 2.2.rc3: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-279.22.1.el6.x86_64 x86_64 CentOS release 6.3 (Final)
auth_master_user_separator = *
auth_mechanisms = plain login
dict {
acl = mysql:/etc/dovecot/dovecot-dict-shares.conf
quotadict = mysql:/etc/dovecot/dovecot-dict-quota.conf
}
disable_plaintext_auth = no
doveadm_password =
listen = *
login_greeting = Dovecot ready.
mail_max_userip_connections = 50
mail_plugins = " quota notify replication"
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
namespace {
list = children
location = maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u
prefix = shared/%%u/
separator = /
subscriptions = no
type = shared
}
namespace inbox {
inbox = yes
location =
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
mailbox Spam {
auto = subscribe
special_use = \Junk
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
prefix =
separator = /
type = private
}
passdb {
args = /etc/dovecot/dovecot-sql.conf
driver = sql
}
plugin {
acl = vfile:/etc/dovecot/acls
acl_shared_dict = proxy::acl
mail_replica = tcp::1337
quota = dict:::proxy::quotadict
quota_rule = *:storage=10M:messages=1000
quota_rule2 = Spam:ignore
quota_rule3 = Trash:storage=+100M
quota_warning = storage=95%% quota-warning 95 %u
quota_warning2 = storage=75%% quota-warning 75 %u
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
protocols = pop3 imap lmtp sieve
service aggregator {
fifo_listener replication-notify-fifo {
user = fumail
}
unix_listener replication-notify {
user = fumail
}
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
unix_listener auth-master {
group = fumail
mode = 0660
user = fumail
}
user = root
}
service dict {
unix_listener dict {
mode = 0600
user = fumail
}
}
service doveadm {
inet_listener {
port = 1337
}
}
service imap {
vsz_limit = 2 G
}
service lmtp {
inet_listener lmtp {
address = 127.0.0.1
port = 24
}
process_min_avail = 5
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0660
user = postfix
}
}
s
Re: [Dovecot] v2.2 dsync_brain_lock() FLOCK compatibility issue on Solaris 11.1
On 22.3.2013, at 12.02, Walter Steiner wrote:
> is a (maybe unintentional) fix reference to FLOCK locks.
>
>
>if (file_wait_lock(brain->lock_fd, brain->lock_path, F_WRLCK,
> FILE_LOCK_METHOD_FLOCK, brain->lock_timeout,
> &brain->lock) <= 0) {
I'm not sure why I used flock instead of fcntl lock. Maybe by accident.
Switched: http://hg.dovecot.org/dovecot-2.2/rev/b436c1f6bd06
Re: [Dovecot] Problem with Prefetch User Database
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 21 Mar 2013, mego...@inboxalias.com wrote: > Dovecot only sees the PAM-authentication part) PAM does not return userdb-relevant information. You cannot use userdb prefetch. You could switch to first ask a ldap passdb and then, for users that have another password in LDAP, pam. I use PAM because of the easyness of blocking specific validated users - you can just add/remove them in a plain text file. Easy administration will be necessary because of the planned huge amount of users on the system (28.000), and sometimes blocking a user is highly time-dependent (e.g. if one answers to a phising mail and sending out his credentials which are then abused for sending spam). I would go over LDAP if there is an equivalent easy way to solve this over LDAP (easy blocking out users by e.g editing a plain text file) - is there any? Ah: http://wiki2.dovecot.org/Authentication/RestrictAccess?highlight=(deny) check out section about passwd-file Other alternative: Add into your passdb LDAP filter: (&(..)(!(dovecotUserDenied=*))) Then add the attribute dovecotUserDenied with any content to deny that user. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEVAwUBUUwzOl3r2wJMiz2NAQJdeggAhxDhio9AUqDomoyjnRg6F2akRq26tFvL 4bG2O4qASIWEyAv232vU5zUX7/EmKWoGbBw6T/Ep3NVrzLNCPzxXi6aMjcd18ZsH z65bk/cgrwFzMjWXacQ+L//clmXSb7buZp6DiMTMfVWMWv5TkJa0u6fio9PQlTGT Fmi4RBnCozwK8SaiEZmXW6fd+Tdjy60NUk80huIngwviwaAnC3EFrv2IO6nCFbOJ PmFbxRDMD0j9+5Vbudea2ZmzYSpLOPzk1kCVFNrGVzAT2dtrishmnc2kv90FkbDt jJN/MUyCIL//zELDY3N73vjaDzpb+RQrp3eUfovS6xApbaGN1rtWqA== =2a5e -END PGP SIGNATURE-
[Dovecot] v2.2 dsync_brain_lock() FLOCK compatibility issue on Solaris 11.1
Hello,
On Oracle Solaris 11.1 (Solaris gcc-45 package set)
core libraries do not provide flock() anymore.
in file: src/doveadm/dsync/dsync-brain.c
in function: dsync_brain_lock()
around line: 234
is a (maybe unintentional) fix reference to FLOCK locks.
if (file_wait_lock(brain->lock_fd, brain->lock_path, F_WRLCK,
FILE_LOCK_METHOD_FLOCK, brain->lock_timeout,
&brain->lock) <= 0) {
resulting in a runtime error about unsupported flock() locks.
(HAVE_FLOCK is not set by configure script)
Personally, I have just changed "FLOCK" to "FCNTL".
[ I have tried brain->lock->lock_method but this seems not to be the correct way
=> compile time error: dereferencing pointer to incomplete type ]
Walter
Re: [Dovecot] Postfix/Dovecot/lmtp with virtual and local users
Timo Sirainen schrieb am 22.03.2013 09:48:
> Maybe. Depends on your Dovecot version and passdb/userdb
> configuration. So, doveconf -n output?
I use version 2.1.7 from the backports repo on Debian Squeeze.
My doveconf -n:
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 2.6.32-5-686-bigmem i686 Debian 6.0.7
auth_cache_size = 10 M
auth_debug = yes
auth_mechanisms = plain login digest-md5
auth_socket_path = /var/run/dovecot/auth-userdb
auth_verbose = yes
auth_verbose_passwords = sha1
base_dir = /var/run/dovecot/
disable_plaintext_auth = no
first_valid_uid = 105
listen = *
log_timestamp = "%Y-%m-%d %H:%M:%S "
login_log_format_elements = user=<%u> method=%m rip=%r lip=%l mpid=%e %c
mail_location = maildir:~/Maildir
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 Drafts {
special_use = \Drafts
}
mailbox Junk {
special_use = \Junk
}
mailbox Sent {
special_use = \Sent
}
mailbox "Sent Messages" {
special_use = \Sent
}
mailbox Trash {
special_use = \Trash
}
prefix = INBOX.
separator = .
type = private
}
passdb {
args = /etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
passdb {
driver = pam
}
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
sieve_global_dir =
}
protocols = " imap lmtp sieve pop3"
service auth {
unix_listener /var/spool/postfix/private/auth {
mode = 0666
}
}
service imap-login {
inet_listener imap {
address = localhost
port = 999
}
inet_listener imaps {
port = 993
ssl = yes
}
service_count = 1
}
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
group = postfix
mode = 0660
user = postfix
}
}
ssl_ca =
Re: [Dovecot] Postfix/Dovecot/lmtp with virtual and local users
On Thu, 2013-03-21 at 15:10 +0100, David Obando wrote: > Is there a way to define "if is local then auth_username_format = > %n else auth_username_format = %Lu"? Maybe. Depends on your Dovecot version and passdb/userdb configuration. So, doveconf -n output?
Re: [Dovecot] Disallow POP3 from deleting messages
On Wed, 2013-03-20 at 17:40 -0600, dormitionsk...@hotmail.com wrote: > On Mar 20, 2013, at 8:59 AM, Timo Sirainen wrote: > > > On Wed, 2013-03-20 at 08:15 -0600, dormitionsk...@hotmail.com wrote: > > > >> My experience with IMAP over the internet with a couple of servers outside > >> our monastery (while I was in it, and we have considerably better download > >> speeds than upload) has always been that IMAP has always been incredibly > >> slow. So, I've always just allowed users to connect to the IMAP server > >> via webmail. It's slow, but usable. > > > > Another idea: Get some cheap server from outside, use dsync replication > > to keep it synced with your internal one, and set up DNS so that users > > get directed to the fastest server. http://wiki2.dovecot.org/Replication > > > > > > I LIKE this idea, but I have a few questions about it to see if it > would be appropriate for our situation. There are a few other things > to consider that I didn't mention before because they did not seem > relevant earlier. > > First off, I'd just like to say that we have a web server set up at a > location outside of our monastery that hosts all of our websites. I'm > currently in the process of building new servers to replace both it > and our current email server. So, assuming this is both plausible for > our situation, and within my capabilities, I should be able to work on > this at my leisure, and get the initial sync of our emails done while > on the same LAN. > > So, the additional info and questions are the following: > > 1.) Our download speeds are decent enough, but in addition to having > poor upload speeds, we also have very strict limits on how much we are > able to download. And we use almost every bit of it every day. We > cannot get more, either. We have unlimited downloads for four hours > at night, however. If a delayed sync isn't a problem, you could do it only once at nights. You wouldn't need to use the replicator service at all, just run "doveadm sync -f -A -d" in a cronjob. > 2.) We have very large message archives. We basically have 95% of > the emails we've received for the past 16 years. So, the sync *must* > only update items that have been changed. Is this how it it would > work? dsync can do full sync (= all messages' metadata is sent + new messages' contents), "changed sync" (= same as full sync, but only for changed folders) or incremental sync (= only new messages' metadata + contents are sent). The incremental sync is what replicator service does while it's running, but it's still currently doing a full sync at startup. A nightly cronjob could do incremental syncing also, but it would have to run dsync separately for each user and store the sync state to some file. The "changed sync" works well enough usually, but it has a problem if both replicas have had exactly the same amount of changes it doesn't realize that there may be differences between them and skip it. > 3.) We are currently using uw-imap with mbox. If we switch to > Dovecot, using Maildir format, will the sync only update the new > messages and the header files for any folders that have been changed? It works the same with all mailbox formats. Headers and bodies aren't synced separately, but metadata (= ~100 bytes/msg maybe) is. > 4.) I thought I read somewhere in Dovecot's documentation last night > that it has a 50 mb limit on folders. It can't write anything larger > than that. Does this sound familiar? (Now I can't find it!) If so, > is that for mbox? We currently have some mbox folders whose files are > significantly larger than that. If we convert to Maildir format, > where the individual messages are in their own files, could a folder > contain messages totaling more than 50 MB using Dovecot? Dovecot has no such limit. Postfix by default has set a file size limit for 50 MB, which effectively limits mbox sizes to 50 MB, but it can be removed with Postfix mailbox_size_limit setting. > 4a. -- Oops. I just noticed this: "NOTE2: sdbox/mdbox mailbox > formats are recommended for replication. Maildir still has some issues > (although probably not noticeable in normal use)." Should I consider > this a show-stopper for syncing like this? With v2.2 I don't think there's much of a difference anymore. > 5.) In the http://wiki2.dovecot.org/Replication page, would this be > continuously synced each time a user sends, receives, deletes, or > moves messages, etc.? Or would it be periodically synced? With replicator it syncs immediately when something changes. > 6.) Also, that page does not make it clear if one server is like the > "master" and the other the "slave". Do I do the same changes to both > servers? Both servers are equal. Setup both servers exactly the same. > If, given the above additional information, it would not be an > appropriate solution for us, this suggestion about syncing the two > servers gave me another idea. > > I was thinking, "Well, I w
Re: [Dovecot] v2.2 dsync
On Wed, Mar 20, 2013 at 20:26:03 +0200, Timo Sirainen wrote: > On 20.3.2013, at 19.51, Timo Sirainen wrote: > > > On 14.3.2013, at 12.05, Walter Steiner wrote: > > > > #0 0x004578cc in dsync_ibc_send_mail_request (ibc=0x4a9f20, > > request=0x5441c0) at dsync-ibc.c:38 > > 38 return ibc->v.is_send_queue_full(ibc) ? > > > > If it crashes there, is_send_queue_full must be NULL or some other invalid > > pointer, but.. > > Oh, the function is correct but the line number is wrong. This fixes the > crash: http://hg.dovecot.org/dovecot-2.2/rev/19ce7403114f > > But I see there are other problems .. I'll continue debugging them. Timo, good to hear from you! With nightly 20130321 no more crashes at this point! Thanks a lot! (misconfigured imapc password at first try => there was another crash) doveadm backup -R -u ... imapc: => mailboxes are created and some/many messages but not all messages are copied from the origin cyrus mailbox to the dovecot box. (i.e. the first consecutive 233 out of 523 are okay) All of the missing messages are logged: => dsync(...): Error: Mailbox ...: Remote didn't send mail UID=... (references to this error seen on the list in Jan. with older versions) I do not see the reason in the cyrus protocol log. (No "NO", only "OK") Maybe it has nothing to do with the messages itself? They are all "real-life" messages - i.e. there is a mailbox with 5 messages and only the first one is okay! I have deleted this first message on the cyrus box, stopped dovecot, removed dovecot mailbox, restarted dovecot. The "same" doveadm backup results in the new first (formerly second) message backed up to the dovecot mailbox (which was not before). If more detail / logs / cyrus IMAP protocol logs would be helpful please let me know and I'll try to setup a mailbox with meaningful testmails. Thank you very much again, Walter
Re: [Dovecot] [dovecot-2.1.15] mdbox corruption, doveadm force-resync can't repair it (throws segfault)
On Thu, 2013-03-21 at 10:41 +0100, Marcin Mirosław wrote: > W dniu 20.03.2013 18:20, Timo Sirainen pisze: > > On 7.3.2013, at 14.12, Marcin Mirosław wrote: > > > >> Here is backtrace from doveadm force-resync: > >> > >> #0 rebuild_mailbox_multi (trans=0x428b58d090, view=, > >> rebuild_ctx=0x428b5a0690, ctx=0x428b57a9a0, mbox=) at > >> mdbox-storage-rebuild.c:433 > >> 433 map_uid = rec->map_uid; > > > > Yeah, I fixed this immediately after 2.1.15: > > http://hg.dovecot.org/dovecot-2.1/rev/2def25f07ca6 > > > > I guess it's soon time for 2.1.16. > > Hi! I've aplied patch and force-resync finished work without problem.Thanks! > I asked one more question: `doveadm force-resync -A "*"` doesn't do > resync inside namespace. Is it feature or bug? What exactly do you mean? I think it should only resync the mailboxes in the prefix="" namespace, or at least that's the intended behavior with other commands where "*" is used. Is -A relevant here (= does it happen the same with -u username)?
Re: [Dovecot] 2.2.rc2: problem with acl_shared_dict
On Tue, 2013-02-26 at 12:16 +0100, Lutz Preßler wrote: > Hello, > > 2.2.rc2, configuration as before: > > acl_shared_dict=file:... > The contents of this file is used for e.g. LISTing shared mailboxes. > But even with file and directory beeing world writable, it's not written > into on SETACL commands. > Instead, at least sometimes (it seems to make a difference if GETACL is > used before in the session) the imap process crashes on SETACL or DELETEACL. > > Feb 26 00:31:52 host dovecot: imap(13373, user) K64y8ZTWOgB/AAAB: Fatal: > master: service(imap): child 13373 killed with signal 11 (core dumps > disabled) > Anything to do for further debugging? Working correctly with 2.1.15. Fixed finally: http://hg.dovecot.org/dovecot-2.2/rev/d211174a2392
