March 2019 - dovecot - dovecot.org

dovecot sieve duplicates detection
by André Rodier 04 Dec '19

04 Dec '19

Hello, I have tested the sieve duplicate script with success so far, but I have a question. I would like to know if the "duplicate" sieve flag in Dovecot is global to all folders, or specific to one folder only. For instance, if I copy an email from one folder to another, and I have a discard action on duplicate email, is this action will be applied (in this case, discard) or not. If the duplicate is global to all folders, is there a way to restrict the search in one folder only. Thanks for your help. André

3 10

Migration
by Hans Brage 01 Oct '19

01 Oct '19

Hi! I'm currently running an small imap-server on Dovecot 2.2.4 but will retire that server. I've set up an new server with Dovecot 2.3.4 and will migrate the mailboxes (maildir-format) from the old to the new server. I'm planning to restructure the accounts a bit when migrating so I need to move them one by one. Its only a few so thats not a big issue. Both servers are using virtual accounts (users file). I've understood that best method for migration is to run doveadm backup -R from the new server. But I really cant figure out what other parameters or settings that I need to perform that task and if it should be run as user vmail or root. Would be greatful for any tips, hints, links or similiar. Regards, Hans

6 9

Best way to move mail from one server to another
by James Brown 01 Oct '19

01 Oct '19

I’d like to migrate to a new server. I only need to transfer the mail store, have already done the users. I’ve seen different recommendations: IMAP-Sync Rsync Doveadmin backup and dsync What are the pros and cons of each? What would be best for me? I’m thinking that Doveadmin backup is the way to go. Both old and new servers are on same network. New server is running Dovecot 2.3.2.1, old server is 2.2.32. macOS X. Does anyone have any advice or examples? Thanks, James.

13 29

pigeonhole/lda accessing -m folder
by matthias lay 12 Sep '19

12 Sep '19

Hi all, anybody knows, if there is a way to acces the folder from a call like this deovecot-lda -m destfolder from within a sieve script? thx in advance matze

5 9

Re: Message delivered twice caused by an LMTP error "Got unexpected reply" during upgrade to 2.3
by Gabriele Nencioni 02 Sep '19

02 Sep '19

>>> On 08/09/2018 09:12 AM, Stephan Bosch wrote >>>>>> Can you make a pcap log of the LMTP communication between the two >>>>>> Dovecot hosts? That may give me a clue on which side of the >>>>>> communication is causing the issue. >>>>> Yes sure, where I can send it? >>>>> Here on list or at your address? >>>> >>>> Just send it to me. On 08/16/2018 10:21 AM, Stephan Bosch wrote: > Op 16/08/2018 om 09:46 schreef Gabriele Nencioni: >> On 08/15/2018 06:39 PM, Stephan Bosch wrote: >>> Op 15-8-2018 om 17:19 schreef Stephan Bosch: >>>> >>>> Op 13-8-2018 om 15:50 schreef Gabriele Nencioni: >>>>> So the scenario seems to be: >>>>> the error occurs between old directors and new backends >>>>> and between the new backends and the smtp submission_host (for >>>>> redirection) >>>>> and using the pipeline capability and attaching a file >>>>> >>>>> Let me know if you need more info >>>> In this case it is possible to obtain a debug log by enabling >>>> mail_debug=yes. Can you obtain a full debug log for such a failing >>>> submission session? >> Ok! It is attached. > > That is just weird. Dovecot reports that it cannot fully send the last > bits of the message and right thereafter the reply is received, which > Dovecot then interprets as out-of-sequence. The PCAP files tell me the > final CRLF.CRLF is actually sent to the other side, but somehow Dovecot > thinks it couldn't do that yet. > > Is this problem occurring for any and all SMTP client interactions, or > just every once in a while? Unfortunately it occurs just every once in a while and it is weird because at the second attempt the message is successful delivered or redirected. >>> Also, I don't see anything weird in the PCAP files: the command-reply >>> sequence is OK. This means that this is likely a bug in the current >>> Dovecot version. Those debug logs should tell me more. >> Ok! Which version of dovecot do you suggest to install? >> On debian current stable (stretch) repository there is the version >> number 2.2.27, have we to install it? > > If you're facing big trouble it is usually best to revert to the > previous version that worked I guess. Ok I'm agree! So, about you, which version can I try to install the 2.2.27 or the previous release of the 2.3 version such as v2.3.2 2018-06-29 or v2.3.1 2018-02-29? Regards, -- Gabriele Nencioni System Administrator eml gabriele.nencioni(a)register.it

2 6

flags not synced correctly with dovecot sync (dsync)
by Dan Christensen 31 Aug '19

31 Aug '19

