- dovecot - dovecot.org

Re: dovecot Digest, Vol 177, Issue 55
by Matthew Brown 25 Jan '18

25 Jan '18

No reason to tell me about security, I just need chmod for my tests. Where to change it ? On Thu, Jan 25, 2018 at 12:00 PM, <dovecot-request(a)dovecot.org> wrote: > Send dovecot mailing list submissions to > dovecot(a)dovecot.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://dovecot.org/mailman/listinfo/dovecot > or, via email, send a message with subject or body 'help' to > dovecot-request(a)dovecot.org > > You can reach the person managing the list at > dovecot-owner(a)dovecot.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dovecot digest..." > > > Today's Topics: > > 1. Re: Panic: data stack: Out of memory when allocating bytes > (Josef 'Jeff' Sipek) > 2. Re: 777 permissions on mailbox, subfolders subfiles new > emails (Nikolai Lusan) > 3. Re: problem with lda (Stephan Bosch) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 24 Jan 2018 17:39:36 -0500 > From: Josef 'Jeff' Sipek <jeff.sipek(a)dovecot.fi> > To: Thomas Robers <robers(a)tutech.de> > Cc: dovecot(a)dovecot.org > Subject: Re: Panic: data stack: Out of memory when allocating bytes > Message-ID: <20180124223936.GE14966@meili> > Content-Type: text/plain; charset=us-ascii > > On Wed, Jan 24, 2018 at 18:55:47 +0100, Thomas Robers wrote: > > Am 23.01.2018 um 20:07 schrieb Josef 'Jeff' Sipek: > > > On Tue, Jan 23, 2018 at 14:03:27 -0500, Josef 'Jeff' Sipek wrote: > > > > On Tue, Jan 23, 2018 at 18:21:38 +0100, Thomas Robers wrote: > ... > > > > 1. Do you have any idea what the imap process was doing at the time > of the > > > > allocation failure? > > > > Yes perhaps. We use shared mailboxes and at the time of failure the > > imap process is reading acl files in a shared mailbox (and subfolder). > > This shared mailbox has about 2800 subfolder and the acl files are read > > in about 10sec and and during this reading the imap process dies with > > the already mentioned error. It seems it has something to do with the > > shared mailbox, because since yesterday morning 5 core dumps have been > > created, 4 of them by one user accessing the shared mailbox and 1 > > by the user who is the owner of the shared mailbox. No other mailboxes > > are affected until now. > > Based on the stack trace, the client was creating a new mailbox, which > caused an acl list rebuild, which ended up triggering this oddly sized > allocation. > > > > > 2. You snipped all the important parts of the back trace. :) It > *starts* on > > > > the line: > > > > #0 0x00007f73f1386495 in raise () from /lib64/libc.so.6 > > > > > > In case you haven't used gdb before... after starting up gdb, run "bt > full" > > > at the gdb prompt. That'll print out a very detailed backtrace. (You > might > > > want to sanity check it to make sure there aren't any user passwords > in it > > > before posting it here...) > > > > Yes, sorry I'm not very familiar in using gdb, but here is the full > > backtrace: > > It looks like the binaries are stripped. There should be a "debug" package > you can install with symbol information. Then, the backtrace should be > much > more helpful. > > > > > Having the backtrace should help answer question number 1. > > > > 3. How big is this process when it dies? > > > > I don't know which imap process dies beforehand so how do i get this > > information? > > The size of the core file will give you an general idea. gdb can also > print > out lots of info via "maintenance info sections", but I don't think that'll > help figuring out why things blow up. > > Jeff. > > -- > Keyboard not found! > Press F1 to enter Setup > > > ------------------------------ > > Message: 2 > Date: Thu, 25 Jan 2018 13:09:40 +1000 > From: Nikolai Lusan <nikolai(a)lusan.id.au> > To: dovecot(a)dovecot.org > Subject: Re: 777 permissions on mailbox, subfolders subfiles new > emails > Message-ID: <1516849780.4714.5.camel(a)lusan.id.au> > Content-Type: text/plain; charset="UTF-8" > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi, > > On Thu, 2018-01-25 at 00:35 +0200, Matthew Brown wrote: > > What I have to change, so dovecot on new email create, sets chmod 777 on > > Mailbox and all subfolders subfiles all new emails/sent emails etc. > > This is a really bad idea. It is possible to setup in dovecot if you're > using dovecot as your LDA. The only reason I can think of for anything > close to this is virtual mailboxes ... and even then I set things up with a > specific user to own the files and set them as 770 for the directories and > 660 for the files. With that setup dovecot limits users to their own mail > directories with values returned via the passdb/userdb. > > As a general rule anything on a *nix system that is chmod 777 is to be > avoided - it's a massive security risk. > > - -- > Nikolai Lusan <nikolai(a)lusan.id.au> > -----BEGIN PGP SIGNATURE----- > > iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAlppSnQACgkQ4ZaDRV2V > L6To/BAAjKeTi6reaRrcSClKm6PEbgewtF1KvHgO1zr+hv9T2XOnVGFSajeFwSXR > rDSXGQ/H9s97KDGZB4VKxuSKZsDRFkF9u7ILttuXOgj8kG8XZl4sqg/w0FIrTC1K > GD8T0TZWSJGFIzrLXTpgzoO1LeQXIuXgnZIMbcaneCHKZc1do/GwQ4DEFVdUnxRJ > n+76nbs8RdQwZKGXYGGTU/BXPniTSW1pmTFxnlruxE7fuWBYeEyQGQRke/CT2rFF > ET+d7LlV4Nds6eGjalyf7m5tCNS87Zm78xegANuMNaMdzPI8NlbnFO82bAlC7kP/ > WkCFSfhJL3s9daEnMWT/dxY2lNKy3kTyOZssXM6ROkNhOFRipNwRr77tO6qzu8l9 > pvaVxr8a0pMVQwxGAyW84vS9GWmeMNMMiY0k7XdPSBS/6CVlQm8eUhnDo6GFZoH9 > Tbn4XNkEKysbZEjImjXb6eQpRwQLniIULjeyoX8aqmN2sh4kDndLJwjxpz7Jd6v2 > j2tuS7+79G9qU8dqpCSwzvWYTteOLJeqJLy6s5F+zf8FHGLcHdNasoo+/Sdzg4+E > tZm31wp7iQdzKMwbOnRk9FceYXbb9WjxI1QY+7U11Rx25y44UDPzUYYOL+ZoWOXJ > zAr/F9fhUP/u8AubOgOn6BLaguiWcFK0g6HhCqDkVAUibEMzC+0= > =YUek > -----END PGP SIGNATURE----- > > > > ------------------------------ > > Message: 3 > Date: Thu, 25 Jan 2018 09:35:57 +0100 > From: Stephan Bosch <stephan(a)rename-it.nl> > To: Infoomatic <infoomatic(a)gmx.at>, dovecot(a)dovecot.org > Subject: Re: problem with lda > Message-ID: <2544728b-5441-c163-34fd-bd155e28f591(a)rename-it.nl> > Content-Type: text/plain; charset=utf-8 > > Op 1/24/2018 om 5:30 PM schreef Infoomatic: > > Hello, > > > > I am currently testing the upgrade from our dovecot v2.2.23 to 2.3.0. I > have a strange problem with lda. > > We use bounce mails for internal users if they try to send > virus/spammails. The exact same config works with 2.2.23, but not with > 2.3.0. > > > > The relevant postfix/master.cf part: > > dovecot unix - n n - - pipe > > flags=DRhu user=vmail:vmail argv=/opt/dovecot/libexec/dovecot/deliver > -d ${recipient} -f ${sender} > > > > On the same machine, with 2.2.23 I get a bounce mail when trying to send > a virus, with the subject "VIRUS in message apparently from you > (Eicar-Test-Signature)", to both the users inbox as well as to the mailbox > of virusalert(a)ourdomain.internal > > > > With 2.3.0, in the logs I get an error: > > > > relay=dovecot, delay=0.01, delays=0/0/0/0, dsn=5.3.0, status=bounced > (command line usage error. Command output: lda: Fatal: Invalid -f > parameter: Missing domain > > > > and the alert message is only sent to virusalert(a)ourdomain.internal, > but not to the user who tried to send the mail. > > > > The relevant part of our dovecot.conf: > > protocol lda { > > mail_plugins = " quota zlib sieve acl mail_log notify" > > postmaster_address = postmaster(a)ourdomain.internal > > } > > > > Does anyone know how to solve this problem? Or is there a workaround via > postfix/amavis/spamassassin? Any hints are highly appreciated, thanks! > > Apparently, the ${sender} has no @domain part. Why? > > Regards, > > Stephan. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > dovecot mailing list > dovecot(a)dovecot.org > https://dovecot.org/mailman/listinfo/dovecot > > ------------------------------ > > End of dovecot Digest, Vol 177, Issue 55 > **************************************** > -- zxzzzzzzzzzzzzz

