Re: [Dovecot] Pigeonhole and dsync replication not replicating 'SETACTIVE' for a sieve script
On 6/2/2014 11:11 PM, Skeffling wrote: Hello, I'm testing dovecot replication alongside pigeonhole and liking it. Dovecot v2.2.13 Pigeonhole v0.4.3 If I create or edit a sieve script on one server (via managesieve, using the thunderbird plugin as it happens) then it does get replicated to the other - great! However, if I set a script to be active (SETACTIVE) on one side then this is not being replicated across to the other server. Is this a known issue? It is not. Could you send us your full configuration (output from `dovecot -n`). Regards, Stephan.
BUG: Mail folder with space in its name is not supported in the global acl file
Hello, I use Dovecot 2.2.13 The syntax of my global acl file is: cat /etc/dovecot/acls INBOX.Junk Mail owner lrwstiae The error is: Error: Global ACL file /etc/dovecot/acls line 1: Unknown ID 'Mail' I tried to escape it with ,'',/ and enclose the whole name with '' without success If I change the rule to: INBOX.JunkMail owner lrwstiae or INBOX.Junk?Mail owner lrwstiae The acl works fine. Please advise how to apply the acl rule for the folder with a space in its name? Thank you Iavor Stoev Project Manager // Head of System Network Administration Department
connection to director (lmtp) time out
Hi all,
I'm running two directors with lmtp proxy as relay transport for my
mail exchangers.
relay_transport = lmtp:inet:dovecot-directors.example.net
dovecot-directors.example.net resolves to 172.17.1.3 and 172.17.1.4
Now, .3 is down and Postfix tries to deliver it to .4 but this
connection gets a timeout:
(delivery temporarily suspended: connect to 172.17.1.4[172.17.1.4]:24:
Connection timed out
There is no log entry on the director.
Can anyone give me a hint how to solve this or maybe optimize my
configuration?
Regards
Patrick
auth_mechanisms = plain login
default_process_limit = 150
director_mail_servers = 172.17.1.2
director_servers = 172.17.1.4 172.17.1.3
director_user_expire = 5 mins
lmtp_proxy = yes
log_path = /var/log/dovecot.log
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
protocols = imap pop3 lmtp sieve
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0666
user = postfix
}
unix_listener auth-userdb {
user = dovecot
}
}
service director {
fifo_listener login/proxy-notify {
mode = 0666
}
inet_listener {
address = 172.17.1.4
port = 9090
}
unix_listener director-userdb {
mode = 0600
}
unix_listener login/director {
mode = 0666
}
}
service imap-login {
executable = imap-login director
}
service lmtp {
inet_listener lmtp {
address = 172.17.1.4
port = 24
}
}
service managesieve-login {
executable = managesieve-login director
inet_listener sieve {
port = 4190
}
}
service pop3-login {
executable = pop3-login director
}
ssl_cert = /etc/ssl/certs/wildcard.example.de.crt
ssl_key = /etc/ssl/private/wildcard.example.de.key
protocol !smtp {
passdb {
args = proxy=y nopassword=y starttls=any-cert
driver = static
}
}
protocol smtp {
passdb {
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
userdb {
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
driver = sql
}
}
protocol lmtp {
auth_socket_path = director-userdb
}
local 83.149 {
protocol imap {
ssl_cert = /etc/ssl/certs/wildcard.example.de.pem
ssl_key = /etc/ssl/private/wildcard.example.de.key
}
}
local 83.149... {
protocol pop3 {
ssl_cert = /etc/ssl/certs/wildcard.example.de.pem
ssl_key = /etc/ssl/private/wildcard.example.de.key
}
}
local [2001:1af8:...] {
protocol imap {
ssl_cert = /etc/ssl/certs/wildcard.example.de.pem
ssl_key = /etc/ssl/private/wildcard.example.de.key
}
}
local [2001:1af8:...] {
protocol pop3 {
ssl_cert = /etc/ssl/certs/wildcard.example.de.pem
ssl_key = /etc/ssl/private/wildcard.example.de.key
}
}
Problems with dovecot 2.2.13 and monit
Hello, When I upgraded my servers to dovecot 2.2.13 the monitoring tool monit started to send out warnings that it couldn't reach my imap/pop3 servers through ssl any more. The same problem didn't happen on non-ssl-connections. According to people on the monit list this is likely a dovecot issue: https://lists.gnu.org/archive/html/monit-general/2014-06/msg00031.html Let me quote: the root cause of the error is, that dovecot 2.2.13 closes the connection if SSL is used in response to LOGOUT command instead of sending usual response. When no SSL is enabled, dovecot responses to LOGOUT command normally. [...] According to RFC 3501 (http://tools.ietf.org/html/rfc3501), LOGOUT is any-state command, where the server MUST send response before closing the connection: http://tools.ietf.org/html/rfc3501#section-3.4 = the problem is caused by dovecot 2.2.13 bug ... its behaviour is inconsistent (LOGOUT in non-authenticated state works per RFC requirement if no SSL is used and doesn't conform to RFC if SSL is used). It is possible that the problem is related to their DoS-attack modification, which has most probably unexpected side-effect. Maybe this is related to the DDoS-protection measures that have been added in dovecot 2.2.13. Would apprechiate if someone could have a look. cu, -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: Problems with dovecot 2.2.13 and monit
On 06/16/2014 03:35 PM, Hanno Böck wrote: = the problem is caused by dovecot 2.2.13 bug ... its behaviour is inconsistent (LOGOUT in non-authenticated state works per RFC requirement if no SSL is used and doesn't conform to RFC if SSL is used). It is possible that the problem is related to their DoS-attack modification, which has most probably unexpected side-effect. This was fixed in commits http://hg.dovecot.org/dovecot-2.2/rev/09d3c9c6f0ad and http://hg.dovecot.org/dovecot-2.2/rev/7129fe8bc260 so it will work better in the next release. br, Teemu Huovila
SIGSEGV in 2.2.13 with IMAP Proxying to an Exchange Server
100% reproducible. User is using alpine to write an email.
Continue postponed composition (answering No won't erase it)?
y - [Empty folder! No messages really postponed!]
Can't delete
{mproxy.charite.de/ssl/novalidate-cert/user=theusername}postponed-msgs
Setup:
==
http://wiki2.dovecot.org/HowTo/ImapcProxy
coredump available for further inspection
Full backtrace:
===
Attaching to program: /usr/lib/dovecot/imap, process 15573
[New LWP 15573]
Core was generated by `dovecot/imap'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 imapc_client_mailbox_cmd (box=0x0, callback=callback@entry=0x7f6ba2ed40e0
imapc_simple_callback, context=context@entry=0x7fff68b7f1a0) at
imapc-client.c:351
#0 imapc_client_mailbox_cmd (box=0x0, callback=callback@entry=0x7f6ba2ed40e0
imapc_simple_callback, context=context@entry=0x7fff68b7f1a0) at
imapc-client.c:351
cmd = optimized out
__FUNCTION__ = imapc_client_mailbox_cmd
#1 0x7f6ba2ed4815 in imapc_mailbox_noop (mbox=mbox@entry=0x1294060) at
imapc-storage.c:154
cmd = optimized out
sctx = {client = 0x123b400, ret = -2}
#2 0x7f6ba2ed2d30 in imapc_mailbox_sync_init (box=0x1294060,
flags=(MAILBOX_SYNC_FLAG_FULL_READ | MAILBOX_SYNC_FLAG_FIX_INCONSISTENT)) at
imapc-sync.c:476
mbox = 0x1294060
list = optimized out
capabilities = optimized out
changes = true
ret = 0
#3 0x7f6ba2ee53c9 in mailbox_sync_init (box=box@entry=0x1294060,
flags=(MAILBOX_SYNC_FLAG_FULL_READ | MAILBOX_SYNC_FLAG_FIX_INCONSISTENT)) at
mail-storage.c:1677
_data_stack_cur_id = 4
ctx = optimized out
#4 0x7f6ba2ee54d7 in mailbox_sync (box=box@entry=0x1294060,
flags=optimized out, flags@entry=MAILBOX_SYNC_FLAG_FULL_READ) at
mail-storage.c:1725
ctx = 0x1294060
status = {sync_delayed_expunges = 0}
#5 0x7f6ba2f0fdcb in mailbox_expunge_all_data (box=0x1294060) at
index-storage.c:648
ctx = 0x7fff68b7f35c
t = 0x7fff68b7f35c
mail = 0x0
search_args = 0x0
#6 index_storage_mailbox_delete (box=0x1294060) at index-storage.c:701
metadata = {guid =
\000\000\000\000\000\000\000\000\030\377\347\242\000\000\000, virtual_size =
19480672, cache_fields = 0x0,
precache_fields = (MAIL_FETCH_RECEIVED_DATE | MAIL_FETCH_SAVE_DATE |
MAIL_FETCH_PHYSICAL_SIZE | MAIL_FETCH_IMAP_ENVELOPE | MAIL_FETCH_UIDL_FILE_NAME
| MAIL_FETCH_GUID | unknown: 16777216),
backend_ns_prefix = 0x7f6ba2ee64b0 mailbox_open+16
\211\302\061\300\205\322x\bH\203\304\030[]Ð\366\203\230\002, backend_ns_type
= (unknown: 0)}
status = {messages = 0, recent = 0, unseen = 19029536, uidvalidity = 0,
uidnext = 1, first_unseen_seq = 0, first_recent_uid = 2730247353,
last_cached_seq = 32619, highest_modseq = 19480672,
highest_pvt_modseq = 140100271760191, keywords = 0x1, permanent_flags
= 0, permanent_keywords = 0, allow_new_keywords = 0, nonpermanent_modseqs = 0,
no_modseq_tracking = 0, have_guids = 0,
have_save_guids = 0, have_only_guid128 = 0}
ret_guid = optimized out
#7 0x7f6ba2ee66a7 in mailbox_delete (box=0x1294060) at mail-storage.c:1319
ret = optimized out
#8 0x0040d0e1 in cmd_delete (cmd=0x125ce40) at cmd-delete.c:39
client = optimized out
ns = optimized out
box = 0x1294060
name = 0x121b2b8 postponed-msgs
errstr = optimized out
error = 32767
disconnect = false
#9 0x00416cfc in command_exec (cmd=0x125ce40) at imap-commands.c:158
hook = 0x12240e0
ret = optimized out
#10 0x00415d5f in client_command_input (cmd=0x125ce40) at
imap-client.c:778
client = 0x1268c10
command = optimized out
__FUNCTION__ = client_command_input
#11 0x00415e15 in client_command_input (cmd=0x125ce40) at
imap-client.c:839
client = 0x1268c10
command = optimized out
__FUNCTION__ = client_command_input
#12 0x00416115 in client_handle_next_command (remove_io_r=synthetic
pointer, client=0x1268c10) at imap-client.c:877
No locals.
#13 client_handle_input (client=client@entry=0x1268c10) at imap-client.c:889
_data_stack_cur_id = 3
remove_io = false
handled_commands = false
__FUNCTION__ = client_handle_input
#14 0x004164a2 in client_input (client=0x1268c10) at imap-client.c:931
cmd = 0x1234630
output = 0x125cd30
bytes = 32
__FUNCTION__ = client_input
#15 0x7f6ba2c19e6f in io_loop_call_io (io=0x125ae10) at ioloop.c:441
ioloop = 0x1223730
t_id = 2
__FUNCTION__ = io_loop_call_io
#16 0x7f6ba2c1ad77 in io_loop_handler_run_internal
(ioloop=ioloop@entry=0x1223730) at ioloop-epoll.c:220
ctx = 0x12243c0
list = 0x1225e20
io = optimized out
tv = {tv_sec = 1739, tv_usec = 977960}
events_count = optimized out
msecs =
ACL group-override question
Trying to get ACLs working, very basic setup:
Virtual users are put into different acl_group via passdb.
u:{PLAIN}B::userdb_acl_groups=g
The global acl file restricts what they can do.
* group-override=g
* group=g lr
Shouldn't this mean, that the group rights override the user rights?
The effect that I see though is, that the user u then may not do
anything, not even lookup and read.
The wiki text is not fully clear to me: It tells about disabling access
fully (probably by specifying a non-existent group?). But this can only
be one way to use group_override…
--
peter
Re: [Dovecot] Replication with virtual users and static userdb possible ?
I'm trying to avoid switching the userdb from a nice simple static
setup to something else to enable replication. Is there anyone using
replication with a virtual user configuration ? How did you do it ?
Actually, anyone doing replication at all - what does your config look
like ?
Thanks -
D.
On 2014-06-03 11:54, deano-dove...@areyes.com
wrote:
Is it possible to get replication working in a virtual user
setup
that uses a static userdb ? My environment is fairly simple and
typical
- there's a single system user (vmail) that owns all the home
dirs
(/var/mail/domain.com/user). The virtual users
(use...@domain.com:secretpassword) are kept in a single file
(/var/mail/domain.com/PASSWD) that's unique per domain, and referenced
as a static userdb :
passdb {
driver = passwd-file
args =
scheme=plain username_format=%u /var/mail/%d/PASSWD
}
userdb {
driver = static
args = uid=vmail gid=vmail home=/var/mail/%d/%n
}
I know the
wiki http://wiki2.dovecot.org/Replication states that
user listing must
be enabled, but that's not available for a static
userdb. The wiki
http://wiki2.dovecot.org/UserDatabase/Static also
says that it shouldn't
be a problem because it will use do a passdb
lookup instead (except for
PAM which isn't used here).
Unfortunately, it's not working. I've testing with ssh :
dsync_remote_cmd = ssh -l vmail %{host} doveadm
dsync-server -u%u
-l%{lock_timeout} -n%{namespace}
mail_replica =
remote:vm...@server2.domain.com
as well as with straight tcp (SSL
for
later)
mail_replica = tcp:server2.domain.com:999
/var/log/mail.err shows the problems ...
Jun 3 11:30:53 server1
dovecot: auth: Error: Trying to iterate users, but userdbs don't support
it
Jun 3 11:30:53 server1 dovecot: replicator: Error: User listing
returned failure
Jun 3 11:30:53 server1 dovecot: replicator: Error:
listing users failed, can't replicate existing data
Anyone else
have it working ? I'm sure it's something simple that I've just
overlooked.