I'm running dovecot 2.3.4.1 from https://repo.dovecot.org/ on Ubuntu 18.04 on three machines that I'll call server, laptop1 and laptop2. Both laptop1 and laptop2 run dovecot sync against server to keep local copies of my imap folders. Even when I initially had only two machines, laptop1 and server, I occasionally noticed that flags were lost, usually custom flags used by Gnus, but I couldn't reliably reproduce the problem. Now that I have two laptops syncing against the server, the problem has gotten worse and I figured out a way to reproduce it: - on server: create new IMAP folder test, and put two read messages in it - on laptop1: doveadm sync -u user -l 10 -m test -f user@server - on laptop2: doveadm sync -u user -l 10 -m test -f user@server At this point, all three machines show the two messages M1 and M2 as being read. - on laptop1: mark message M1 unread - on laptop2: mark message M2 unread - on laptop1: doveadm sync -u user -l 10 -m test -f user@server Both laptop1 and server have M1 unread, M2 read, as expected. - on laptop2: doveadm sync -u user -l 10 -m test -f user@server Now laptop2 and server have M1 *read*, M2 unread. - on laptop1: doveadm sync -u user -l 10 -m test -f user@server Now laptop1 and the server have both M1 and M2 *read*. - on laptop2: doveadm sync -u user -l 10 -m test -f user@server Now laptop2 has both read as well. The two lines that say "*read*" are wrong in my opinion. dsync propagated a read mark to an unread message, even though that message was marked unread more recently than it was marked read. I usually use stateful sync, and get many related problems. I just did a test in which M1 and M2 started out read, and I started with empty files named dstate.test on laptop1 and laptop2. Then I did the above procedure, using the command doveadm sync -u user -l 10 -m test -s "`cat dstate.test`" user@server > dstate.test At the end, laptop2 and server had both messages unread (which is good), but laptop1 had only M1 unread, and repeated runs of the sync command did not correct this. So the stateful sync failed to detect a change. Are these bugs in dovecot? Is there more information that I can provide? The output of doveconf -n on one machine is below, and the others are almost identical. Thanks for any help! Dan # 2.3.4.1 (3c0b8769e): /etc/dovecot/dovecot.conf # OS: Linux 4.15.0-45-generic x86_64 Ubuntu 18.04.1 LTS # Hostname: laptop2 auth_mechanisms = plain login listen = 127.0.0.1 mail_index_log2_max_age = 10 days mail_index_log_rotate_min_age = 1 days mail_index_log_rotate_min_size = 300 k mail_location = maildir:~/Maildir 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 = scheme=CRYPT username_format=%u /etc/dovecot/users driver = passwd-file } protocols = imap service imap-login { inet_listener imap { address = * port = 143 } inet_listener imaps { address = * port = 943 ssl = yes } } service imap { process_limit = 25 } ssl_cert = </etc/dovecot/private/dovecot.pem ssl_client_ca_dir = /etc/ssl/certs ssl_dh = # hidden, use -P to show it ssl_key = # hidden, use -P to show it userdb { args = username_format=%u /etc/dovecot/users driver = passwd-file } protocol lda { postmaster_address = [elided] } protocol imap { mail_max_userip_connections = 20 }

3 8

[BUG?] Double quota calulation when special folder is present
by Mark Moseley 07 Aug '19

07 Aug '19

