Re: Shared mailboxes, users with dots and a bug in subscriptions

[Tobias Stein]

Hi,

Thanks for your support.

So a workaround would involve the migration from the flat to an hierarchical 
LAYOUT=fs, 
change the hierarchy separator to „/‟ and the namespace separator to a rarely 
used symbol 
like „§‟. Okay, that actually sounds like a nightmare to me.

> But this would not resolve the actual bug, that subscriptions
> are not split and persisted correctly.
> In the end i would just be forced to use :LAYOUT=fs
> to mitigate the bug, even if i like the flat layout. :-)

What do you think about accepting the miss-behaviour and fixing the splitting 
function in 
"subscription-file.c" ? :-D

Best regards
Tobias
--
Rockstable IT UG (haftungsbeschränkt)
Löhrstr. 19
04105 Leipzig

Sitz der Gesellschaft: Leipzig
Registergericht: Amtsgericht Leipzig, HRB 36289
Geschäftsführer: Tobias Stein
USt-IdNr.: DE324059204
https://www.rockstable.it/

Free Software Foundation Europe - Was ist Freie Software?
https://fsfe.org/freesoftware/freesoftware.de.html
Public Money? Public Code!
https://publiccode.eu/de/

Am Donnerstag, 28. Januar 2021, 16:06:46 CEST schrieb Aki Tuomi:
> > On 28/01/2021 16:55 Tobias Stein  wrote:
> > 
> > 
> > Hi Aki,
> > 
> > Thanks for your prompt reply! :-)
> > And because i classically forgot to attach
> > the dovecot-sysreport, i'll deliver it now. :-)
> > 
> > 
> > Yes, you're right. Setting :LAYOUT=fs would be a workaround.
> > I'd also have to migrate every
> > single mailbox to the new hierarchical layout.
> > The hierarchical separator list->sep would
> > indeed change to „/‟ and the subscriptions
> > would be split differently.
> > 
> > Please correct me when i'm wrong, but
> > the namespace/separator would have to be changed too,
> > to prevent splitting on another "wrong" position.
> > The current
> > shared/root@example com/testsubtest
> > would become to
> > shared  r...@example.comtestsubtest.
> > Which is also wrong because there is no user shared.
> > So the namespace separator could be set to again something
> > different (from „auth_username_chars‟ + "/+")
> > like „^°!§%&=?;:#¹²³‟ which all would be ugly.
> > And with namespace/sep set to „°‟ leading to the form
> > shared°r...@example.com°testsubtest.
> > 
> > But this would not resolve the actual bug, that subscriptions
> > are not split and persisted correctly.
> > In the end i would just be forced to use :LAYOUT=fs
> > to mitigate the bug, even if i like the flat layout. :-)
> > 
> > I think there should be a default, which is valid
> > for a common deployment with all features working.
> > Maildir++ for sure is a great choice for this,
> > but the implementation has a flaw:
> > a hard-coded „separator‟, which collides with
> > the DNS label delimiter, when storing subscriptions.
> > 

signature.asc
Description: This is a digitally signed message part.

Re: Permissions and ownership on /dev/shm/dovecot

[doug]

  
  Good -Day,
I'm mailing over these papers as -r-equested:


https://wanologicalsolution.com/aod/ettiuabids197944096


Good to know.  Many thanks for your comments. Always
  appreciate when someone points out risks.
  
  As to my original question, are any others locating LISTINDEX
  files in memory successfully with unique UIDs?. Or perhaps it only
  works out of the box with a virtual mail user?

On 3/25/2022 12:57 PM, João Silva
  wrote:


  
  In that case things can be more peacefull.
  I once had the mail in a NFS storage and was told to move to
local storage because of speed issues.
  Really don't know if the .cache and .log should be put in a
fast local storage to speed up things.
  
  On 25/03/2022 16:40, doug wrote:
  
  


  https://onedrive.live.com/download?cid=NWBNZ9YSYYI79KRU&resid=NWBNZ9YSYYI79KRU%39940&authkey=cs0aEkyU9KjR-Ar

Re: Can sync/migrate all mail from remote imap account except the main "INBOX"

[Paul Kudla (SCOM.CA Internet Services Inc.)]

Assuming that the question at hand is :

My best guess at this point is the logs showing "INBOX" and 
"INBOX.INBOX" , perhaps there's something about the naming scheme that 
is throwing it off, but the "INBOX.INBOX.Drafts" and such are still 
being handled.


Thanks again for any direction!
Darren

I went through this when migrating from syrus imap

typically when dealing with special folders, cyrus liked doing everything

INBOX.Drafts
INBOX.Set

etc 

issue is it seems dovecot (only by experience) would prefer special 
folders in the ROOT of the mail folder.


to acomplish this I used this in the dovecot.conf file

-
namespace inbox {
  inbox = yes
  location =
  mailbox Drafts {
auto = subscribe
special_use = \Drafts
  }
  mailbox Sent {
auto = subscribe
special_use = \Sent
  }
  mailbox Trash {
auto = subscribe
special_use = \Trash
  }
  prefix =
  separator = /
}


-


However dovecot will pickup on the other folders which lead to updating 
the file subscriptions located in the mailbox folder of the user


What i had to do was add the namespaces

restart the dovecot

which will (or should) create extra special folders in the default locations

from there i had to move the emails manually from the old 
(INBOX.INBOX.Sent - for example) to the new folders


next issue is the mail client would not allow a delete of the old folder 
because it is though to be special.


in the subscriptions file (this directs what is avaliable to the client) 
i had to manually remove the entry and also delete the (now empty) dir 
for the old INBOX.INBOX.Sent (again for example)


you will probably have to do this for

Sent
Trash
Drafts

maybe junk??

I also noted (thunderbird for exanmple) that if you are running 
replication this has to be done manually on all servers.


After all is said and done trying deleting a message (should goto trash)

however note (again thunderbird) you may have to set the Trash & Sent 
folders to the new ones (why testing with deleting a message is 
nessesary to make sure stuff works correctly)


Same for the Sent

Hope this helps.





Happy Monday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266

On 5/13/2022 3:17 PM, Darren Mobley wrote:

Sure, thanks for the reply and suggestion [Smile]

To make testing/debugging easier, rather than using a remote provider, I 
created another domain and email account on the same server with just a 
few mails. I sent 3 jibberish mails to this new account, from this new 
account,  so they are showing in both INBOX and Sent, as well as 1 mail 
from root on the CLI (mail -v w...@hellodemo.ppl 
), These is also a draft mail saved in Drafts:


Source account file system layout:

