May 2023 - dovecot - dovecot.org

auth: Panic: file oauth2-request.c assertion failed
by Urban Loesch 05 Sep '23

05 Sep '23

Hi, I'm running a postfix smtp relay server on which users are getting authenticated trough sasl via the dovecot authentication service. This works without problems. Recently I extended my configuration to authenticate users with the PLAIN mechanism against Azure AD B2C with oauth2 in the future. Important to mention is that currently no users are stored in Azure B2C. I only prepared the hole configuration and authentiucation falls back to mysql database. Now sometimes I get the error below in my logs (not permanently): ... Dec 7 11:36:49 relay-out1 dovecot: auth: Panic: file oauth2-request.c: line 201 (oauth2_request_start): assertion failed: (oauth2_valid_token(input->token)) Dec 7 11:36:49 relay-out1 dovecot: auth: Error: Raw backtrace: /usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x3d) [0x7f399402e62d] -> /usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7f399402e74e] -> /usr/lib/dovecot/libdovecot.so.0(+0x1006eb) [0x7f399403b6eb] -> /usr/lib/dovecot/libdovecot.so.0(+0x100781) [0x7f399403b781] -> /usr/lib/dovecot/libdovecot.so.0(+0x54b7c) [0x7f3993f8fb7c] -> /usr/lib/dovecot/libdovecot.so.0(+0x4605a) [0x7f3993f8105a] -> /usr/lib/dovecot/libdovecot.so.0(oauth2_passwd_grant_start+0xfa) [0x7f3993f9870a] -> dovecot/auth(db_oauth2_lookup+0x2ca) [0x560d0804368a] -> dovecot/auth(auth_request_default_verify_plain_continue+0x2d6) [0x560d08026436] -> dovecot/auth(auth_policy_check+0x2b) [0x560d0802071b] -> dovecot/auth(+0x29f72) [0x560d0802ff72] -> dovecot/auth(auth_request_handler_auth_continue+0xf7) [0x560d0802a197] -> dovecot/auth(+0x16c62) [0x560d0801cc62] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x69) [0x7f3994051c29] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x131) [0x7f3994053251] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x4c) [0x7f3994051ccc] -> /usr/lib/dovecot/libdovecot.so.0(io_loop_run+0x40) [0x7f3994051e50] -> /usr/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7f3993fc4df3] -> dovecot/auth(main+0x415) [0x560d0801abf5] -> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f3993cee09b] -> dovecot/auth(_start+0x2a) [0x560d0801ad8a] ... After the error above postfix says the connection to the authentication server was lost: ... Dec 7 11:36:49 relay-out1 rolrelayout1/smtpd[1655601]: warning: domain.com[12.12.12.12]: SASL LOGIN authentication failed: Connection lost to authentication server ... I was able to make a core dump. ... # gdb /usr/lib/dovecot/auth core.auth.1654357.1670409409 GNU gdb (Debian 8.2.1-2+b3) 8.2.1 ... For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/dovecot/auth...Reading symbols from /usr/lib/debug/.build-id/bc/f14ed9cc2dda3ee9565fbd7ccd835460008438.debug...done. done. [New LWP 1654357] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `dovecot/auth'. Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht gefunden. (gdb) bt full #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 set = {__val = {0, 1415, 1416, 94613970086496, 10, 139885273538955, 155, 139885273347109, 140724590457408, 118, 206158430224, 140724590457744, 140724590457536, 16888407779496842752, 94613970086472, 139885273131758}} pid = <optimized out> tid = <optimized out> ret = <optimized out> #1 0x00007f3993cec535 in __GI_abort () at abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x73f, sa_sigaction = 0x73f}, sa_mask = {__val = {1024, 18446744073709551615, 94613971926672, 94613971631792, 139885273108347, 94613970084312, 139885273090236, 94613970084312, 16888407779496842752, 94613970084288, 139885273346402, 140724590457744, 94613970084312, 140724590457744, 139885273346761, 94613970084312}}, sa_flags = -1811749030, sa_restorer = 0x5} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007f3993f8feaf in default_fatal_finish (status=0, type=LOG_TYPE_PANIC) at failures.c:465 backtrace = 0x560d0813e220 "/usr/lib/dovecot/libdovecot.so.0(backtrace_append+0x3d) [0x7f399402e62d] -> /usr/lib/dovecot/libdovecot.so.0(backtrace_get+0x1e) [0x7f399402e74e] -> /usr/lib/dovecot/libdovecot.so.0(+0x1006eb) [0x7f39"... backtrace = <optimized out> recursed = 0 #3 fatal_handler_real (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at failures.c:477 status = 0 #4 0x00007f399403b781 in i_internal_fatal_handler (ctx=<optimized out>, format=<optimized out>, args=<optimized out>) at failures.c:879 No locals. #5 0x00007f3993f8fb7c in i_panic (format=format@entry=0x7f399407a0e8 "file %s: line %d (%s): assertion failed: (%s)") at failures.c:530 ctx = {type = LOG_TYPE_PANIC, exit_status = 0, timestamp = 0x0, timestamp_usecs = 0, log_prefix = 0x0, log_prefix_type_pos = 0} args = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7ffcff39b4e0, reg_save_area = 0x7ffcff39b420}} #6 0x00007f3993f8105a in oauth2_request_start (set=0x560d08176150, input=0x7ffcff39b5d0, callback=0x560d08042b50 <db_oauth2_lookup_passwd_grant>, context=0x560d082ffe90, p=0x560d082b7eb0, method=0x7f399407a2c6 "POST", url=0x560d08178480 "https://xxx.b2clogin.com/xxx.onmicrosoft.com/B2C_1_ropc/oauth2/v2.0/token?s…", payload=0x560d082b7ed8, add_auth_bearer=false) at oauth2-request.c:201 __func__ = "oauth2_request_start" pool = <optimized out> req = <optimized out> #7 0x00007f3993f9870a in oauth2_passwd_grant_start (set=set@entry=0x560d08176150, input=input@entry=0x7ffcff39b5d0, username=0x560d082ffe38 "user.name", password=0x560d082ffe48 "", callback=callback@entry=0x560d08042b50 <db_oauth2_lookup_passwd_grant>, context=context@entry=0x560d082ffe90) at oauth2-request.c:351 pool = 0x560d082b7eb0 payload = 0x560d082b7ed8 #8 0x0000560d0804368a in db_oauth2_lookup (db=0x560d08176060, req=0x560d082ffe90, token=<optimized out>, request=0x560d082ffba8, callback=0x560d080370b0 <oauth2_verify_plain_continue>, context=0x560d082ffba8) at db-oauth2.c:862 input = {token = 0x560d082ffe48 "", service = 0x560d082ffe20 "smtp", local_ip = {family = 2, u = {ip6 = {__in6_u = {__u6_addr8 = "\303\376\374\322", '\000' <repeats 11 times>, __u6_addr16 = {65219, 54012, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {3539795651, 0, 0, 0}}}, ip4 = {s_addr = 3539795651}}}, real_local_ip = {family = 2, u = {ip6 = {__in6_u = {__u6_addr8 = "\303\376\374\322", '\000' <repeats 11 times>, __u6_addr16 = {65219, 54012, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {3539795651, 0, 0, 0}}}, ip4 = {s_addr = 3539795651}}}, remote_ip = {family = 2, u = {ip6 = {__in6_u = {__u6_addr8 = "*\300\070\226", '\000' <repeats 11 times>, __u6_addr16 = {49194, 38456, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {2520301610, 0, 0, 0}}}, ip4 = {s_addr = 2520301610}}}, real_remote_ip = {family = 2, u = {ip6 = {__in6_u = {__u6_addr8 = "*\300\070\226", '\000' <repeats 11 times>, __u6_addr16 = { 49194, 38456, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {2520301610, 0, 0, 0}}}, ip4 = {s_addr = 2520301610}}}, local_port = 0, real_local_port = 0, remote_port = 0, real_remote_port = 0} __func__ = "db_oauth2_lookup" #9 0x0000560d08026436 in auth_request_default_verify_plain_continue (request=0x560d082ffba8, callback=0x560d0803e6f0 <plain_verify_callback>) at auth-request.c:1123 passdb = 0x560d0814da40 result = 22029 cache_key = <optimized out> error = 0x560d082ffe38 "user.name" password = 0x560d082ffe48 "" __func__ = "auth_request_default_verify_plain_continue" #10 0x0000560d0802071b in auth_policy_check (request=<optimized out>, password=<optimized out>, cb=<optimized out>, context=<optimized out>) at auth-policy.c:575 pool = <optimized out> ctx = <optimized out> #11 0x0000560d0802ff72 in mech_plain_auth_continue (request=0x560d082ffba8, data=0x560d0813d368 "user.name", data_size=30) at mech-plain.c:58 authid = <optimized out> authenid = 0x560d0813d377 "user.name" error = 0x560d0813d320 "h\323\023\b\rV" pass = 0x560d0813d388 "" i = <optimized out> len = <optimized out> count = 2 #12 0x0000560d0802a197 in auth_request_handler_auth_continue (handler=0x560d082d1ae8, args=args@entry=0x560d08268e96 "21\tdGhvbWFzLmZlcnJhcmkAdGhvbWFzLmZlcnJhcmkA") at auth-request-handler.c:738 request = 0x560d082ffba8 data = 0x560d08268e99 "dGhvbWFzLmZlcnJhcmkAdGhvbWFzLmZlcnJhcmkA" data_len = 40 buf = 0x560d0813d320 id = 21 #13 0x0000560d0801cc62 in auth_client_handle_line (line=0x560d08268e91 "CONT\t21\tdGhvbWFzLmZlcnJhcmkAdGhvbWFzLmZlcnJhcmkA", conn=0x560d08276d30) at auth-client-connection.c:228 No locals. #14 auth_client_input (conn=<optimized out>) at auth-client-connection.c:311 _data_stack_cur_id = 3 line = <optimized out> ret = <optimized out> #15 0x00007f3994051c29 in io_loop_call_io (io=0x560d0826f240) at ioloop.c:737 ioloop = 0x560d08145f80 t_id = 2 __func__ = "io_loop_call_io" #16 0x00007f3994053251 in io_loop_handler_run_internal (ioloop=ioloop@entry=0x560d08145f80) at ioloop-epoll.c:222 ctx = 0x560d08148600 events = <optimized out> event = 0x560d08148680 list = 0x560d082ae620 io = <optimized out> tv = {tv_sec = 0, tv_usec = 315566} events_count = <optimized out> msecs = <optimized out> ret = <optimized out> i = 0 j = <optimized out> call = <optimized out> __func__ = "io_loop_handler_run_internal" #17 0x00007f3994051ccc in io_loop_handler_run (ioloop=0x560d08145f80) at ioloop.c:789 __func__ = "io_loop_handler_run" #18 0x00007f3994051e50 in io_loop_run (ioloop=0x560d08145f80) at ioloop.c:762 __func__ = "io_loop_run" #19 0x00007f3993fc4df3 in master_service_run (service=0x560d08145dd0, callback=<optimized out>) at master-service.c:869 No locals. #20 0x0000560d0801abf5 in main (argc=<optimized out>, argv=<optimized out>) at main.c:393 c = <optimized out> ... And "doveconf -n": ... # 2.3.19.1 (9b53102964): /etc/dovecot/dovecot.conf # OS: Linux 5.10.0-18-amd64 x86_64 Debian 10.13 # Hostname: relay-out1.domain.com auth_cache_negative_ttl = 0 auth_cache_size = 40 M auth_cache_ttl = 30 days auth_mechanisms = plain login auth_username_chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_%@ auth_username_translation = %@ auth_verbose = yes auth_verbose_passwords = plain auth_worker_max_count = 100 disable_plaintext_auth = no 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 = /etc/dovecot/dovecot-oauth2.plain.conf.ext driver = oauth2 mechanisms = plain login } passdb { args = /etc/dovecot/dovecot-sql-account.conf driver = sql } service auth { unix_listener /var/spool/postfix/private/auth { group = postfix mode = 0660 user = postfix } } userdb { args = /etc/dovecot/dovecot-sql-account.conf driver = sql } ... System OS is Debian 10, Dovecot installed from dovecot repository. Many thanks Urban