1 1

777 permissions on mailbox, subfolders subfiles new emails
by Matthew Brown 25 Jan '18

25 Jan '18

What I have to change, so dovecot on new email create, sets chmod 777 on Mailbox and all subfolders subfiles all new emails/sent emails etc.

2 1

Questions about SPECIAL-USE IMAP extension
by Joseph Tam 25 Jan '18

25 Jan '18

I'd like to configure my dovecot service to use the IMAP SPECIAL-USE extension, but have a few questions for those who have used them, or are knowledgable about its use. Using this configuration as an example, namespace { ... mailbox xxx { special_use = \Sent } } Q1) Am I correct that mail client that don't understand SPECIAL-USE extentions will behave the same way with repect to outgoing mailbox storage? Q2) Will SPECIAL-USE enabled mail clients switch the mailbox used for outgoing mail from whatever it was using (e.g. "Sent Mail") to the (new) special-use mailbox "xxx"? Q3) Will SPECIAL-USE enabled mail clients connecting for the first time use "xxx" for outgoing mail, auto-creating it if necessary? Or will "xxx" be used only if the user does not manually configure a mailbox for this purpose? Q4) If I have an additional configuration mailbox yyy { special_use = \Sent } how does it affect Q2, Q3? Thanks to any who can provide clarity on this. Joseph Tam <jtam.home(a)gmail.com>