Just hoping to get some dev eyes on this. I'm incredibly reluctant to throw the word 'bug' around (since 99 times out of 100, it's not -- it's almost always the config), but I can't think of any way that this could be a config issue, esp when the pre-2.2.34 version works as expected. I noticed during troubleshooting that dovecot errors out if I try to create a subfolder called 'INBOX' but it'll happily create a subfolder called INBOX.SomethingElse (i.e. a folder called INBOX.INBOX.SomethingElse - resulting in a directory called .INBOX.SomethingElse on the filesystem, and leading to the problem described below). Is that sub-subfolder creation (where the top level subfolder matches the namespace name) supposed to be allowed? It seems odd that 'INBOX' (as a subfolder of INBOX) would be blocked but INBOX.SomethingElse (as a subfolder of INBOX) would be allowed. I'd expect INBOX.SomethingElse (i.e. INBOX.INBOX.SomethingElse) would be blocked as well. On Wed, Mar 13, 2019 at 4:46 AM Bernd Wurst via dovecot <dovecot(a)dovecot.org> wrote: > Hello, > > we're operating dovecot on a small server. Some years ago, we migrated > from courier IMAP to dovecot. Therefore, we defined our default > Namespace "inbox" with prefix "INBOX." to have this compatible. I found > this in some migration docs those days. Generally, everything worked as > expected. > > Our only namespace is configured like this: > > namespace inbox { > separator = . > prefix = INBOX. > inbox = yes > } > > Regularly, there is no folder named INBOX or .INBOX in the file system, > I suppose this is correct. But I found a special corner case today when > it comes to quota calculation. > > When - for whatever reason - a folder .INBOX.foo (for arbitrary values > of foo) exists, the whole mailbox is counted twice in quota > recalculation. Just creating .INBOX does nothing but a subfolder > triggers the problem. > > This is my shell view (replaced username and file path and deleted > unnecessary debug output) > > $ cat maildirsize > 268435456S > 14697 17 > $ maildirmake .INBOX.foo > $ sudo doveadm -D quota recalc -u <user> > [...] > doveadm(<user>): Debug: Namespace inbox: type=private, prefix=INBOX., > sep=., inbox=yes, hidden=no, list=yes, subscriptions=yes > location=maildir:/home/.../test > doveadm(<user>): Debug: maildir++: root=/home/.../test, index=, > indexpvt=, control=, inbox=/home/.../test, alt= > doveadm(<user>): Debug: Namespace : type=private, prefix=, sep=, > inbox=no, hidden=yes, list=no, subscriptions=no location=fail::LAYOUT=none > doveadm(<user>): Debug: none: root=, index=, indexpvt=, control=, > inbox=, alt= > doveadm(<user>): Debug: quota: quota_over_flag check: quota_over_script > unset - skipping > doveadm(<user>): Debug: Quota root User quota: Recalculated relative > rules with bytes=268435456 count=0. Now grace=26843545 > doveadm(<user>): Debug: Namespace INBOX.: Using permissions from > /home/.../test: mode=0700 gid=default > > $ cat maildirsize > 268435456S > 29394 34 > > > So the used quota has exactly been doubled by just creating an empty > subfolder. > > Do you have any pointers for fixing my configuration or is this a bug in > dovecot? > > I coincidentally resurrected a months-old thread with this same issue a few days ago. I'm seeing the exact same after upgrading from 2.2.32 to 2.2.36. The original poster (who also narrowed it down to something in 2.2.34) mentioned a workaround that does indeed work, namely setting mailbox_list_index=no: > doveadm -o 'mailbox_list_index=no' quota recalc -u myuser I've been staring at diffs of 2.2.33 and 2.2.34 without anything jumping out at me (not a C guy, sadly). Maybe src/lib-storage/index/index-storage.c or src/lib-storage/list/mailbox-list-fs-iter.c or src/lib-storage/list/mailbox-list-index-iter.c or src/lib-storage/list/mailbox-list-index.c? The latter few have some added strcmp's against "INBOX". Then again, there's a lot of new code in the diffs under src/lib-storage that references INBOX specifically.

3 5

GSSAPI vs group check
by Németh Ákos Ferenc 05 Aug '19

05 Aug '19

Dear All, Is it possible to make any authorization (eg. checking of group membership) in case of GSSAPI authentication? Our dovecot authenticates the users against PAM and GSSAPI. In the PAM file I'm able to check if a user is a member of a selected (e.g mailreader) group. If the user is member, he can login otherwise not (see below). If the user has a valid Kerberos ticket and he tries to login via GSSAPI, I can't restrict him if he is not a member of the selected group. How can I overcome this issue? My config: passdb { driver = pam # [session=yes] [setcred=yes] [failure_show_msg=yes] [max_requests=<n>] # [cache_key=<key>] [<service name>] #args = dovecot } userdb { # <doc/wiki/AuthDatabase.Passwd.txt> driver = passwd # [blocking=no] #args = # Override fields from passwd #override_fields = home=/home/virtual/%u } ...in PAM file: auth [success=1 default=ignore] pam_succeed_if.so user ingroup mailreader auth [success=ignore default=2] pam_succeed_if.so user ingroup admins auth [success=ignore default=1] pam_succeed_if.so uid >= 1000 auth [success=3 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login auth [success=ignore default=1] pam_succeed_if.so uid < 1000 auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass auth requisite pam_deny.so auth required pam_permit.so Thank you. Br, Ákos

2 3

Bug with latest GCC 9
by Martin Liška 29 Jul '19

29 Jul '19

Hi. As mentioned here: https://bugzilla.opensuse.org/show_bug.cgi?id=1123136 there's a new issue with GCC 9, it's related to: https://gcc.gnu.org/gcc-9/porting_to.html#complit in: /* Not const! Never return this as a result directly! */ #define SMTP_ADDRESS_LITERAL(localpart, domain) \ &((struct smtp_address){ (localpart), (domain) }) Thanks, Martin

2 4

IMAP copy stopped copying flags
by Andrzej A. Filip 29 Jul '19

29 Jul '19

Is it intended behavior? It seems to be caused by upgrade to 1:2.3.2-2 on Debian/Testing. -- A. Filip

4 6