1 1

Pigeonhole redirect is adding a message-id header when it already exists
by Sébastien Riccio 04 Aug '23

04 Aug '23

Hello, We are using sieve filter to redirect incoming mails to an external mailbox (gmail) an we are seeing some forwarded e-mails being rejected by gmail because of duplicate headers. I think was able to identify the probable cause of the duplicate headers: It seems that when the original message's "Message-ID" is not compliant, pigeonhole acts like if the header is not existing and adds it's own Message-ID. This result in having two "Message-ID" headers being submitted to the destination mail server. Original Message-ID: Message-ID: 1883biz_pay_after_purchase:0:0_572392900$ae7ed6e4d53b424c84aaf83b30c507e7 Pigeon hole adds his own Message-ID: Message-ID: <dovecot-sieve-1664386049-21512-0@510faa1ff2d9> Gmail answer: 550-5.7.1 [94.103.100.17] Our system has detected that this message is not RFC 550-5.7.1 5322 compliant: duplicate headers. To reduce the amount of spam sent 550-5.7.1 to Gmail, this message has been blocked. Please review 550 5.7.1 RFC 5322 specifications for more information. While I understand the original "Message-ID" seems to be all but compliant with RFCs, shouldn't a "Message-ID" be added only when "Message-ID" is really missing ? When redirecting a message, If the original "Message-ID" exists but is bogus shouldn't it still be forwarded untouched ? Also, maybe if pigeonhole is adding it's own "Message-ID", shouldn't it remove any previous "Message-ID" to avoid generating duplicate headers ? (but maybe it could break some DKIM stuff?) Any ideas how to workaround this issue ? Thanks a lot for your feedbacks! Sébastien RICCIO SYSTEM ADMINISTRATOR P +41 840 888 888 F +41 840 888 000 M sriccio(a)swisscenter.com<mailto:sriccio@swisscenter.com>