4 5

"Timeout (180s) while waiting for lock for transaction log file" since 2.3 upgrade?
by Zube 24 Jan '18

24 Jan '18

dovecot 2.1.x and 2.2.x has "just worked" with a minimal configuration for just about anything I've ever thrown at it. Now, with 2.3.0, there is one user (and only one user) that continually sees horrible delays, which is not surprising given the logs: Error: imap(user)<70175><356C8oljxrCBUppP>: Timeout (180s) while waiting for lock for transaction log file /path/to/home/directory/.imap/dovecot.list.index.log (WRITE lock held by pid 69995) where 69995 is the pid of the first dovecot process and 70175 is the pid of, e.g., the first LIST command. What's unique about this user is that he's the only one using linux (thunderbird) and his home directory is NFS-mounted. I understand that something is incorrect with the locking, but there are a couple of issues that I do not understand: 1) Is there a default that changed between 2.2 and 2.3 that would cause this? Despite potential issues associated with NFS, I didn't see the problem with 2.2. There is nothing in my conf file related to locking, so if there was a change, it must be a default for 2.3 (from doveconf -a): dotlock_use_excl = yes lock_method = fcntl mbox_dotlock_change_timeout = 2 mins mbox_lock_timeout = 5 mins mbox_read_locks = fcntl mbox_write_locks = dotlock fcntl 2) If the problem is related to NFS locks, why would the problem persist when the user runs thunderbird from the server where his home directory *is not* NFS-mounted? Thanks for any help. Cheers, Zube

1 0

Autoexpunge is not working with dotlock locking
by Jaakko Seppälä 24 Jan '18

24 Jan '18