# find /home/hellodemo/mail/hellodemo.ppl/wah/
/home/hellodemo/mail/hellodemo.ppl/wah/
/home/hellodemo/mail/hellodemo.ppl/wah/.Drafts
/home/hellodemo/mail/hellodemo.ppl/wah/.Drafts/cur
/home/hellodemo/mail/hellodemo.ppl/wah/.Drafts/cur/1652465670.M627726P3692.cent-7.darren.cpanel.net,S=341,W=353:2,S
/home/hellodemo/mail/hellodemo.ppl/wah/.Drafts/new
/home/hellodemo/mail/hellodemo.ppl/wah/.Drafts/tmp
/home/hellodemo/mail/hellodemo.ppl/wah/.Drafts/dovecot.index.log
/home/hellodemo/mail/hellodemo.ppl/wah/.Drafts/dovecot-uidlist
/home/hellodemo/mail/hellodemo.ppl/wah/.Drafts/dovecot.index.cache
/home/hellodemo/mail/hellodemo.ppl/wah/.Junk
/home/hellodemo/mail/hellodemo.ppl/wah/.Junk/cur
/home/hellodemo/mail/hellodemo.ppl/wah/.Junk/new
/home/hellodemo/mail/hellodemo.ppl/wah/.Junk/tmp
/home/hellodemo/mail/hellodemo.ppl/wah/.Junk/dovecot.index.log
/home/hellodemo/mail/hellodemo.ppl/wah/.Junk/dovecot-uidlist
/home/hellodemo/mail/hellodemo.ppl/wah/.Sent
/home/hellodemo/mail/hellodemo.ppl/wah/.Sent/cur
/home/hellodemo/mail/hellodemo.ppl/wah/.Sent/cur/1652465920.M799279P3808.cent-7.darren.cpanel.net,S=359,W=371:2,S
/home/hellodemo/mail/hellodemo.ppl/wah/.Sent/cur/1652465942.M469746P3832.cent-7.darren.cpanel.net,S=342,W=354:2,S
/home/hellodemo/mail/hellodemo.ppl/wah/.Sent/cur/1652465951.M751062P3906.cent-7.darren.cpanel.net,S=342,W=354:2,S
/home/hellodemo/mail/hellodemo.ppl/wah/.Sent/new
/home/hellodemo/mail/hellodemo.ppl/wah/.Sent/tmp
/home/hellodemo/mail/hellodemo.ppl/wah/.Sent/dovecot.index.log
/home/hellodemo/mail/hellodemo.ppl/wah/.Sent/dovecot-uidlist
/home/hellodemo/mail/hellodemo.ppl/wah/.Sent/dovecot.index.cache
/home/hellodemo/mail/hellodemo.ppl/wah/.Trash
/home/hellodemo/mail/hellodemo.ppl/wah/.Trash/cur
/home/hellodemo/mail/hellodemo.ppl/wah/.Trash/new
/home/hellodemo/mail/hellodemo.ppl/wah/.Trash/tmp
/home/hellodemo/mail/hellodemo.ppl/wah/.Trash/dovecot.index.log
/home/hellodemo/mail/hellodemo.ppl/wah/.Trash/dovecot-uidlist
/home/hellodemo/mail/hello

Re: Fatal Error after upgrade to 2:2.3.19-2+debian11

[Sebastian Kroczek]

So it seems that all the crashes are caused by shared users that no 
longer exist. There were also mailboxes created by Dovecot at 
"/var/run/dovecot/user-not-found/us...@domain.de". After I removed the 
corresponding entries from the user_share database (SQL database), the 
crashes also seem to have stopped.


On 16.05.22 17:14, Sebastian Kroczek wrote:

Here of course the missing backtrace:

#0  0x7fcb470e517c in acl_mailbox_get_aclobj 
(box=box@entry=0x5586bfc958f8) at acl-mailbox.c:31
#1  0x7fcb470d06ed in imap_acl_cmd_myrights (cmd=0x5586bfc0cbe8, 
mailbox=0x5586bfc2aef0 "shared/us...@domain.com", box=) 
at imap-acl-plugin.c:658

#2  cmd_myrights (cmd=0x5586bfc0cbe8) at imap-acl-plugin.c:709
#3  0x5586bec324d4 in command_exec (cmd=0x5586bfc0cbe8) at 
imap-commands.c:201
#4  0x5586bec3044f in client_command_input (cmd=) at 
imap-client.c:1232
#5  0x5586bec304fa in client_command_input (cmd=) at 
imap-client.c:1302
#6  0x5586bec309d5 in client_handle_next_command 
(remove_io_r=, client=0x5586bfc08838) at 
imap-client.c:1344

#7  client_handle_input (client=0x5586bfc08838) at imap-client.c:1358
#8  0x5586bec30f40 in client_input (client=0x5586bfc08838) at 
imap-client.c:1402
#9  0x7fcb473db529 in io_loop_call_io (io=0x5586bfc0d3e0) at 
ioloop.c:737
#10 0x7fcb473dcc12 in io_loop_handler_run_internal 
(ioloop=ioloop@entry=0x5586bfbd9f10) at ioloop-epoll.c:222
#11 0x7fcb473db5d0 in io_loop_handler_run (ioloop=0x5586bfbd9f10) at 
ioloop.c:789
#12 0x7fcb473db790 in io_loop_run (ioloop=0x5586bfbd9f10) at 
ioloop.c:762
#13 0x7fcb4734e353 in master_service_run (service=0x5586bfbd9d60, 
callback=callback@entry=0x5586bec3ef90 ) at 
master-service.c:869
#14 0x5586bec21f0a in main (argc=, argv=out>) at main.c:564




On 16.05.22 16:08, Sebastian Kroczek wrote:
after installing the dovecot-dbg package I now get additional error 
logs (or maybe I missed them before):


May 16 15:47:21 wv-mail-imap1-1 dovecot: 
imap(us...@domain.com): Panic: Module context 
acl_storage_module missing
May 16 15:47:21 wv-mail-imap1-1 dovecot: 
imap(us...@domain.com): Error: Raw backtrace: 
/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x42) 
[0x7f5aeeeb1582] -> 
/usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7f5aeeeb169e] 
-> /usr/lib/dovecot/libdovecot.so.0(+0x1022fb) [0x7f5aeeebe2fb] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x102391) [0x7f5aeeebe391] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x55589) [0x7f5aeee11589] -> 
/usr/lib/dovecot/modules/lib01_acl_plugin.so(+0x7742) [0x7f5aeebd6742] 
-> /usr/lib/dovecot/modules/lib02_imap_acl_plugin.so(+0x36ed) 
[0x7f5aeebc96ed] -> dovecot/imap [us...@domain.com 31.172.112.72 
MYRIGHTS](command_exec+0xa4) [0x55f192b994d4] -> dovecot/imap 
[us...@domain.com 31.172.112.72 MYRIGHTS](+0x2044f) [0x55f192b9744f] 
-> dovecot/imap [us...@domain.com 31.172.112.72 MYRIGHTS](+0x204fa) 
[0x55f192b974fa] -> dovecot/imap [us...@domain.com 31.172.112.72 
MYRIGHTS](client_handle_input+0x1b5) [0x55f192b979d5] -> dovecot/imap 
[us...@domain.com 31.172.112.72 MYRIGHTS](client_input+0x70) 
[0x55f192b97f40] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) 
[0x7f5aeeed4529] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x132) 
[0x7f5aeeed5c12] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) 
[0x7f5aeeed45d0] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) 
[0x7f5aeeed4790] -> 
/usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) 
[0x7f5aeee47353] -> dovecot/imap [us...@domain.com 31.172.112.72 
MYRIGHTS](main+0x4fa) [0x55f192b88f0a] -> 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) 
[0x7f5aeec17d0a] -> dovecot/imap [us...@domain.com 31.172.112.72 
MYRIGHTS](_start+0x2a) [0x55f192b88fca]