9 17

subscription, dots and subscribe to shared folder.
by Julien Nadal 24 Jul '23

24 Jul '23

Hello; We were able to set up shared folders in a cluster (using dovecot as proxy on dedicated front-end servers, without using director) by following https://doc.dovecot.org/configuration_manual/shared_mailboxes/cluster_setup/. Here is our related conf on imap farms (dovecot v2.3.16 on Almalinux): namespaces: mail_location = maildir:~/Maildir namespace default { inbox = yes location = prefix = separator = / } namespace shared { list = children location = imapc:~/shared/%%u:INDEXPVT=~/shared-pvt/%%u prefix = shared/%%u/ separator = / subscriptions = no type = shared } imapc settings: imapc_features = fetch-bodystructure fetch-headers rfc822.size search modseq acl delay-login imapc_host = XXXXXX imapc_master_user = %{user} imapc_password = XXXXXX imapc_port = XXXXXX passdb { args = password=#hidden_use-P_to_show# userdb_namespace/shared/disabled=yes userdb_acl_user=%{auth_user} allow_nets=XXXXX/XX driver = static master = yes } dict { acl-mysql = mysql:/etc/dovecot/conf.d/dovecot-dict-sql.conf.ext } This way, a folder is created under ~/ : shared & shared-pvt : When user A shares a folder with B, B will find ~/shared/userA/sharedfolder I should mention that the user authentication (backend: mysql) uses the full email address as we are in a multi-tenant context. So the folder looks like ~/shared/usera(a)domain.tld/folder Since then, everything works perfectly, we can share and see the shared folders in the webmail (SOGo). Unfortunately, accessing these folders through an imap client (tested on Thunderbird and MSOutlook) is impossible because the subscription fails (the folder is listed, but the subscription doesn't seem to do anything). I could not find any relevant logs but I was able to confirm on the command line: I am able to view folder with LIST, subscribe with an "OK" output, but the folder is not listed with LSUB. So I could see that the subscribtion file in maildir shows incorrect entries: V 2 Sent Trash Drafts Junk shared/testuser1@sub domain tld/INBOX/folder The dots in the folder names are replaced by tabs. I was able to recover things by editing the file as follows: Sent Trash Drafts Junk shared/testuser1(a)sub.domain.tld/INBOX/folder This means that Maildir++ and V2 subscription can't handle dots in folders. I found a previous discussion: https://dovecot.org/pipermail/dovecot/2021-January/121233.html But the final advice can't be applied on our side: - changing LAYOUT to FS is not possible for us - we have already migrated the dot separator to slash - changing the layout only for shared namespaces does not solve the problem and totally breaks the access to shared folders. Thanks a lot for your advice Best regards Julien

