Re: [Bug] Mailbox aliases still broken

[Benny Pedersen]

On 2016-09-18 21:25, Aki Tuomi wrote:


We will take a look at it. Thank you for taking the time to remind
about this and sorry for lack of reply.


also postfix virtual alias to dovecot quota mailbox gives problems if 
the alias in postfix is not a mailbox, then dovecot says mailbox does 
not exists, and tell to reject it in postfix, but the error is just thst 
qouta plugin does not know postfix virtual aliases


carefull with the auth on aliases btw

Re: [Bug] Mailbox aliases still broken

[Aki Tuomi]

> On September 18, 2016 at 9:49 PM azu...@pobox.sk wrote:
> 
> 
> Hi,
> 
> about an year ago i was reporting a bug in mailbox aliases, which  
> remains unfixed and unasnwered (probably totally ignored, don't  
> understand why). I thought it was because the bug is old and already  
> fixed but yesterday i upgraded to Dovecot 2.2.24 and problem persists.
> 
> Here is the original report, everything, except the Dovecot version,  
> is still correct:
> http://dovecot.org/list/dovecot/2015-June/101176.html
> 
> Will this be fixed? Thanks for info.
> 
> azur

We will take a look at it. Thank you for taking the time to remind about this 
and sorry for lack of reply. 

Aki

[Bug] Mailbox aliases still broken

[azurit]

Hi,

about an year ago i was reporting a bug in mailbox aliases, which  
remains unfixed and unasnwered (probably totally ignored, don't  
understand why). I thought it was because the bug is old and already  
fixed but yesterday i upgraded to Dovecot 2.2.24 and problem persists.


Here is the original report, everything, except the Dovecot version,  
is still correct:

http://dovecot.org/list/dovecot/2015-June/101176.html

Will this be fixed? Thanks for info.

azur

Re: BUG - DELETE Public/Folder not working with Thunderbird

[Leander Schäfer]

Alright. Thank you

Am 17.09.16 um 17:20 schrieb Anton Yuzhaninov:

On 2016-09-16 16:13, Leander Schäfer wrote:

Thank you very much for your helpful hint. Thunderbird clearly wants to
move Public/Test to the Trash of the user who subscribed the Public
folder. Question is how to solve this from a Dovecot point of a view, so
a user can also delete folders?



31432704[11f53e080]: 1f581800:192.168.10.52:A:SendData: 17 rename
"Public/Test" "Trash/Test"
31432704[11f53e080]: ReadNextLine [stream=2ac7e870 nb=91 needmore=0]
31432704[11f53e080]: 1f581800:192.168.10.52:A:CreateNewLineFromSocket:
17 NO [CANNOT] Renaming not supported across non-private namespaces
(0.000 + 0.000 secs).


I don't sure something can be done by dovecot in this situation. You
have to try workarounds in Thunderbird:
http://kb.mozillazine.org/IMAP_folder_cannot_be_deleted

I personally think, that MUA should delete folder (not rename) if
folder is empty.

Re: Panic: file auth-request.c

[Chris Wik]

From:   Aki Tuomi  

 To:   Dovecot Mailing List , Chris Wik  
 Sent:   18/09/2016 8:06 AM 
 Subject:   Re: Panic: file auth-request.c 

 
> Sep 17 19:34:57 mail dovecot: auth: Panic: file auth-request.c: line 1049 
> (auth_request_lookup_credentials): assertion failed: 
> (request->credentials_scheme == scheme) 
> Sep 17 19:34:57 mail dovecot: auth: Error: Raw backtrace: 
> /usr/local/lib/dovecot/libdovecot.so.0(+0x89470) [0x7fa9cb8af470] -> 
> /usr/local/lib/dovecot/libdovecot.so.0(+0x8954e) [0x7fa9cb8af54e] -> 
> /usr/local/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7fa9cb851f75] -> 
> dovecot/auth() [0x4165bc] -> dovecot/auth() [0x4221fb] -> dovecot/auth() 
> [0x41620b] -> dovecot/auth(auth_request_lookup_credentials_callback+0x58) 
> [0x4162f8] -> dovecot/auth(passdb_handle_credentials+0x6a) [0x4254ba] -> 
> dovecot/auth() [0x425b62] -> dovecot/auth() [0x41c1f8] -> 
> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x4c) [0x7fa9cb8c207c] 
> -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0xd7) 
> [0x7fa9cb8c3377] -> 
> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x25) 
> [0x7fa9cb8c2105] -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) 
> [0x7fa9cb8c22b8] -> 
> /usr/local/lib/dovecot/libdovecot.so.0(master_service_run+0x13) 
> [0x7fa9cb857f33] -> dovecot/auth(main+0x2eb 
 ) [0x40ccdb] -> /lib64/libc.so.6(__libc_start_main+0xf5) [0x7fa9c9dc2b15] -> 
dovecot/auth() [0x40cf15] 

 
Hi! 
 
This has been fixed with 
https://github.com/dovecot/core/commit/6c969ac21a43cc10ee1f1a91a4f39e4864c886cb 
 
Aki Tuomi 
Dovecot oy 


Great, good to hear!


In my local source of 2.2.5, the deleted lines are lines 1048-1049. In the 
patch the lines are 1068-1069. I think maybe we'll wait for 2.2.6 and not try 
to patch it ourselves, we aren't using the new features in 2.2.5 yet and 2.2.4 
has been stable for us...


