Re: [Dovecot] Patch for pigeonhole 0.4.0 avoiding PATH_MAX
On 6/15/2013 3:24 PM, Svante Signell wrote: Hi, I recently downloaded and built dovecot-2.2.2 and dovecot-2.2-pigeonhole-0.4.0 on GNU/Linux and GNU/Hurd. The changes needed will be sent to the Debian maintainer shortly. Latest Debian release is 2.1.7-7 and dovecot-2.1-pigeonhole-0.3.1. When building dovecot-2.2.2 there were no PATH_MAX problems on GNU/Hurd, thank you for that. However, pigeonhole 0.4.0 had one remaining PATH_MAX construct. The attached patch solves this problem. It it good enough to be accepted upstream? (According to the description of t_malloc, free is not needed, right?) Fixed: http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/1b1a0c271383 Regards, Stephan.
Re: [Dovecot] Problem redirecting email using pigeonhole 0.4.0 (with patch)
On 6/8/2013 11:37 PM, Andriy Syrovenko wrote: Hello, Starting from the version 0.4.0 Pigeonhole adds X-Sieve and X-Sieve-Redirected-From headers ending them with CR+LF, and then copies the original message (including original headers) ending the lines with LF-only. This causes troubles at least if using Exim (I have not checked with other MTAs)- original message gets dropped, and only the new pigeonhole-generated headers are sent out. The attached file fixed the problem for me. Applied: http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/e439789e3211 I hope I can restructure LDA mail submission a bit when I finish lib-smtp, avoiding useless conversions between CRLF and LF line endings. Regards, Stephan.
Re: [Dovecot] doveadm index crashes when indexing shared mailboxes
Hi, We store our mail archive in a tree of subfolders. I am trying to speed up text searching on our mail archive but when running doveadm -D -v index -u neil shared/Exalon/Aandeelhouders the following output is produced: .. doveadm(neil): Panic: file mbox-storage.c: line 711 (mbox_transaction_unlock): assertion failed: (mbox-box.transaction_count 0 || mbox-mbox_lock_type == F_UNLCK) mbox is a pretty difficult format, and I wouldn't recommend using it for anything else than small simple legacy setups. After changing the format to sdbox indexing works. regards, -- Willem-Jan de Hoog
[Dovecot] dovecot enterprise release
Hi all, Not sure if this is the right place to ask, but...: On the dovecot enterprise release pages, only debian 6 compatibility is shown. Are there any plans to support wheezy? (as 7 is stable now, and we are running it...) Regards, Mourik Jan
Re: [Dovecot] Mailbox conversion/importing
Hi, We have used Rick's tools to migrate from scalix to dovecot, and they worked out incredibly well for us. Also Rick was very responsive to questions and suggestions. I consider it $35 USD well spent. And that's the end of this commercial. ;-) Mourik Jan On 06/17/2013 04:31 AM, Rick Sanders wrote: A specialised migration tool must be less tested (and perhaps more buggy) than pop/imap servers that are in use around the world constantly. On the other hand a tool which is specifically built to do IMAP migration can do the job quickly and efficiently. My experience is that a well-designed IMAP Migration tool which has been tested over the years is often the best bet. Just my own 2 cents worth. Rick Sanders rfs9...@earthlink.net http://www.athensfbc.com/imap-tools
Re: [Dovecot] dovecot enterprise release
On 18.6.2013, at 12.32, mourik jan SOGo heup...@merit.unu.edu wrote: Not sure if this is the right place to ask, but...: On the dovecot enterprise release pages, only debian 6 compatibility is shown. Are there any plans to support wheezy? (as 7 is stable now, and we are running it…) Wheezy is supported already as well. I guess the web page needs updating.
Re: [Dovecot] Patch for pigeonhole 0.4.0 avoiding PATH_MAX
On Tue, 2013-06-18 at 08:37 +0200, Stephan Bosch wrote: On 6/15/2013 3:24 PM, Svante Signell wrote: Hi, I recently downloaded and built dovecot-2.2.2 and dovecot-2.2-pigeonhole-0.4.0 on GNU/Linux and GNU/Hurd. The changes needed will be sent to the Debian maintainer shortly. Latest Debian release is 2.1.7-7 and dovecot-2.1-pigeonhole-0.3.1. When building dovecot-2.2.2 there were no PATH_MAX problems on GNU/Hurd, thank you for that. However, pigeonhole 0.4.0 had one remaining PATH_MAX construct. The attached patch solves this problem. It it good enough to be accepted upstream? (According to the description of t_malloc, free is not needed, right?) Fixed: http://hg.rename-it.nl/dovecot-2.2-pigeonhole/rev/1b1a0c271383 Thanks a lot :)
Re: [Dovecot] dovecot enterprise release
Hi Timo, list, Wheezy is supported already as well. I guess the web page needs updating. Ah, thanks for the quick reply. MJ
[Dovecot] Crashes at login time with freshest code
Hello,
Dovecot keeps crashing at login time. Things were fine on 2.2.2
Fatal: master: service(imap): child 5014 killed with signal 11
Here is the trace:
Core was generated by `imap'.
Program terminated with signal 11, Segmentation fault.
#0 0x105cdfdf in mailbox_list_get_storage (list=0x7fffe310,
vname=0x10a04ab0 INBOX/spam, storage_r=0x7fffe308)
at mailbox-list.c:811
811 if (set != NULL set-driver[0] != '\0') {
(gdb) bt full
#0 0x105cdfdf in mailbox_list_get_storage (list=0x7fffe310,
vname=0x10a04ab0 INBOX/spam, storage_r=0x7fffe308)
at mailbox-list.c:811
set = 0x10a89758
#1 0x108c2876 in acl_backend_vfile_get_local_dir
(backend=0x10a33a40, name=0x10a04a48 INBOX/spam) at
acl-backend-vfile.c:148
ns = 0x10a5d3c0
list = 0x10a45040
storage = 0xb
type = MAILBOX_LIST_PATH_TYPE_DIR
dir = 0x10a1a250 INBOX/spam
inbox = 0x1055dcc0 static_system_pool \200\334U\020
vname = 0x10a04ab0 INBOX/spam
error = 0x0
__FUNCTION__ = acl_backend_vfile_get_local_dir
#2 0x108c2a6c in acl_backend_vfile_object_init
(_backend=0x10a33a40, name=0x10a04a48 INBOX/spam) at
acl-backend-vfile.c:195
_data_stack_cur_id = 9
backend = 0x10a33a40
aclobj = 0x10a8c380
dir = 0x10a04a68 \003
vname = 0x10a45258 \220R\244\020
#3 0x108c05a2 in acl_object_init_from_name (backend=0x10a33a40,
name=0x10a04a48 INBOX/spam) at acl-api.c:15
No locals.
#4 0x108ca3d7 in acl_mailbox_list_have_right (list=0x10a45040,
name=0x10a04a48 INBOX/spam, parent=false, acl_storage_right_idx=0,
can_see_r=0x0) at acl-mailbox-list.c:63
alist = 0x10a45328
backend = 0x10a33a40
idx_arr = 0x10a453f8
aclobj = 0x1e420
ret = 0
ret2 = 10
#5 0x108cad9c in acl_mailbox_list_info_is_visible
(ctx=0x10a11040) at acl-mailbox-list.c:336
info = 0x10a110a8
acl_name = 0x10a04a48 INBOX/spam
ret = 0
__FUNCTION__ = acl_mailbox_list_info_is_visible
#6 0x108caf36 in acl_mailbox_list_iter_next (_ctx=0x10a11040)
at acl-mailbox-list.c:386
_data_stack_cur_id = 8
ctx = 0x10a11040
info = 0x10a4a0c0
ret = 0
#7 0x105e4394 in mailbox_list_iter_next_call (ctx=0x10a11040)
at mailbox-list-iter.c:941
info = 0x10a110a8
set = 0x10a0
#8 0x105e44ae in autocreate_iter_next (ctx=0x10a11040) at
mailbox-list-iter.c:969
actx = 0x10a0
info = 0x7fffe510
autoboxes = 0x10a45040
autobox = 0x7fffe530
count = 4096
__FUNCTION__ = autocreate_iter_next
#9 0x105e466c in mailbox_list_iter_next (ctx=0x10a11040) at
mailbox-list-iter.c:1010
_data_stack_cur_id = 7
info = 0x10a8
#10 0x108cacd3 in iter_mailbox_has_visible_children
(ctx=0x10a10840, only_nonpatterns=false) at acl-mailbox-list.c:299
iter = 0x10a11040
info = 0x10a8
pattern = 0x10a047c8
prefix = 0x10a04800 INBOX/*
i = 5
prefix_len = 6
stars = false
ret = true
__FUNCTION__ = iter_mailbox_has_visible_children
#11 0x108cade9 in acl_mailbox_list_info_is_visible
(ctx=0x10a10840) at acl-mailbox-list.c:345
info = 0x10a108a8
acl_name = 0x10a047a0 INBOX
ret = 1
__FUNCTION__ = acl_mailbox_list_info_is_visible
#12 0x108caf36 in acl_mailbox_list_iter_next (_ctx=0x10a10840)
at acl-mailbox-list.c:386
_data_stack_cur_id = 6
ctx = 0x10a10840
info = 0x10a490c0
ret = 0
#13 0x105e4394 in mailbox_list_iter_next_call (ctx=0x10a10840)
at mailbox-list-iter.c:941
info = 0x0
set = 0x0
#14 0x105e44ae in autocreate_iter_next (ctx=0x10a10840) at
mailbox-list-iter.c:969
actx = 0x10a10910
info = 0x7fffe6b0
autoboxes = 0x2
autobox = 0x10a9b000
count = 0
__FUNCTION__ = autocreate_iter_next
#15 0x105e466c in mailbox_list_iter_next (ctx=0x10a10840) at
mailbox-list-iter.c:1010
_data_stack_cur_id = 5
info = 0x10a1b780
#16 0x105e343b in mailbox_list_ns_iter_try_next
(_ctx=0x10a10440, info_r=0x7fffe768) at mailbox-list-iter.c:580
ctx = 0x10a10440
ns = 0x1050912c o_stream_get_buffer_used_size+41
info = 0x10a1b808
error = MAIL_ERROR_NONE
errstr = 0x10a47840
has_children = false
__FUNCTION__ = mailbox_list_ns_iter_try_next
#17 0x105e36fc in mailbox_list_ns_iter_next (_ctx=0x10a10440) at
mailbox-list-iter.c:645
info = 0x0
#18 0x105e4394 in mailbox_list_iter_next_call (ctx=0x10a10440)
at mailbox-list-iter.c:941
---Type return to continue, or q return to quit---
info = 0x417e06 client_send_line_next+159
set = 0x7fffe7d0
#19 0x105e467e in mailbox_list_iter_next
Re: [Dovecot] v2.2.3 released
On 6/17/2013 8:06 AM, Timo Sirainen wrote: On 17.6.2013, at 0.41, Timo Sirainen t...@iki.fi wrote: http://dovecot.org/releases/2.2/dovecot-2.2.3.tar.gz http://dovecot.org/releases/2.2/dovecot-2.2.3.tar.gz.sig This is a pretty important upgrade for v2.2 users, because of the IMAP ENVELOPE reply fix. sdbox/mdbox users: Don't upgrade just yet.. It seems it may cause Extension header update points outside header size errors that don't fix themselves. (Bug 1: Causing this error in the first place, bug 2: not being able to fix it automatically.) Hi Timo, The latest from http://hg.dovecot.org/dovecot-2.2/ seems to fix the dsync errors I was seeing with 2.2.2. Mostly Error: Mailbox INBOX sync: mailbox_delete failed: INBOX can't be deleted. Is the extension header bug fixed with yesterday's patch: http://hg.dovecot.org/dovecot-2.2/rev/3056feb418b1 ? Thanks, Ken Anderson If you're already getting those errors, attached a workaround patch. Probably happens only to POP3 users. I'm not sure yet how to reproduce this. -- Ken Anderson Pacific Internet - http://www.pacific.net
[Dovecot] dovecot creating unknown users
Hi
We recently installed a dovecot postfix roundcube debian
wheezy serverIt is now in production and we are feeling
our way as we progressivelyadd new users to this local
server.
I noticed that dovecot is creating user directory structures
for unknown users withinour domain in /var/vmail, even
though we have setup a static users.conf db file.
I tried omiting the allow_all_users=yes parameter but
that doesn't seem to be linked to this issue
Sorry if this has been asked a number of times already
Is there an easy way to search the archives of this
mailinglist ?
Thanks
yann
# 2.2.2 (45399357008a): /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-4-686-pae i686 Debian 7.0 ext4
auth_debug = yes
auth_mechanisms = plain login
auth_socket_path = /var/run/dovecot/auth-userdb
auth_verbose = yes
disable_plaintext_auth = no
first_valid_gid = 5000
first_valid_uid = 5000
hostname = holimail.holinice.com
last_valid_gid = 5000
last_valid_uid = 5000
listen = *
mail_debug = yes
mail_gid = vmail
mail_location = maildir:/var/vmail/%d/%n/Maildir
mail_privileged_group = mail
mail_uid = vmail
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 = maildir:/var/vmail/%d/%n/Maildir
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 =
subscriptions = yes
}
passdb {
args = scheme=CRAM-MD5 /etc/dovecot/users.conf
driver = passwd-file
}
passdb {
driver = pam
}
plugin {
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve
}
postmaster_address = azur...@holinice.com
protocols = imap sieve pop3
service auth-worker {
user = $default_internal_user
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
}
unix_listener auth-userdb {
group = vmail
mode = 0600
user = vmail
}
}
service imap-login {
group = dovecot
inet_listener imap {
port = 143
}
inet_listener imaps {
port = 993
ssl = yes
}
}
service imap {
process_limit = 1024
}
service pop3-login {
inet_listener pop3 {
port = 110
}
inet_listener pop3s {
port = 995
ssl = yes
}
}
service pop3 {
process_limit = 1024
}
ssl_cert = /etc/ssl/certs/dovecot.pem
ssl_key = /etc/ssl/private/dovecot.pem
userdb {
args = uid=5000 gid=5000 home=/var/vmail/%d/%n allow_all_users=yes
driver = static
}
userdb {
driver = passwd
}
protocol lda {
mail_plugins = sieve
}
Re: [Dovecot] Crashes at login time with freshest code
Hi Olivier,
I think I am hitting the same issue on a test machine, but I didn't had
the time yet to debug it properly.
Is your INBOX/spam folder configured to be auto-created?
What mailbox format do you use? (I am using maildir)
Cheers,
Chris
On Tue, 18 Jun 2013 17:14:52 +0200
interfaSys sàrl interfa...@gmail.com wrote:
Hello,
Dovecot keeps crashing at login time. Things were fine on 2.2.2
Fatal: master: service(imap): child 5014 killed with signal 11
Here is the trace:
Core was generated by `imap'.
Program terminated with signal 11, Segmentation fault.
#0 0x105cdfdf in mailbox_list_get_storage
(list=0x7fffe310, vname=0x10a04ab0 INBOX/spam,
storage_r=0x7fffe308) at mailbox-list.c:811
811 if (set != NULL set-driver[0] != '\0') {
(gdb) bt full
#0 0x105cdfdf in mailbox_list_get_storage
(list=0x7fffe310, vname=0x10a04ab0 INBOX/spam,
storage_r=0x7fffe308) at mailbox-list.c:811
set = 0x10a89758
#1 0x108c2876 in acl_backend_vfile_get_local_dir
(backend=0x10a33a40, name=0x10a04a48 INBOX/spam) at
acl-backend-vfile.c:148
ns = 0x10a5d3c0
list = 0x10a45040
storage = 0xb
type = MAILBOX_LIST_PATH_TYPE_DIR
dir = 0x10a1a250 INBOX/spam
inbox = 0x1055dcc0 static_system_pool \200\334U\020
vname = 0x10a04ab0 INBOX/spam
error = 0x0
__FUNCTION__ = acl_backend_vfile_get_local_dir
#2 0x108c2a6c in acl_backend_vfile_object_init
(_backend=0x10a33a40, name=0x10a04a48 INBOX/spam) at
acl-backend-vfile.c:195
_data_stack_cur_id = 9
backend = 0x10a33a40
aclobj = 0x10a8c380
dir = 0x10a04a68 \003
vname = 0x10a45258 \220R\244\020
#3 0x108c05a2 in acl_object_init_from_name
(backend=0x10a33a40, name=0x10a04a48 INBOX/spam) at acl-api.c:15
No locals.
#4 0x108ca3d7 in acl_mailbox_list_have_right
(list=0x10a45040, name=0x10a04a48 INBOX/spam, parent=false,
acl_storage_right_idx=0, can_see_r=0x0) at acl-mailbox-list.c:63
alist = 0x10a45328
backend = 0x10a33a40
idx_arr = 0x10a453f8
aclobj = 0x1e420
ret = 0
ret2 = 10
#5 0x108cad9c in acl_mailbox_list_info_is_visible
(ctx=0x10a11040) at acl-mailbox-list.c:336
info = 0x10a110a8
acl_name = 0x10a04a48 INBOX/spam
ret = 0
__FUNCTION__ = acl_mailbox_list_info_is_visible
#6 0x108caf36 in acl_mailbox_list_iter_next (_ctx=0x10a11040)
at acl-mailbox-list.c:386
_data_stack_cur_id = 8
ctx = 0x10a11040
info = 0x10a4a0c0
ret = 0
#7 0x105e4394 in mailbox_list_iter_next_call (ctx=0x10a11040)
at mailbox-list-iter.c:941
info = 0x10a110a8
set = 0x10a0
#8 0x105e44ae in autocreate_iter_next (ctx=0x10a11040) at
mailbox-list-iter.c:969
actx = 0x10a0
info = 0x7fffe510
autoboxes = 0x10a45040
autobox = 0x7fffe530
count = 4096
__FUNCTION__ = autocreate_iter_next
#9 0x105e466c in mailbox_list_iter_next (ctx=0x10a11040) at
mailbox-list-iter.c:1010
_data_stack_cur_id = 7
info = 0x10a8
#10 0x108cacd3 in iter_mailbox_has_visible_children
(ctx=0x10a10840, only_nonpatterns=false) at acl-mailbox-list.c:299
iter = 0x10a11040
info = 0x10a8
pattern = 0x10a047c8
prefix = 0x10a04800 INBOX/*
i = 5
prefix_len = 6
stars = false
ret = true
__FUNCTION__ = iter_mailbox_has_visible_children
#11 0x108cade9 in acl_mailbox_list_info_is_visible
(ctx=0x10a10840) at acl-mailbox-list.c:345
info = 0x10a108a8
acl_name = 0x10a047a0 INBOX
ret = 1
__FUNCTION__ = acl_mailbox_list_info_is_visible
#12 0x108caf36 in acl_mailbox_list_iter_next (_ctx=0x10a10840)
at acl-mailbox-list.c:386
_data_stack_cur_id = 6
ctx = 0x10a10840
info = 0x10a490c0
ret = 0
#13 0x105e4394 in mailbox_list_iter_next_call (ctx=0x10a10840)
at mailbox-list-iter.c:941
info = 0x0
set = 0x0
#14 0x105e44ae in autocreate_iter_next (ctx=0x10a10840) at
mailbox-list-iter.c:969
actx = 0x10a10910
info = 0x7fffe6b0
autoboxes = 0x2
autobox = 0x10a9b000
count = 0
__FUNCTION__ = autocreate_iter_next
#15 0x105e466c in mailbox_list_iter_next (ctx=0x10a10840) at
mailbox-list-iter.c:1010
_data_stack_cur_id = 5
info = 0x10a1b780
#16 0x105e343b in mailbox_list_ns_iter_try_next
(_ctx=0x10a10440, info_r=0x7fffe768) at mailbox-list-iter.c:580
ctx = 0x10a10440
ns = 0x1050912c o_stream_get_buffer_used_size+41
info = 0x10a1b808
error = MAIL_ERROR_NONE
errstr = 0x10a47840
has_children = false
Re: [Dovecot] v2.2.3 released
On 18.6.2013, at 18.22, Ken A k...@pacific.net wrote: sdbox/mdbox users: Don't upgrade just yet.. It seems it may cause Extension header update points outside header size errors that don't fix themselves. (Bug 1: Causing this error in the first place, bug 2: not being able to fix it automatically.) Hi Timo, The latest from http://hg.dovecot.org/dovecot-2.2/ seems to fix the dsync errors I was seeing with 2.2.2. Mostly Error: Mailbox INBOX sync: mailbox_delete failed: INBOX can't be deleted. Normally that shouldn't happen in the first place! But yeah, that fix was done intentionally. But if INBOX is being deleted all the time with you there's something wrong. Is the extension header bug fixed with yesterday's patch: http://hg.dovecot.org/dovecot-2.2/rev/3056feb418b1 ? Today's patch :) But yes, that one. And since it happens only with corrupted dboxes anyway I guess it's not actually that bad. Oh, almost forgot to fix this for sdbox also: http://hg.dovecot.org/dovecot-2.2/rev/07642120b6ea
Re: [Dovecot] Crashes at login time with freshest code
On 18.6.2013, at 18.14, interfaSys sàrl interfa...@gmail.com wrote:
Hello,
Dovecot keeps crashing at login time. Things were fine on 2.2.2
Fatal: master: service(imap): child 5014 killed with signal 11
Here is the trace:
Core was generated by `imap'.
Program terminated with signal 11, Segmentation fault.
#0 0x105cdfdf in mailbox_list_get_storage (list=0x7fffe310,
vname=0x10a04ab0 INBOX/spam, storage_r=0x7fffe308)
at mailbox-list.c:811
811 if (set != NULL set-driver[0] != '\0') {
Fixed: http://hg.dovecot.org/dovecot-2.2/rev/8a81c5a1b60f
[Dovecot] deny users
hello I'm in trouble with the deny feature the log is like the following Jun 18 17:37:53 auth: Error: Error in configuration file /usr/local/etc/dovecot/deny.imap line 1: Expecting '=' in the documentation said to write one username per line in the deny file that is what I did ...what is the format of this file ? thank you
Re: [Dovecot] deny users
On 18.6.2013, at 18.59, BONNET, Frank frank.bon...@esiee.fr wrote: I'm in trouble with the deny feature the log is like the following Jun 18 17:37:53 auth: Error: Error in configuration file /usr/local/etc/dovecot/deny.imap line 1: Expecting '=' It's not a configuration file. in the documentation said to write one username per line in the deny file that is what I did ...what is the format of this file ? The file format is correct. Your configuration for it isn't. What's your doveconf -n? Is this file getting !included?
Re: [Dovecot] Crashes at login time with freshest code
Hello Chris,
You are right. Autocreated and autosubscribed.
And we're using mdbox.
It seems Timo has fixed the issue in the repository.
I'll report back if it isn't the case.
Cheers,
Olivier
On 18/06/2013 17:33, Christian Wiese wrote:
Hi Olivier,
I think I am hitting the same issue on a test machine, but I didn't had
the time yet to debug it properly.
Is your INBOX/spam folder configured to be auto-created?
What mailbox format do you use? (I am using maildir)
Cheers,
Chris
On Tue, 18 Jun 2013 17:14:52 +0200
interfaSys sàrl interfa...@gmail.com wrote:
Hello,
Dovecot keeps crashing at login time. Things were fine on 2.2.2
Fatal: master: service(imap): child 5014 killed with signal 11
Here is the trace:
Core was generated by `imap'.
Program terminated with signal 11, Segmentation fault.
#0 0x105cdfdf in mailbox_list_get_storage
(list=0x7fffe310, vname=0x10a04ab0 INBOX/spam,
storage_r=0x7fffe308) at mailbox-list.c:811
811 if (set != NULL set-driver[0] != '\0') {
(gdb) bt full
#0 0x105cdfdf in mailbox_list_get_storage
(list=0x7fffe310, vname=0x10a04ab0 INBOX/spam,
storage_r=0x7fffe308) at mailbox-list.c:811
set = 0x10a89758
#1 0x108c2876 in acl_backend_vfile_get_local_dir
(backend=0x10a33a40, name=0x10a04a48 INBOX/spam) at
acl-backend-vfile.c:148
ns = 0x10a5d3c0
list = 0x10a45040
storage = 0xb
type = MAILBOX_LIST_PATH_TYPE_DIR
dir = 0x10a1a250 INBOX/spam
inbox = 0x1055dcc0 static_system_pool \200\334U\020
vname = 0x10a04ab0 INBOX/spam
error = 0x0
__FUNCTION__ = acl_backend_vfile_get_local_dir
#2 0x108c2a6c in acl_backend_vfile_object_init
(_backend=0x10a33a40, name=0x10a04a48 INBOX/spam) at
acl-backend-vfile.c:195
_data_stack_cur_id = 9
backend = 0x10a33a40
aclobj = 0x10a8c380
dir = 0x10a04a68 \003
vname = 0x10a45258 \220R\244\020
#3 0x108c05a2 in acl_object_init_from_name
(backend=0x10a33a40, name=0x10a04a48 INBOX/spam) at acl-api.c:15
No locals.
#4 0x108ca3d7 in acl_mailbox_list_have_right
(list=0x10a45040, name=0x10a04a48 INBOX/spam, parent=false,
acl_storage_right_idx=0, can_see_r=0x0) at acl-mailbox-list.c:63
alist = 0x10a45328
backend = 0x10a33a40
idx_arr = 0x10a453f8
aclobj = 0x1e420
ret = 0
ret2 = 10
#5 0x108cad9c in acl_mailbox_list_info_is_visible
(ctx=0x10a11040) at acl-mailbox-list.c:336
info = 0x10a110a8
acl_name = 0x10a04a48 INBOX/spam
ret = 0
__FUNCTION__ = acl_mailbox_list_info_is_visible
#6 0x108caf36 in acl_mailbox_list_iter_next (_ctx=0x10a11040)
at acl-mailbox-list.c:386
_data_stack_cur_id = 8
ctx = 0x10a11040
info = 0x10a4a0c0
ret = 0
#7 0x105e4394 in mailbox_list_iter_next_call (ctx=0x10a11040)
at mailbox-list-iter.c:941
info = 0x10a110a8
set = 0x10a0
#8 0x105e44ae in autocreate_iter_next (ctx=0x10a11040) at
mailbox-list-iter.c:969
actx = 0x10a0
info = 0x7fffe510
autoboxes = 0x10a45040
autobox = 0x7fffe530
count = 4096
__FUNCTION__ = autocreate_iter_next
#9 0x105e466c in mailbox_list_iter_next (ctx=0x10a11040) at
mailbox-list-iter.c:1010
_data_stack_cur_id = 7
info = 0x10a8
#10 0x108cacd3 in iter_mailbox_has_visible_children
(ctx=0x10a10840, only_nonpatterns=false) at acl-mailbox-list.c:299
iter = 0x10a11040
info = 0x10a8
pattern = 0x10a047c8
prefix = 0x10a04800 INBOX/*
i = 5
prefix_len = 6
stars = false
ret = true
__FUNCTION__ = iter_mailbox_has_visible_children
#11 0x108cade9 in acl_mailbox_list_info_is_visible
(ctx=0x10a10840) at acl-mailbox-list.c:345
info = 0x10a108a8
acl_name = 0x10a047a0 INBOX
ret = 1
__FUNCTION__ = acl_mailbox_list_info_is_visible
#12 0x108caf36 in acl_mailbox_list_iter_next (_ctx=0x10a10840)
at acl-mailbox-list.c:386
_data_stack_cur_id = 6
ctx = 0x10a10840
info = 0x10a490c0
ret = 0
#13 0x105e4394 in mailbox_list_iter_next_call (ctx=0x10a10840)
at mailbox-list-iter.c:941
info = 0x0
set = 0x0
#14 0x105e44ae in autocreate_iter_next (ctx=0x10a10840) at
mailbox-list-iter.c:969
actx = 0x10a10910
info = 0x7fffe6b0
autoboxes = 0x2
autobox = 0x10a9b000
count = 0
__FUNCTION__ = autocreate_iter_next
#15 0x105e466c in mailbox_list_iter_next (ctx=0x10a10840) at
mailbox-list-iter.c:1010
_data_stack_cur_id = 5
info = 0x10a1b780
#16 0x105e343b in mailbox_list_ns_iter_try_next
(_ctx=0x10a10440,
Re: [Dovecot] v2.2.3 released
On 6/18/2013 10:54 AM, Timo Sirainen wrote: On 18.6.2013, at 18.22, Ken A k...@pacific.net wrote: sdbox/mdbox users: Don't upgrade just yet.. It seems it may cause Extension header update points outside header size errors that don't fix themselves. (Bug 1: Causing this error in the first place, bug 2: not being able to fix it automatically.) Hi Timo, The latest from http://hg.dovecot.org/dovecot-2.2/ seems to fix the dsync errors I was seeing with 2.2.2. Mostly Error: Mailbox INBOX sync: mailbox_delete failed: INBOX can't be deleted. Normally that shouldn't happen in the first place! But yeah, that fix was done intentionally. But if INBOX is being deleted all the time with you there's something wrong. I suspect I'm causing breakage of metadata. I'm preparing to migrate to mdbox from mbox, so I'm rsyncing mboxes to a new server and then running dsync -R -u user backup mbox:/path The INBOXes that were generating this error were those that I'd opened using an IMAP client on the new server (testing mailboxes) between rsync/dsync runs. Thanks, Ken Is the extension header bug fixed with yesterday's patch: http://hg.dovecot.org/dovecot-2.2/rev/3056feb418b1 ? Today's patch :) But yes, that one. And since it happens only with corrupted dboxes anyway I guess it's not actually that bad. Oh, almost forgot to fix this for sdbox also: http://hg.dovecot.org/dovecot-2.2/rev/07642120b6ea -- Ken Anderson Pacific Internet - http://www.pacific.net
Re: [Dovecot] Crashes at login time with freshest code
This has fixed it for me.
Thank you.
On 18/06/2013 17:56, Timo Sirainen wrote:
On 18.6.2013, at 18.14, interfaSys sàrl interfa...@gmail.com wrote:
Hello,
Dovecot keeps crashing at login time. Things were fine on 2.2.2
Fatal: master: service(imap): child 5014 killed with signal 11
Here is the trace:
Core was generated by `imap'.
Program terminated with signal 11, Segmentation fault.
#0 0x105cdfdf in mailbox_list_get_storage (list=0x7fffe310,
vname=0x10a04ab0 INBOX/spam, storage_r=0x7fffe308)
at mailbox-list.c:811
811 if (set != NULL set-driver[0] != '\0') {
Fixed: http://hg.dovecot.org/dovecot-2.2/rev/8a81c5a1b60f
[Dovecot] Pound Sign # in password
Is there any way to use a pound sign # in my postfix user password in the dovecot sql configuration file.
Re: [Dovecot] deny users
hello Timo thanks for the answer I found my mistake after posting ... overwork since two weeks sorry for the noise Envoyé de mon iPhone. Le 18 juin 2013 à 18:05, Timo Sirainen t...@iki.fi a écrit : On 18.6.2013, at 18.59, BONNET, Frank frank.bon...@esiee.fr wrote: I'm in trouble with the deny feature the log is like the following Jun 18 17:37:53 auth: Error: Error in configuration file /usr/local/etc/dovecot/deny.imap line 1: Expecting '=' It's not a configuration file. in the documentation said to write one username per line in the deny file that is what I did ...what is the format of this file ? The file format is correct. Your configuration for it isn't. What's your doveconf -n? Is this file getting !included?