3 4

Many IDLE imap processes but very few connections moved to imap-hibernate
by pierre.alletru＠gmail.com 17 Jul '23

17 Jul '23

Hi Dovecot community! I have a strange issue with imap-hibernate. Or more likely it behaves as it's supposed to and it's just that I don't really understand it. I have enabled it, and it works, but for some reason hibernation happens only to a tiny amount of connections, whereas I have a lot of IDLE imap processes. And I can't find any relevant errors in the logs. ## config ## mail_debug = yes verbose_proctitle = yes $ doveconf imap_hibernate_timeout imap_hibernate_timeout = 5 secs $ doveconf -a | grep -A 21 'service imap-hibernate' service imap-hibernate { chroot = client_limit = 0 drop_priv_before_exec = no executable = imap-hibernate extra_groups = group = idle_kill = 0 privileged_group = process_limit = 0 process_min_avail = 0 protocol = imap service_count = 0 type = unix_listener imap-hibernate { group = $default_internal_group mode = 0660 user = } user = $default_internal_user vsz_limit = 18446744073709551615 B } ## imap processes ## $ ps aux | grep "dovecot/imap" | wc -l 2214 ps aux | grep "dovecot/imap" | grep IDLE | wc -l 1258 $ ps aux | grep "imap-hibernate" syslog 1571453 0.0 0.0 4748 3156 ? S 15:44 0:00 dovecot/imap-hibernate [18 connections] As you can see here I have 1258 IDLE imap processes (out of 2214 in total), and only 18 connections in imap-hibernate. I'd like to have all IDLE processes to be moved to imap-hibernate in order to save up memory. Any idea why these 1k+ IDLE imap processes are not moved into imap-hibernate? Thank you!