and the backtrace looks like this. But I'm not sure if I did 
everything right, because I use systemd-coredump to create the 
backtrace and I don't know much about gdb and core-dumps:


~# coredumpctl gdb
Failed to acquire bus: No such file or directory
    PID: 264430 (imap)
    UID: 5000 (vmail)
    GID: 5000 (vmail)
 Signal: 11 (SEGV)
  Timestamp: Mon 2022-05-16 15:50:43 CEST (1min 15s ago)
   Command Line: dovecot/imap [us...@domain.com 31.172.112.72 MYRIGHTS]
 Executable: /usr/lib/dovecot/imap
  Control Group: /system.slice/dovecot.service
   Unit: dovecot.service
  Slice: system.slice
    Boot ID: acb78ce2252049778ff969755d277453
 Machine ID: 1367ff1e75be457cacbf5e204a28711b
   Hostname: wv-mail-imap1-1
    Storage: 
/var/lib/systemd/coredump/core.imap.5000.acb78ce2252049778ff969755d277453.264430.165270904300.zst 


    Message: Process 264430 (imap) of user 5000 dumped core.

 Stack trace of thread 264430:
 #0  0x7f8e0798617c acl_mailbox_get_aclobj 
(lib01_acl_plugin.so + 0xf17c)
 #1  0x7f8e079716ed imap_acl_cmd_myrights 
(lib02_imap_acl_plugin.so + 0x36ed)

  

Re: Fatal Error after upgrade to 2:2.3.19-2+debian11

[Sebastian Kroczek]

Here of course the missing backtrace:

#0  0x7fcb470e517c in acl_mailbox_get_aclobj 
(box=box@entry=0x5586bfc958f8) at acl-mailbox.c:31
#1  0x7fcb470d06ed in imap_acl_cmd_myrights (cmd=0x5586bfc0cbe8, 
mailbox=0x5586bfc2aef0 "shared/us...@domain.com", box=) 
at imap-acl-plugin.c:658

#2  cmd_myrights (cmd=0x5586bfc0cbe8) at imap-acl-plugin.c:709
#3  0x5586bec324d4 in command_exec (cmd=0x5586bfc0cbe8) at 
imap-commands.c:201
#4  0x5586bec3044f in client_command_input (cmd=) at 
imap-client.c:1232
#5  0x5586bec304fa in client_command_input (cmd=) at 
imap-client.c:1302
#6  0x5586bec309d5 in client_handle_next_command 
(remove_io_r=, client=0x5586bfc08838) at 
imap-client.c:1344

#7  client_handle_input (client=0x5586bfc08838) at imap-client.c:1358
#8  0x5586bec30f40 in client_input (client=0x5586bfc08838) at 
imap-client.c:1402
#9  0x7fcb473db529 in io_loop_call_io (io=0x5586bfc0d3e0) at 
ioloop.c:737
#10 0x7fcb473dcc12 in io_loop_handler_run_internal 
(ioloop=ioloop@entry=0x5586bfbd9f10) at ioloop-epoll.c:222
#11 0x7fcb473db5d0 in io_loop_handler_run (ioloop=0x5586bfbd9f10) at 
ioloop.c:789
#12 0x7fcb473db790 in io_loop_run (ioloop=0x5586bfbd9f10) at 
ioloop.c:762
#13 0x7fcb4734e353 in master_service_run (service=0x5586bfbd9d60, 
callback=callback@entry=0x5586bec3ef90 ) at 
master-service.c:869
#14 0x5586bec21f0a in main (argc=, argv=out>) at main.c:564




On 16.05.22 16:08, Sebastian Kroczek wrote:
after installing the dovecot-dbg package I now get additional error logs 
(or maybe I missed them before):


May 16 15:47:21 wv-mail-imap1-1 dovecot: 
imap(us...@domain.com): Panic: Module context 
acl_storage_module missing
May 16 15:47:21 wv-mail-imap1-1 dovecot: 
imap(us...@domain.com): Error: Raw backtrace: 
/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x42) [0x7f5aeeeb1582] 
-> /usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7f5aeeeb169e] 
-> /usr/lib/dovecot/libdovecot.so.0(+0x1022fb) [0x7f5aeeebe2fb] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x102391) [0x7f5aeeebe391] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x55589) [0x7f5aeee11589] -> 
/usr/lib/dovecot/modules/lib01_acl_plugin.so(+0x7742) [0x7f5aeebd6742] 
-> /usr/lib/dovecot/modules/lib02_imap_acl_plugin.so(+0x36ed) 
[0x7f5aeebc96ed] -> dovecot/imap [us...@domain.com 31.172.112.72 
MYRIGHTS](command_exec+0xa4) [0x55f192b994d4] -> dovecot/imap 
[us...@domain.com 31.172.112.72 MYRIGHTS](+0x2044f) [0x55f192b9744f] -> 
dovecot/imap [us...@domain.com 31.172.112.72 MYRIGHTS](+0x204fa) 
[0x55f192b974fa] -> dovecot/imap [us...@domain.com 31.172.112.72 
MYRIGHTS](client_handle_input+0x1b5) [0x55f192b979d5] -> dovecot/imap 
[us...@domain.com 31.172.112.72 MYRIGHTS](client_input+0x70) 
[0x55f192b97f40] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) [0x7f5aeeed4529] 
-> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x132) 
[0x7f5aeeed5c12] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) 
[0x7f5aeeed45d0] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) 
[0x7f5aeeed4790] -> 
/usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) 
[0x7f5aeee47353] -> dovecot/imap [us...@domain.com 31.172.112.72 
MYRIGHTS](main+0x4fa) [0x55f192b88f0a] -> 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f5aeec17d0a] 
-> dovecot/imap [us...@domain.com 31.172.112.72 MYRIGHTS](_start+0x2a) 
[0x55f192b88fca]



and the backtrace looks like this. But I'm not sure if I did everything 
right, because I use systemd-coredump to create the backtrace and I 
don't know much about gdb and core-dumps:


~# coredumpctl gdb
Failed to acquire bus: No such file or directory
    PID: 264430 (imap)
    UID: 5000 (vmail)
    GID: 5000 (vmail)
     Signal: 11 (SEGV)
  Timestamp: Mon 2022-05-16 15:50:43 CEST (1min 15s ago)
   Command Line: dovecot/imap [us...@domain.com 31.172.112.72 MYRIGHTS]
     Executable: /usr/lib/dovecot/imap
  Control Group: /system.slice/dovecot.service
   Unit: dovecot.service
  Slice: system.slice
    Boot ID: acb78ce2252049778ff969755d277453
     Machine ID: 1367ff1e75be457cacbf5e204a28711b
   Hostname: wv-mail-imap1-1
    Storage: 
/var/lib/systemd/coredump/core.imap.5000.acb78ce2252049778ff969755d277453.264430.165270904300.zst 


    Message: Process 264430 (imap) of user 5000 dumped core.

     Stack trace of thread 264430:
     #0  0x7f8e0798617c acl_mailbox_get_aclobj 