Hello, Autoexpunge is not working when used with dotlock locking. It seems to been broken since version 2.2.28. When autoexpunge is enabled and mailbox locking is set to dotlock all imap, pop and lmtp connections crash with the same error "file file-lock.c: line 287: unreached". Connected to localhost. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ AUTH=PLAIN] Dovecot ready. X LOGIN testuser password X OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE LITERAL+ NOTIFY] Logged in X LOGOUT * BYE Logging out X OK Logout completed (0.001 + 0.000 secs). Connection closed by foreign host. => Jan 22 09:25:55 dovecottest dovecot: imap-login: Login: user=<testuser>, method=PLAIN, rip=::1, lip=::1, mpid=8274, secured, session=<EDVCNV5jvNsAAAAAAAAAAAAAAAAAAAAB> Jan 22 09:25:57 dovecottest dovecot: imap(testuser)<8274><EDVCNV5jvNsAAAAAAAAAAAAAAAAAAAAB>: Panic: file file-lock.c: line 287: unreached Jan 22 09:25:57 dovecottest dovecot: imap(testuser)<8274><EDVCNV5jvNsAAAAAAAAAAAAAAAAAAAAB>: Error: Raw backtrace: /usr/local/lib/dovecot/libdovecot.so.0(+0xc8d24) [0x7ff43bef5d24] -> /usr/local/lib/dovecot/libdovecot.so.0(+0xc8dde) [0x7ff43bef5dde] -> /usr/local/lib/dovecot/libdovecot.so.0(i_fatal+0) [0x7ff43be69190] -> /usr/local/lib/dovecot/libdovecot.so.0(+0xcd8ff) [0x7ff43befa8ff] -> /usr/local/lib/dovecot/libdovecot.so.0(file_wait_lock_error+0x26) [0x7ff43befac46] -> /usr/local/lib/dovecot/libdovecot.so.0(file_try_lock_error+0x13) [0x7ff43befacc3] -> /usr/local/lib/dovecot/libdovecot.so.0(file_create_locked+0x253) [0x7ff43bef7df3] -> /usr/local/lib/dovecot/libdovecot-storage.so.0(mail_user_lock_file_create+0xc5) [0x7ff43c1f5f15] -> /usr/local/lib/dovecot/libdovecot-storage.so.0(mail_user_autoexpunge+0x1f8) [0x7ff43c1dfc68] -> dovecot/imap(+0x1ba7c) [0x7ff43c72fa7c] -> dovecot/imap(client_input+0xb5) [0x7ff43c7308c5] -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_call_io+0x65) [0x7ff43bf0d315] -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_handler_run_internal+0x10f) [0x7ff43bf0ebbf] -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_handler_run+0x52) [0x7ff43bf0d412] -> /usr/local/lib/dovecot/libdovecot.so.0(io_loop_run+0x38) [0x7ff43bf0d638] -> /usr/local/lib/dovecot/libdovecot.so.0(master_service_run+0x13) [0x7ff43be8bb73] -> dovecot/imap(main+0x333) [0x7ff43c7226c3] -> /lib64/libc.so.6(__libc_start_main+0xf5) [0x7ff43ba8bc05] -> dovecot/imap(+0xe8a1) [0x7ff43c7228a1] Jan 22 09:25:57 dovecottest dovecot: imap(testuser)<8274><EDVCNV5jvNsAAAAAAAAAAAAAAAAAAAAB>: Fatal: master: service(imap): child 8274 killed with signal 6 (core dumps disabled) Configuration used for testing: [root@dovecottest dovecot]# /usr/local/sbin/dovecot -n # 2.3.0 (c8b89eb): /usr/local/etc/dovecot/dovecot.conf # OS: Linux 3.10.0-514.el7.x86_64 x86_64 CentOS Linux release 7.3.1611 (Core) lock_method = dotlock mail_location = maildir:~/Maildir namespace inbox { inbox = yes location = mailbox Drafts { special_use = \Drafts } mailbox INBOX { autoexpunge = 30 days } mailbox Junk { special_use = \Junk } mailbox Sent { special_use = \Sent } mailbox "Sent Messages" { special_use = \Sent } mailbox Trash { special_use = \Trash } prefix = } passdb { driver = pam } service lmtp { inet_listener lmtp { port = 24 } } ssl = no userdb { driver = passwd } Regards, Jaakko