2 1

Warning sqlpool(mysql): Query failed
by Alessio Cecchi 27 Jun '23

27 Jun '23

Hi, with the last dovecot version (2.3.13) I see many of this warnings via "doveadm log errors": Feb 17 03:26:28 Warning: dict(31513): conn unix:dict (pid=31330,uid=95): dict(mysql)<email1(a)company1.com>: sqlpool(mysql): Query failed, retrying: MySQL server has gone away (idled for 679 secs) Feb 17 03:48:53 Warning: dict(31013): conn unix:dict (pid=31805,uid=95): dict(mysql)<email2(a)company2.com>: sqlpool(mysql): Query failed, retrying: MySQL server has gone away (idled for 685 secs) Feb 17 03:54:12 Warning: dict(32529): conn unix:dict (pid=3147,uid=95): dict(mysql)<email3(a)company3.com>: sqlpool(mysql): Query failed, retrying: MySQL server has gone away (idled for 670 secs) What do they mean? I thinks are related to inactivity timeout on mysql server (where I have a wait_timeout=600), but these warnings could be problems or can be fixed with some setting in dovecot? My dovecot configuration about dict: dict { acl = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext expire = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext sieve = mysql:/etc/dovecot/dovecot-dict-sieve-sql.conf.ext sqlquota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext } plugin { [...] acl_shared_dict = proxy::acl expire_dict = proxy::expire quota2 = dict:Quota Usage::noenforcing:proxy::sqlquota sieve = file:~/sieve;active=~/.dovecot.sieve sieve_before = dict:proxy::sieve;name=activesql [...] } service dict { process_limit = 500 unix_listener dict { group = vmail mode = 0660 user = vmail } } Thanks -- Alessio Cecchi Postmaster @ http://www.qboxmail.it https://www.linkedin.com/in/alessice

2 1

configuring Dovecot submission service
by Computerisms Corporation 23 Jun '23

23 Jun '23