Chris

--
Chris Wik
Anu Internet Services
www.anu.net | www.cwik.ch

Re: Panic: file auth-request.c

[Aki Tuomi]

> On September 17, 2016 at 9:15 PM Chris Wik  wrote:
> 
> 
> 
> Hello Dovecot list,
> 
> 
> We've been running a really old CentOS 5 server with the stock dovecot from 
> yum (1.0.7) for years and years with absolutely no problems. If it ain't 
> broke, don't fix it, or something like that.
> 
> 
> Well it finally broke, but only due to the server no longer being able to 
> handle the load of the increasing user base (many thousands now, with 
> hundreds of concurrent IMAP connections any any given time)
> 
> 
> So we upgraded to a new CentOS 7 server with SSD RAID, fast CPUs and tons of 
> RAM. No more load problems. We compiled the latest dovecot from source (as 
> the version from CentOS yum repo is already quite old, figure we might as 
> well run the latest version since we were upgrading anyway).
> 
> 
> Thanks to excellent documentation on dovecot.org and fairly thorough testing, 
> the upgrade was quite smooth. We kept all the message UUIDs intact and tried 
> to match the supported authentication methods etc to the old setup, and we 
> didn't have any problems with clients re-downloading or re-syncing mail.
> 
> 
> We do however have one problem, which prompted me to join this list. It is 
> the same problem as described in this thread from last month: 
> http://dovecot.org/list/dovecot/2016-July/104899.html
> 
> 
> Here's the excerpt from our maillog:
> 
> 
> Sep 17 19:34:57 mail dovecot: auth: Panic: file auth-request.c: line 1049 
> (auth_request_lookup_credentials): assertion failed: 
> (request->credentials_scheme == scheme)
> Sep 17 19:34:57 mail dovecot: auth: Error: Raw backtrace: 
> /usr/local/lib/dovecot/libdovecot.so.0(+0x89470) [0x7fa9cb8af470] -> 
> /usr/local/lib/dovecot/libdovecot.so.0(+0x8954e) [0x7fa9cb8af54e] -> 
> /usr/local/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7fa9cb851f75] -> 
> dovecot/auth() [0x4165bc] -> dovecot/auth() [0x4221fb] -> dovecot/auth() 
> [0x41620b] -> dovecot/auth(auth_request_lookup_credentials_callback+0x58) 
> [0x4162f8] -> dovecot/auth(passdb_handle_credentials+0x6a) [0x4254ba] -> 
> dovecot/auth() [0x425b62] -> dovecot/auth() [0x41c1f8] -> 
> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x4c) [0x7fa9cb8c207c] 
> -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0xd7) 
> [0x7fa9cb8c3377] -> 
> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x25) 
> [0x7fa9cb8c2105] -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) 
> [0x7fa9cb8c22b8] -> 
> /usr/local/lib/dovecot/libdovecot.so.0(master_service_run+0x13) 
> [0x7fa9cb857f33] -> dovecot/auth(main+0x2eb
 ) [0x40ccdb] -> /lib64/libc.so.6(__libc_start_main+0xf5) [0x7fa9c9dc2b15] -> 
dovecot/auth() [0x40cf15]
> 
> 
> On the client side, it manifests as an authentication failure, and the user 
> is prompted to re-enter their password. The reports we've had are all from 
> users who have their passwords saved in a local password manager, so the 
> client is definitely sending the correct password. It's not related to a 
> particular mail client. It is also definitely not related to the particular 
> user or password, as the user will authenticate many times successfully and 
> then (seemingly) randomly be hit by this bug and prompted to re-enter their 
> password.
> 
> 
> We enabled verbose logging and even logging of passwords for failed 
> authentication attempts in an attempt to find a pattern, but so far we have 
> not found one.
> 
> 
> Similar to the original poster in the above thread, we are using a MySQL 
> backend, and CentOS 7 on x86_64
> 
> 
> It happens quite frequently: in the past 6 days it happened 49175 times, 
> according to a grep of the maillog. In the same period there were 294167 
> successful IMAP logins and 160322 POP3 logins.
> 
> 
> For now we have downgraded to 2.2.4 and so far have not seen the crash 
> recorded in the maillog.
> 
> 
> What can we do to help track down and fix this bug?
> 
> 
> 
> # dovecot -n
> # 2.2.24 (a82c823): /usr/local/etc/dovecot/dovecot.conf
> # OS: Linux 3.10.0-327.28.3.el7.x86_64 x86_64 CentOS Linux release 7.2.1511 
> (Core)  ext4
> auth_debug = yes
> auth_debug_passwords = yes
> auth_mechanisms = plain login digest-md5 cram-md5 ntlm rpa apop
> auth_verbose = yes
> auth_verbose_passwords = plain
> debug_log_path = /var/log/dovecot-debug.log
> default_client_limit = 5000
> default_process_limit = 1000
> disable_plaintext_auth = no
> first_valid_uid = 89
> mail_debug = yes
> mail_fsync = never
> mail_gid = 89
> mail_location = maildir:/var/virtual/%d/%n
> mail_uid = 89
> 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 = 
> }
> passdb {
>   args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
>   driver = sql
> }