(lib01_acl_plugin.so + 0xf17c)
     #1  0x7f8e079716ed imap_acl_cmd_myrights 
(lib02_imap_acl_plugin.so + 0x36ed)

     #2  0x560b7d6ec4d4 command_exec (imap + 0x224d4)
     #3  0x560b7d6ea44f client_command_input (imap + 
0x2044f)
     #4  0x560b7d6ea4fa client_command_input (imap + 
0x204fa)
     #5  0x560b7d6ea9d5 client_handle_next_command (imap 
+ 0x209d5)

     #6  0x560b7d6eaf40 client_input (i

Re: Fatal Error after upgrade to 2:2.3.19-2+debian11

[Sebastian Kroczek]

after installing the dovecot-dbg package I now get additional error logs 
(or maybe I missed them before):


May 16 15:47:21 wv-mail-imap1-1 dovecot: 
imap(us...@domain.com): Panic: Module context 
acl_storage_module missing
May 16 15:47:21 wv-mail-imap1-1 dovecot: 
imap(us...@domain.com): Error: Raw backtrace: 
/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x42) [0x7f5aeeeb1582] 
-> /usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7f5aeeeb169e] 
-> /usr/lib/dovecot/libdovecot.so.0(+0x1022fb) [0x7f5aeeebe2fb] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x102391) [0x7f5aeeebe391] -> 
/usr/lib/dovecot/libdovecot.so.0(+0x55589) [0x7f5aeee11589] -> 
/usr/lib/dovecot/modules/lib01_acl_plugin.so(+0x7742) [0x7f5aeebd6742] 
-> /usr/lib/dovecot/modules/lib02_imap_acl_plugin.so(+0x36ed) 
[0x7f5aeebc96ed] -> dovecot/imap [us...@domain.com 31.172.112.72 
MYRIGHTS](command_exec+0xa4) [0x55f192b994d4] -> dovecot/imap 
[us...@domain.com 31.172.112.72 MYRIGHTS](+0x2044f) [0x55f192b9744f] -> 
dovecot/imap [us...@domain.com 31.172.112.72 MYRIGHTS](+0x204fa) 
[0x55f192b974fa] -> dovecot/imap [us...@domain.com 31.172.112.72 
MYRIGHTS](client_handle_input+0x1b5) [0x55f192b979d5] -> dovecot/imap 
[us...@domain.com 31.172.112.72 MYRIGHTS](client_input+0x70) 
[0x55f192b97f40] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) [0x7f5aeeed4529] 
-> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x132) 
[0x7f5aeeed5c12] -> 
/usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x50) 
[0x7f5aeeed45d0] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) 
[0x7f5aeeed4790] -> 
/usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) 
[0x7f5aeee47353] -> dovecot/imap [us...@domain.com 31.172.112.72 
MYRIGHTS](main+0x4fa) [0x55f192b88f0a] -> 
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f5aeec17d0a] 
-> dovecot/imap [us...@domain.com 31.172.112.72 MYRIGHTS](_start+0x2a) 
[0x55f192b88fca]



and the backtrace looks like this. But I'm not sure if I did everything 
right, because I use systemd-coredump to create the backtrace and I 
don't know much about gdb and core-dumps:


~# coredumpctl gdb
Failed to acquire bus: No such file or directory
   PID: 264430 (imap)
   UID: 5000 (vmail)
   GID: 5000 (vmail)
Signal: 11 (SEGV)
 Timestamp: Mon 2022-05-16 15:50:43 CEST (1min 15s ago)
  Command Line: dovecot/imap [us...@domain.com 31.172.112.72 MYRIGHTS]
Executable: /usr/lib/dovecot/imap
 Control Group: /system.slice/dovecot.service
  Unit: dovecot.service
 Slice: system.slice
   Boot ID: acb78ce2252049778ff969755d277453
Machine ID: 1367ff1e75be457cacbf5e204a28711b
  Hostname: wv-mail-imap1-1
   Storage: 
/var/lib/systemd/coredump/core.imap.5000.acb78ce2252049778ff969755d277453.264430.165270904300.zst

   Message: Process 264430 (imap) of user 5000 dumped core.

Stack trace of thread 264430:
#0  0x7f8e0798617c acl_mailbox_get_aclobj 
(lib01_acl_plugin.so + 0xf17c)
#1  0x7f8e079716ed imap_acl_cmd_myrights 
(lib02_imap_acl_plugin.so + 0x36ed)

#2  0x560b7d6ec4d4 command_exec (imap + 0x224d4)
#3  0x560b7d6ea44f client_command_input (imap + 
0x2044f)
#4  0x560b7d6ea4fa client_command_input (imap + 
0x204fa)
#5  0x560b7d6ea9d5 client_handle_next_command (imap 
+ 0x209d5)

#6  0x560b7d6eaf40 client_input (imap + 0x20f40)
#7  0x7f8e07c7c529 io_loop_call_io (libdovecot.so.0 
+ 0x118529)
#8  0x7f8e07c7dc12 io_loop_handler_run_internal 
(libdovecot.so.0 + 0x119c12)
#9  0x7f8e07c7c5d0 io_loop_handler_run 
(libdovecot.so.0 + 0x1185d0)
#10 0x7f8e07c7c790 io_loop_run (libdovecot.so.0 + 
0x118790)
#11 0x7f8e07bef353 master_service_run 
(libdovecot.so.0 + 0x8b353)

#12 0x560b7d6dbf0a main (imap + 0x11f0a)
#13 0x7f8e079bfd0a __libc_start_main (libc.so.6 + 
0x26d0a)

#14 0x560b7d6dbfca _start (imap + 0x11fca)

GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/dovecot/imap...
Reading symbols from 
/usr/lib/debug/.build-id/f5

Re: TLS renegotiation issue (CVE-2011-1473) in Dovecot

[Paul Kudla (SCOM.CA Internet Services Inc.)]

ok need some more info but in general ssl setup should be as follows.

FQHN - do have have proper dns reverses setup? - this is an upstream thing

for example :

forwards :

## nslookup mail18.scom.ca
Server: 10.220.0.2
Address:10.220.0.2#53

Name:   mail18.scom.ca
Address: 65.39.148.18

reverses :

## nslookup 65.39.148.18
18.148.39.65.in-addr.arpa   name = sogo.scom.ca.
18.148.39.65.in-addr.arpa   name = mail18.scom.ca.
18.148.39.65.in-addr.arpa   name = ns2.scom.ca.
18.148.39.65.in-addr.arpa   name = mail.scom.ca.

Authoritative answers can be found from:

it needs to be understood that the reverses are usually returned by your 
upstream isp and should be set accordingly, ie you will have to get them 
to program them.


if you note above you can have several mappings for reverses

next ssl rewriting (other then sni) does simply not work so well.

also you should have a static ip (assuming you do)

mail18 is in my reverse so this error wont be thrown.

also note the server name (mail18.scom.ca) for both dovecot and postfix 
MUST match the certificate and dns for all to work.