2 1

version conflict in freebsdports?
by ＠lbutlr 24 Jan '18

24 Jan '18

I have dovecot 2.2.33 installed. When trying to install dovecot2-pigeonhole (v 0.4.19) I get the following when it tries to install dovecot 2.2.31_1 I run portsnap fetch update daily, and I ran it again after this error, but same result. ===> Installing for dovecot2-2.2.31_1 ===> Checking if dovecot2 already installed ===> Registering installation for dovecot2-2.2.31_1 as automatic Installing dovecot2-2.2.31_1... pkg-static: dovecot2-2.2.31_1 conflicts with dovecot-2.2.33.2_2 (installs files into the same place). Problematic file: /usr/local/bin/doveadm *** Error code 70 (FreeBSD 11.1) -- Take my hand and I'll show you what was and will be.

2 2

PDFs getting mangled
by Adam Weinberger 24 Jan '18

24 Jan '18

Since upgrading to 2.3.0 / 0.5.0.1, incoming PDFs are getting mangled. It seems to be happening when I use vnd.dovecot.filter. When I comment out the block, things come through fine. My filter block looks like this: require "vnd.dovecot.filter"; filter "bogofilter_filter"; if header :contains "X-Bogosity" [ "Spam, tests=bogofilter, spamicity=1.00", "Spam, tests=bogofilter, spamicity=0.99" ] { fileinto "spam/totally"; stop; } elsif header :contains "X-Bogosity" "Spam," { fileinto "spam/probably"; stop; } elsif header :contains "X-Bogosity" "Unsure," { fileinto "spam/maybe"; stop; } filter/bogofilter_filter looks like this: #!/bin/sh cat /dev/stdin | /usr/local/bin/bogofilter -p -e -c /path/to/bogofilter.cf Images seem to come through fine. I didn't have this problem before the upgrade. It could easily be a problem with bogofilter, but I figured that I'd check here first to see if anybody else has an attachment-mangling issue with vnd.dovecot.filter. # Adam -- Adam Weinberger adamw(a)adamw.org http://www.adamw.org

3 7

Auth cache prevents login when non-password fields change
by Tom Sommer 23 Jan '18

23 Jan '18

The auth cache contains all fields returned by "password_query" (in itself a little odd), including the fields "nologin" and "reason". If a user is cached with "nologin=Y" and the database-source is changed so nologin condition is no longer true, then the cache prevents login for as long as the TTL remain? is there any way around this? Thanks -- Tom

1 0

rewrite copy to trash->delete->expunge mail with move??
by Chi Min Wang 23 Jan '18

23 Jan '18

Hello Everyone: When user got quota exceed and trying to delete mail. Most MUA's default "move to trash folder" will proceed by copy mail to trash folder,then by delete/expunge it(copy before expunge). Unfortunately this will not success due to quota exceed. Is there any way to let dovecot proceed it by IMAP MOVE instead of "copy to trash folder"->delete/expunge,Thanks!! *********************************************** CONFIDENTIALITY NOTICE:This e-mail and any attachments are confidential and may be legally privileged. If you are not the intended recipient, (i) please do not read or disclose to others, and (ii) please notify immediately the sender by reply mail, and (iii) please delete all copies of the email from your system. Failure to follow this process may be unlawful. We greatly appreciate your cooperation.

3 2

How to set autoexpunge rule for single user mailbox in dovecot conf?
by Alexey Murz Korepov 23 Jan '18

23 Jan '18

I need to set autoexpunge rule only for one single user and one mailbox (mail folder), so apply it only for user alice(a)example.com mailbox INBOX. How can I set namespace in dovecot config, that will apply only to single user? -- Best regards, Alexey Murz Korepov. Email, Jabber: murznn(a)gmail.com

3 2