Hi Dovecot Gurus, I have been playing around with the submission service. I have managed to get all the things working that I want working with two exceptions. I have not found (or possibly I have overlooked) solutions in the documentation or discussions on the 'net. First; I would like to be able to authenticate against my backend MTA using the user-supplied credentials. I have tried setting submission_relay_user as %u and submission_relay_password as %w, but these seem to be passed through as literal strings, and of course my backend MTA has no idea who %u is. I found a post from 2019 that indicates passing the submission_relay_user/password to the backend is not a supported function, but hoping that maybe that is outdated info. I also found: https://doc.dovecot.org/3.0/configuration_manual/authentication/proxies/ Which seems to indicate it could pass credentials to a non-Dovecot MTA backend, but I am not really clear from the docs on how to set that up, and I did not find any relevant examples to work from. Seems like it would be setting up a Director service, maybe? I have done that before and I do manage multiple email servers, but none of them is clustered or configured to be interoperable, so not sure if this is a viable approach. Second; I am wondering about the possibility of having multiple submission_relay_host entries. For example if I have dovecot submission services running on my standard port 587 and 465 connect to a relay on the same box through localhost, but could I have another submission service running on another port, say 5587, and relay all traffic received on that port through a completely different host? I am thinking I could set that up by running a separate instance of dovecot for just that service, but maybe there is a more suitable way? I don't have a solid use-case for this in mind at the moment, but given that I do manage multiple email servers, I am thinking that if this is possible it might provide some useful corner-case configurations down the road. Thank you for reading my post, any thoughts, information, or pointers to relevant documentation would be most appreciated. -- Bob Miller 867-334-7117 www.computerisms.ca

2 3

Multiple backends with NFSv4.1 (supports file locking): should work without Director, right?
by pierre.alletru＠gmail.com 05 Jun '23

05 Jun '23

Hi Dovecot community, We're looking at running multiple Dovecot backend servers in parallel, all using the same shared NFSv4.1 mount to store mailboxes in the maildir format. We've read in multiple places that running multiple backends with a shared NFS can result in issues like index files corruption. The standard solution seems to use the Director feature, or some kind of IP based proxy/load balancer. But: 1 - The Director feature will be removed in future free versions of Dovecot (https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/ILA3C…). 2 - NFSv4 and above support file locking (flock and fcntl, flock being emulated using fcntl). 3 - It looks like Dovecot does use file locking, though we're unsure if it does on everything and in particular on index files. Thus, we are wondering if the need for Director is still relevant with NFSv4? Shouldn't it work without Director thanks to file locking? Has anyone tried it? We're thinking that the documentation and various threads on the subject may be outdated, based on NFSv3 and lower (no file locking). If it doesn't work, anybody knows why? Isn't file locking there precisely to handle concurrency? Thanks!

10 17

Share
by liecj3＠bfh.ch 01 Jun '23

01 Jun '23