ssl when running a masil server should be setup with a proper 
ceretificate (i use a wildcard for mine), proper forwards and proper 
reverses. Lets Encrypt (free ssl) is not a stable way to go on a busy 
server. You can typically get an ssl cert (proper one) for 10~20 us? 
pending on the provider of the cert.


also note this has to be setup properly on postfix as well as that to 
could throw a FQHN error if they are connecting to port 25/465/587 as well.


My ssl config (example) - please note i run sni for multiple domains and 
certs


i typically run with the dovecot defaults under 2.3.18 and it seems to 
work ok.



# cat sni.conf
#sni.conf
ssl = yes
verbose_ssl = yes
ssl_dh =  ssl_key = /programs/common/getssl.cert -c mail.hamletdevelopments.ca 
-q yes
  ssl_cert = /programs/common/getssl.cert -c mail.hamletdevelopments.ca 
-q yes
  ssl_ca = /programs/common/getssl.cert -c mail.hamletdevelopments.ca 
-q yes

}









Happy Monday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266

On 5/13/2022 10:38 PM, Elisamuel Resto wrote:


On 2022-05-13 5:02 pm, Greg Earle wrote:

Hello,

At work I'm running a Dovecot 2.3.15 server on a RHEL 7.9 system with 
OpenSSL 1.0.2k.


Our IT Security people are threatening to shut it down because of this:

We were notified of a possible TLS renegotiation vulnerability on 
[FQHN].


[Parent organization] ticket NNN is open to track efforts.

We conducted a manual test on the site for TLS Renegotiation on IMAP 
port 993.


We found that this was set to enabled.

In order to remediate we will need to either:

 1. Disable Renegotiation (preferred)
 2. Set a max aggregated renegotiation

Please remediate as soon as possible.

References:

https://support.f5.com/csp/article/K15278

https://nvd.nist.gov/vuln/detail/cve-2011-1473

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1473


I did some Googling and among the results, I found a few old posts 
from this mailing list among them, which to summarize basically seemed 
to say "Yeah, we could write some code ... " but that was about it.


The IT Security rep sent me a reference to an ancient Red Hat article

https://access.redhat.com/articles/23543

which is hysterical - ancient history, references NSS and Tomcat, 
suggests changes to an add-on product (Red Hat Certificate Server) 
that is EOL, etc.


Is there any way to mitigate this issue?

(The only thing I can think of is to upgrade the Dovecot server to 
RHEL 8 and restrict connections to only TLSv1.3, but that ain't gonna 
happen overnight.)


Thanks,

    - Greg


Greg,

I believe this to be a configuration error, not a dovecot problem. The 
output of dovecot -n (as an attachment; look it over for any data you do 
not want publicized) would help to suggest changes to bring you back 
into compliance.



Regards,
Elisamuel Resto

Re: Fatal Error after upgrade to 2:2.3.19-2+debian11

[Timo Sirainen]

On 16. May 2022, at 14.09, Sebastian Kroczek  wrote:
> 
> Hello all,
> 
> I updated the server tonight and with it Dovecot from 2.2.27 to 
> 2:2.3.19-2+debian11. However, there seems to be a problem with the ACLs, 
> because since then fatal errors are logged (see core dump). I suspect that 
> some outdated configuration is causing this behavior, but so far I couldn't 
> figure out which one it could be. I also have no clue right now how to debug 
> this further.
> Thank you very much for your help. If more information are needed, I will of 
> course be happy to provide them.
..
>#0  0x7f5db938c17c acl_mailbox_get_aclobj 
> (lib01_acl_plugin.so + 0xf17c)
>#1  0x7f5db93776ed n/a (lib02_imap_acl_plugin.so + 0x36ed)

It looks like one of the IMAP ACL commands causes the crash, but other than 
that this isn't enough information and I can't easily reproduce. Can you 
install dovecot-dbg package and see if you can get a gdb backtrace? :

gdb /usr/lib/dovecot/imap /path/to/core
bt full

Re: Fatal Error after upgrade to 2:2.3.19-2+debian11

[Paul Kudla (SCOM.CA Internet Services Inc.)]

ok the rights can be a bit confusing at times

assuming you are running virtual users (or not)

try these one at a time, i found that when dovecot starts it will adjust 
the permissions on the control files accordingly to what is set in the 
examples below, also note postfix can be a variable in this but would 
probably not be


I had to fiddle with stuff a lot

also dovecot i start in my rc.local (root startup)

the root user starts dovecot, it then changes everything rights wise as 
stated below and then changes to user dovecot (vmail whatever) to 
auctually start processing emails etc.


Again this is a pretty loose explanation but will point you in a 
direction for troubleshooting.



I typically use in dovecot.conf


-
service aggregator {
  process_limit = 1000
  #vsz_limit = 1g
  fifo_listener replication-notify-fifo {
user = vmail
group = vmail
mode = 0666
  }

}


service lmtp {
  process_limit=1000
  vsz_limit = 512m
  client_limit=1
   unix_listener /usr/home/postfix.local/private/dovecot-lmtp {
 group = postfix
 mode = 0600
 user = postfix
  }
}

service doveadm {
  process_limit = 0
  process_min_avail = 0
  idle_kill = 0
  client_limit = 1
  user = vmail
  inet_listener {
port = 12345
  }
}

service config {
  unix_listener config {
user = vmail
}
}

service anvil {
  process_limit = 1
  client_limit=5000
  vsz_limit = 512m
  unix_listener anvil {
group = vmail
mode = 0666
  }
}

service auth {
   process_limit = 1
   client_limit=5000
   vsz_limit = 1g

   unix_listener auth-userdb {
  mode = 0660
  user = vmail
  group = vmail
   }
   unix_listener /var/spool/postfix/private/auth {
  mode = 0666
   }

}

service stats {
  process_limit = 1000
  vsz_limit = 1g
  unix_listener stats-reader {
group = vmail
mode = 0666
  }
  unix_listener stats-writer {
group = vmail
mode = 0666
  }
}

-




Happy Monday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266

On 5/16/2022 8:09 AM, Sebastian Kroczek wrote:


Hello all,

I updated the server tonight and with it Dovecot from 2.2.27 to 
2:2.3.19-2+debian11. However, there seems to be a problem with the ACLs, 
because since then fatal errors are logged (see core dump). I suspect 
that some outdated configuration is causing this behavior, but so far I 
couldn't figure out which one it could be. I also have no clue right now 
how to debug this further.
Thank you very much for your help. If more information are needed, I 
will of course be happy to provide them.


VG
Sebastian


 Error logs =
May 16 13:33:43 Fatal: imap(us...@domain.com)<0r5YZR/fM4AfrHBI>: master: 
service(imap): child 238359 killed with signal 11 (core dumped)
May 16 13:33:46 Fatal: imap(us...@domain.com): master: 
service(imap): child 238386 killed with signal 11 (core dumped)
May 16 13:33:46 Fatal: imap(us...@domain.com): master: 
service(imap): child 238387 killed with signal 11 (core dumped)
May 16 13:34:54 Fatal: imap(us...@domain.com)<1WS6aR/fHoAfrHBI>: master: 
service(imap): child 238509 killed with signal 11 (core dumped)
May 16 13:34:54 Fatal: imap(us...@domain.com): master: 
service(imap): child 238508 killed with signal 11 (core dumped)
May 16 13:35:27 Fatal: imap(us...@domain.com): master: 
service(imap): child 238589 killed with signal 11 (core dumped)
May 16 13:35:27 Fatal: imap(us...@domain.com): master: 
service(imap): child 238590 killed with signal 11 (core dumped)

 END Error logs =

 dovecot.conf ==

# 2.3.19 (b3ad6004dc): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.19 (4eae2f79)
# OS: Linux 5.10.0-14-amd64 x86_64 Debian 11.3
# Hostname: wv-imap1.wavecloud.de
auth_mechanisms = plain login
default_vsz_limit = 4 G
dict {
   acl = mysql:/etc/dovecot/dovecot-dict-sql.conf
}
first_valid_gid = 5000
first_valid_uid = 5000
imap_capability = +XDOVECOT
last_valid_gid = 5000
last_valid_uid = 5000
listen = 10.10.115.XX
login_trusted_networks = 10.10.115.XX 10.10.115.XX
mail_location = maildir:~/
mail_log_prefix = "%s(%u)<%{session}>: "
mail_plugins = acl notify quota fts fts_solr virtual
maildir_stat_dirs = yes
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 = yes
   location =
   mailbox Archive {
     auto = subscribe
     special_use = \Archive
   }
   mailbox Drafts {
     auto = subscribe
     special_use = \Drafts
   }
   mailbox Junk {
     special_use = \Junk
   }
   mailbox Sent {
     auto = subscribe
     special_use = \Sent
   }
   mailbox "Sen

Re: Duplicate messages if message is moved when using dsync

[Paul Kudla (SCOM.CA Internet Services Inc.)]

ok duplicsate emails (even across dsync, replication etc) is typically 
handled via a global sieve script



I use :

# cat duplicates.sieve
require "duplicate";   # for dovecot >= 2.2.18

if duplicate {
discard;
stop;
}

for the scripts

and setup sieve to work via my dovecot.conf file

relative parts below :



protocols = imap pop3 lmtp sieve

protocol lmtp {
  mail_plugins = $mail_plugins sieve
  postmaster_address = moni...@scom.ca
}


protocol lda {
  mail_plugins = $mail_plugins sieve
}


plugin {
.

  sieve = file:~/sieve;active=~/sieve/.dovecot.sieve

  sieve_duplicate_default_period = 1h
  sieve_duplicate_max_period = 1d
  sieve_extensions = +duplicate +notify +imapflags +vacation-seconds
  sieve_global_dir = /usr/local/etc/dovecot/sieve
  sieve_before = /usr/local/etc/dovecot/sieve/duplicates.sieve

.
}

service managesieve-login {
  process_limit = 1000
  vsz_limit = 1g
  inet_listener sieve {
port = 4190
  }
}

protocol sieve {
  managesieve_implementation_string = Dovecot Pigeonhole
  managesieve_max_line_length = 65536
}



--


note the sieve_before which handles duplictes during delivery etc.


Happy Monday !!!
Thanks - paul

Paul Kudla


Scom.ca Internet Services 
004-1009 Byron Street South
Whitby, Ontario - Canada
L1N 4S3

Toronto 416.642.7266
Main 1.866.411.7266
Fax 1.888.892.7266

On 5/15/2022 12:38 PM, Thom Pol wrote:

Hi,

Hope you are well.

We have a cluster of 2 Dovecot servers, both on v2.3.13 (89f716dc2), 
using dsync to sync the messages between them.


Previously, we used TCPS to sync the messages, but after some testing, 
we concluded that syncing over SSH resulted in a lot less failed syncs, 
so we started using SSH.


The change has been a success, but I now notice a issue when a email 
client immediately moves a messages to a separate folder while Dovecot 
is syncing, where the message is seen twice in the folder (with the 
exact same headers/content).


For example, I have set a filter in my email client, Thunderbird, to 
immediately move all emails coming from this list to a separate folder. 
When opening that folder, I do not see one, but two unread messages, 
both identical to each other.


When checking the directories on the server, I see this:
mx1:
/var/vmail/example.com/joe/Maildir/.Subdir.Subdir/cur/1652615808.M190190P990486.mx2,S=19089,W=19384:2,S
/var/vmail/example.com/joe/Maildir/.Subdir.Subdir/cur/1652615811.M180050P1376677.mx1,S=19089,W=19384:2,S

mx2:
/var/vmail/example.com/joe/Maildir/.Subdir.Subdir/cur/1652615811.M981426P990530.mx2,S=19089,W=19384:2,S
/var/vmail/example.com/joe/Maildir/.Subdir.Subdir/cur/1652615808.M190190P990486.mx2,S=19089,W=19384:2,S

Note the difference: on mx1, one indicates mx1, and one mx2, while on 
the other server, both indicate mx2/


Any idea (other then telling end-users not to use such filters) how we 
could prevent these duplicate messages?