Hello dear Dovecot users I have a somewhat special request: I have a single file in mbox format which I want to make accessible via IMAP to anonymous logins. The mbox file is being updated outside of Dovecot and should not be changeable by Dovecot. So far I created a Docker container based on the official image (https://hub.docker.com/r/dovecot/dovecot) and configured the Dovecot according to https://doc.dovecot.org/configuration_manual/shared_mailboxes/public_shared/. The volume with the mbox file is mounted in the running container under /var/mail. Each time a client tries to access this public mailbox the following error is logged and no content is returned: May 26 21:57:06 imap(mutt)<16><Rkpg0Z/8pLfAqDAB>: Error: Mailbox Public/archive: open() failed with mbox: Read-only file system. Note that I don't need the file to be a shared mailbox. Instead I would also be happy to have all (anonymous) users mapped to the read-only mbox somewhere in the filesystem. Dockerfile: FROM dovecot/dovecot RUN mkdir -p /var/indexes/public RUN chown 1000:1000 /var/indexes/public ADD dovecot.conf /etc/dovecot/dovecot.conf /etc/dovecot/dovecot.conf: ## You should mount /etc/dovecot if you want to ## manage this file mail_home=/srv/mail/%Lu mail_location=sdbox:~/Mail mail_uid=1000 mail_gid=1000 #protocols = imap pop3 submission sieve lmtp protocols = imap first_valid_uid = 1000 last_valid_uid = 1000 passdb { driver = static args = password=pass } ssl=yes ssl_cert=<cert.pem ssl_key=<key.pem namespace { type = private inbox = yes separator = / } namespace { type = public prefix = Public/ location = mbox:/var/mail/:INDEX=/var/indexes/public subscriptions = no } listen = * log_path=/dev/stdout info_log_path=/dev/stdout debug_log_path=/dev/stdout

2 1

GSSAPI auth Line too long
by Thomas Lemarchand 31 May '23

31 May '23

Hello, On version 2.3.20 (80a5ac675d), I have a problem with submission-login when using GSSAPI auth : it's not working, probably due to AUTH line being too long. It appeared after I activated PAC on my Kerberos infrastructure. Now the Kerberos tickets contains MS-PAC data and are bigger. It's part of the RFC and is a valid use case : https://datatracker.ietf.org/doc/html/rfc4120#section-5.2.6 Logs : May 30 17:13:00 auth: Debug: auth client connected (pid=378) May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Sent: 220 mail.int.k8s.lemarchand.io Dovecot ready. May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Received new command: EHLO [192.168.202.16] May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: New command May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: Execute command May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: Pipeline blocked May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: 250 reply: Submitted May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: Replied May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: Ready to reply May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Trigger output May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: Next to reply May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Sending replies May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: Next to reply May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: Completed May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: Pipeline unblocked May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Connection state reset May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: 250 reply: Sent: 250-mail.int.k8s.lemarchand.io 8BITMIME AUTH GSSAPI PLAIN LOGIN BURL imap CHUNKING ENHANCEDSTATUSCODES SIZE P IPELINING May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: Finished May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: Destroy May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command EHLO: 250 reply: Destroy May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Trigger output May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: No more commands pending May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Sending replies May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: No more commands pending May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Client sent invalid command: Command line is too long May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command [unknown]: Invalid command May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command [unknown]: 500 reply: Submitted May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command [unknown]: Replied May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command [unknown]: Ready to reply May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Trigger output May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Sending replies May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command [unknown]: Next to reply May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command [unknown]: Completed May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command [unknown]: 500 reply: Sent: 500 5.5.2 Line too long May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command [unknown]: Finished May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command [unknown]: Destroy May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: command [unknown]: 500 reply: Destroy May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Trigger output May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: No more commands pending May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Sending replies May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: No more commands pending May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Remote closed connection: Connection closed May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Disconnected: Connection closed May 30 17:13:00 submission-login: Debug: smtp-server: conn 10.200.114.128:13587 [1]: Connection state reset My guess is that it's due to https://github.com/dovecot/core/blob/main/src/lib-smtp/smtp-common.h#L10 being too low (is it configurable ?), but I didn't read the code thoroughly. Red Hat IDM now activates MS-PAC by default, so any installation based on IDM (or FreeIPA) may have the same problem. What's your opinion ? Bug ? Mail sent using password auth :'( -- Thomas Lemarchand

4 7

Inconsistent listing of shared subfolders
by mschering＠intermesh.nl 30 May '23

30 May '23

Hi all, I have a problem with listing shared folders. In my web application I don't get the whole folder tree at once but get them level by level with: LIST "" "subfolder/%" RETURN (CHILDREN) Now I have an issue with shared folders. If I share folder test/sub with another user it returns it's (not shared) parent folder with this command: LIST "" "shared/someuser/%" RETURN (CHILDREN) But if I do the same with INBOX/sub it will not return the "INBOX" folder with the above command. Is that a bug or does anybody know why it behaves differently? Also, If I do: LIST "" "shared/someuser/*" RETURN (CHILDREN) it will return both the subfolder of test and inbox. My shared namespace is setup like this: namespace { type = shared separator = / prefix = shared/%%u/ # a) Per-user seen flags. Maildir indexes are shared. (INDEXPVT requires v2.2+) location = maildir:%%h/Maildir:INDEXPVT=~/Maildir/shared/%%u # b) Per-user seen flags. Maildir indexes are not shared. If users have direct filesystem level access to their mails, this is a safer option: #location = maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u:INDEXPVT=~/Maildir/shared/%%u subscriptions = no list = children } Thanks for any help! Best regards, Merijn

1 0