This is our config:
# Pigeonhole version 0.5.13 (cdd19fe3)
# OS: Linux 5.10.0-13-cloud-amd64 x86_64 Debian 11.3
# Hostname: mx1.example.com
auth_mechanisms = plain login
disable_plaintext_auth = no
dsync_remote_cmd = ssh -p 222 -l%{login} %{host} doveadm dsync-server -u%u
imap_capability = +SPECIAL-USE XLIST
listen = *,[::]
lmtp_rcpt_check_quota = yes
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_max_userip_connections = 100
mail_plugins = quota
mail_privileged_group = vmail
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 = .
}
passdb {
   args = /etc/dovecot/dovecot-sql.conf
   driver = sql
}
plugin {
   mail_replica = remote:r...@mx2.example.com
   quota = dict:user::file:/var/vmail/%d/%n/.quotausage
   quota_status_nouser = DUNNO
   quota_status_overquota = 552 5.2.2 Mailbox is full
   quota_status_success = DUNNO
   sieve = /var/vmail/%d/%n/.sieve
   sieve_after = /var/vmail/%d/%n/.ispconfig.sieve
   sieve_before = /var/vmail/%d/%n/.ispconfig-before.sieve
   sieve_max_actions = 100
   sieve_max_redirects = 25
   sieve_max_script_size = 2M
}
protocols = imap pop3 lmtp
replication_max_conns = 50
service aggregator {
   fifo_listener replication-notify-fifo {
     mode = 0666
     user = vmail
   }
   unix_listener replication-notify {
     mode = 0666
     user = vmail
   }
}
service auth {
   unix_listener /var/spool/postfix/private/auth {
     group = postfix
     mode = 0660
     user = postfix
   }
   unix_listener auth-userdb {
     group = vmail
     mode = 0600
     user = vmail
   }
   user = root
}
service imap-login {
   client_limit = 1000
   process_limit = 512
}
service lmtp {
   unix_listener /var/spool/postfix/private

Fatal Error after upgrade to 2:2.3.19-2+debian11

[Sebastian Kroczek]

Hello all,

I updated the server tonight and with it Dovecot from 2.2.27 to 
2:2.3.19-2+debian11. However, there seems to be a problem with the ACLs, 
because since then fatal errors are logged (see core dump). I suspect 
that some outdated configuration is causing this behavior, but so far I 
couldn't figure out which one it could be. I also have no clue right now 
how to debug this further.
Thank you very much for your help. If more information are needed, I 
will of course be happy to provide them.


VG
Sebastian


 Error logs =
May 16 13:33:43 Fatal: imap(us...@domain.com)<0r5YZR/fM4AfrHBI>: master: 
service(imap): child 238359 killed with signal 11 (core dumped)
May 16 13:33:46 Fatal: imap(us...@domain.com): master: 
service(imap): child 238386 killed with signal 11 (core dumped)
May 16 13:33:46 Fatal: imap(us...@domain.com): master: 
service(imap): child 238387 killed with signal 11 (core dumped)
May 16 13:34:54 Fatal: imap(us...@domain.com)<1WS6aR/fHoAfrHBI>: master: 
service(imap): child 238509 killed with signal 11 (core dumped)
May 16 13:34:54 Fatal: imap(us...@domain.com): master: 
service(imap): child 238508 killed with signal 11 (core dumped)
May 16 13:35:27 Fatal: imap(us...@domain.com): master: 
service(imap): child 238589 killed with signal 11 (core dumped)
May 16 13:35:27 Fatal: imap(us...@domain.com): master: 
service(imap): child 238590 killed with signal 11 (core dumped)

 END Error logs =

 dovecot.conf ==

# 2.3.19 (b3ad6004dc): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.19 (4eae2f79)
# OS: Linux 5.10.0-14-amd64 x86_64 Debian 11.3
# Hostname: wv-imap1.wavecloud.de
auth_mechanisms = plain login
default_vsz_limit = 4 G
dict {
  acl = mysql:/etc/dovecot/dovecot-dict-sql.conf
}
first_valid_gid = 5000
first_valid_uid = 5000
imap_capability = +XDOVECOT
last_valid_gid = 5000
last_valid_uid = 5000
listen = 10.10.115.XX
login_trusted_networks = 10.10.115.XX 10.10.115.XX
mail_location = maildir:~/
mail_log_prefix = "%s(%u)<%{session}>: "
mail_plugins = acl notify quota fts fts_solr virtual
maildir_stat_dirs = yes
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 = yes
  location =
  mailbox Archive {
auto = subscribe
special_use = \Archive
  }
  mailbox Drafts {
auto = subscribe
special_use = \Drafts
  }
  mailbox Junk {
special_use = \Junk
  }
  mailbox Sent {
auto = subscribe
special_use = \Sent
  }
  mailbox "Sent Items" {
auto = no
special_use = \Sent
  }
  mailbox "Sent Messages" {
auto = no
special_use = \Sent
  }
  mailbox Spam {
auto = subscribe
special_use = \Junk
  }
  mailbox Trash {
auto = subscribe
special_use = \Trash
  }
  prefix =
  separator = /
  type = private
}
namespace Virtual {
  hidden = yes
  list = no
  location = virtual:/etc/dovecot/virtual:INDEX=/srv/vmail/_virtual/%u
  prefix = Virtual/
  separator = /
  subscriptions = no
}
namespace shared {
  list = yes
  location = maildir:%%h:INDEX=~/shared/%%u
  prefix = shared/%%u/
  separator = /
  subscriptions = no
  type = shared
}
passdb {
  args = /etc/dovecot/dovecot-sql-password.conf
  driver = sql
}
passdb {
  args = /etc/dovecot/admin-sql.conf
  driver = sql
  master = yes
  pass = yes
}
plugin {
  acl = vfile
  acl_shared_dict = proxy::acl
  fts = solr
  fts_autoindex = yes
  fts_solr = url=http://wv-solr1.wavecloud.de:8983/solr/dovecot/
  quota = maildir:User quota
  quota_rule = *:storage=20G
  quota_rule2 = Trash:storage=+100M
  quota_rule3 = SPAM:ignore
  quota_warning = storage=95%% quota-warning 95 %u
  quota_warning2 = storage=80%% quota-warning 80 %u
  quota_warning3 = -storage=100%% quota-warning below %u
  sieve = ~/.dovecot.sieve
  sieve_before = /var/vmail/globalsieverc
  sieve_max_script_size = 1M
  sieve_quota_max_scripts = 42
  sieve_quota_max_storage = 10
}
protocols = imap pop3 sieve lmtp
service auth {
  unix_listener /var/spool/postfix/private/auth {
group = vmail
mode = 0666
user = vmail
  }
  unix_listener auth-master {
mode = 0666
  }
}
service dict {
  unix_listener dict {
mode = 0600
user = vmail
  }
}
service imap-login {
  process_min_avail = 1
  service_count = 0
  vsz_limit = 500 M
}
service lmtp {
  inet_listener lmtp {
address = 0.0.0.0
port = 24
  }
}
service managesieve-login {
  executable = /usr/lib/dovecot/managesieve-login
  inet_listener sieve {
address = 10.10.115.10
port = 4190
  }
  process_min_avail = 1
  service_count = 1
}
service managesieve {
  executable = /usr/local/sbin/dovecot-managesieve.sh
}
service pop3-login {
  process_min_avail = 1
  service_count = 1
}
service quota-warning {
  executable = script /usr/local/sbin/quota-warning.sh
  user = vmail
}
service stats {
  unix_listener st

Re: Use different log files

[Paul Kudla (SCOM.CA Internet Services Inc.)]

Robert's answer is a valid approach pending the size of your server 
networks etc.


on another note (because i run multiple servers etc)

I run a common syslog file across all servers which is what you appear 
to have now.


from there i like everything in one syslog because i am usually looking 
for something relative to a user which can occur anywhere. (imap, smtp, 
pop3, ssl etc)


that being said i wrote bash scripts that do stuff like

cat /var/log/syslog.log | grep $1

this allows everything from ALL servers going into one file for 
simplicity and then it gets seperated out when you go looking for something.


note that syslog can be programmed to divert to other servers in syslog.conf

## cat /etc/syslog.conf
*.* /var/log/all.log
*.* @10.228.0.6

10.228.0.6 is my central internal syslog capture server and all of my 
servers, routers, devices etc point to that and i go from there.


if you are having auth issues etc between dovecot & postfix this will 
show you everything related to a user, ip address etc.


Again its just a suggestion ... Logging is always relative to network 
setup more then anything else and situations vary easily.


I expanded this concept eventually into a database driven logger system 
in django, it is probably overkill for you but i am running 20+ servers 
and at the end of the day it was just easier to centralize it.


so

ssh 10.220.0.6 -q -tt /usr/home/syslog/log $1 $2 $3 $4 $5 $6 $7 $8 $9

or more spoecifically

log -t p...@hiscomputer.ca (-t was for today's date)

would give me all activity for my accounts



mail19  05-16 07:03:26 {smtphandler.py} [14475] (996976186) [14475] 
Header info data: 'hiscomputer...@em1.dereksloan.ca', 
['p...@hiscomputer.ca'] ((While
Handling File : 
/usr/home/postfix/tmp/936692CC6F0))
mail19  05-16 07:03:26 {smtphandler.py} [14475] (996976190) [14475] 
rSPF set : Received-SPF: Pass (sender SPF authorized) identity=mailfrom; 
client-
ip=167.89.21.76; 
helo=o24.email.nationbuilder.com; envelope-from=bounces+14632821-e4fc-


paul=hiscomputer...@em1.dereksloan.ca; receiver=p...@hiscomputer.ca \n 
((While Handling File :


/usr/home/postfix/tmp/936692CC6F0))
mail19  05-16 07:03:26 {smtphandler.py} [14475] (996976198) [14475] 
Checking for Spam SPF Conditions in rSPF : Received-SPF: Pass (sender 
SPF authorized)
identity=mailfrom; 
client-ip=167.89.21.76; helo=o24.email.nationbuilder.com; envelope-


from=bounces+14632821-e4fc-paul=hiscomputer...@em1.dereksloan.ca; 
receiver=p...@hiscomputer.ca \n ((While
Handling File : 
/usr/home/postfix/tmp/936692CC6F0))
mail19  05-16 07:03:26 {smtphandler.py} [14475] (996976200) [14475] 
processing TO: p...@hiscomputer.ca ((While Handling File :


/usr/home/postfix/tmp/936692CC6F0))
mail19  05-16 07:03:26 {smtphandler.py} [14475] (996976201) [14475] 
Checking if user p...@hiscomputer.ca has a mailbox ((While Handling File :


/usr/home/postfix/tmp/936692CC6F0))
mail19  05-16 07:03:26 {smtphandler.py} [14475] (996976202) [14475] 
SELECT * FROM email_users WHERE source = $$p...@hiscomputer.ca$$ ((While 
Handling File
: 
/usr/home/postfix/tmp/936692CC6F0))
mail19  05-16 07:03:28 {MailScanner}[11525] (996976259) Delivery 
of nonspam: message 936692CC6F0.AF475 from bounces+14632821-e4fc-


paul=hiscomputer...@em1.dereksloan.ca to p...@hiscomputer.ca with 
subject WHO take over!
mail19  05-16 07:03:42 {smtphandler.py} [14487] (996976373) [14487] 
Header info data: 'hiscomputer...@em1.dereksloan.ca', 
['p...@hiscomputer.ca'] ((While
Handling File : 
/usr/home/postfix/tmp/75A082CC6FE))
mail19  05-16 07:03:42 {smtphandler.py} [14487] (996976377) [14487] 
rSPF set : Received-SPF: Pass (sender SPF authorized) identity=mailfrom; 
client-
ip=167.89.21.76; 
helo=o24.email.nationbuilder.com; envelope-from=bounces+14632821-e4fc-


paul=hiscomputer...@em1.dereksloan.ca; receiver=p...@hiscomputer.ca \n 
((While Handling File :


/usr/home/postfix/tmp/75A082CC6FE))
mail19  05-16 07:03:42 {smtphandler.py} [14487] (996976385) [14487] 
Checking for Spam SPF Conditions in rSPF : Received-SPF: Pass (sender 
SPF authorized)
identity=mailfrom; 
client-ip=167.89.21.76; helo=o24.email.nationbuilder.com; envelope-


from=bounces+14632821-e4fc-paul=hiscomputer...@em1.dereksloan.ca; 
receiver=p...@hiscomputer.ca \n ((While
Handling File : 
/usr/home/postfix/tmp/75A082CC6FE))
mail19  05-16 07:03:42 {smtphandler.py} [14487] (996976387) [14487] 
processing TO: p...@hiscomputer.ca ((While

Re: Use different log files

[Robert Schetterer]

Am 16.05.2022 um 11:58 schrieb Cristiano Deana:

Hi,

I have a mailserver with dovecot logging to syslog (by default, to 
/var/log/maillog) and my MTA (postfix) is doing the same.
I use dovecot's services imap/pop3, auth and lmtp and now logs files are 
hard to read because I havve all together MTA and these services.


Is it possibile to have different log with different services?

Example:
auth logging: /var/log/mail.auth
delivery: /var/log/mail.delivery and so on

Thank you



https://blog.sys4.de/xymon-dovecot-count-imap-pop3-logins-graph-central-rsyslog-server-ubuntu-lucid-en.html

use filter in syslog i.e

/etc/rsyslog.d/50-default.conf

...
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn   |/dev/xconsole
...
# dovecot
:programname, isequal, "dovecot" /var/log/dovecot.log
#pop3
:msg, contains, "pop3" /var/log/dovecot-pop3.log
#imap
:msg, contains, "imap" /var/log/dovecot-imap.log
...

and dont forget to configure logrotate
too


--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

Use different log files

[Cristiano Deana]

Hi,

I have a mailserver with dovecot logging to syslog (by default, to 
/var/log/maillog) and my MTA (postfix) is doing the same.
I use dovecot's services imap/pop3, auth and lmtp and now logs files are 
hard to read because I havve all together MTA and these services.


Is it possibile to have different log with different services?

Example:
auth logging: /var/log/mail.auth
delivery: /var/log/mail.delivery and so on

Thank you

--

###
# Cristiano Deana #
# #
# Senior Network Engineer #
# Digital Response Team #
# CittaStudi S.p.a. #
# off. +39 015 855 1172 #
# cell +39 328 310 6392 #
###

Re: TLS renegotiation issue (CVE-2011-1473) in Dovecot

[Aki Tuomi]

Interesting that your security organization is worried about TLS renegotiation 
but do not mind people logging in without TLS... =)

You have

disable_plaintext_auth = no

which allows plaintext auth over non-TLS connection. See 
https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/

"ssl=yes and disable_plaintext_auth=no: SSL/TLS is offered to the client, but 
the client isn’t required to use it. The client is allowed to login with 
plaintext authentication even when SSL/TLS isn’t enabled on the connection. 
This is insecure, because the plaintext password is exposed to the internet."

Anyways, back to the TLS renegotiation...

There is no config option in dovecot explicitly to disable this, and 
unfortunately openssl 1.0.2 does not seem to support system-wide config file to 
disable Renegotiation in ssl_conf section. With OpenSSL 1.1.1 you can actually 
edit /etc/pki/tls/openssl.cnf and disable renegotiation, without having to run 
everything on TLSv1.3.
 
For users with 1.1 you can use following to disable renegotiation in your 
distribution specific system-wide openssl.cnf:

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
Options = NoRenegotiation

Aki

> On 14/05/2022 11:13 Greg Earle  wrote:
> 
>  
> On 13 May 2022, at 19:38, Elisamuel Resto  wrote:
> 
> > I believe this to be a configuration error, not a dovecot problem.  
> > The
> > output of dovecot -n (as an attachment; look it over for any data you 
> > do
> > not want publicized) would help to suggest changes to bring you back
> > into compliance.
> 
> Elisamuel,
> 
> I'm not really sure why you think it's a configuration error, but I'll 
> attach the "dovecot -n" output.
> 
> Thanks,
> 
>   - Greg