July 2014 - dovecot - dovecot.org

[Dovecot] Converting old emails to compressed format
by Renaud Allard 02 Aug '14

02 Aug '14

Hello, I know this question has already been asked, but I would really like a solution here as I tried all I could find on the wiki or mail archives I am now running dovecot 2.2.12 Compression works fine for new mails, so zlib works Mails are currently stored using dbox So I tried for testing dsync -D -v mirror -u user -m Archives dbox:~/temp dsync -o "plugin/zlib_save=xz" -D -v mirror -u user -m Archives dbox:~/temp dsync -o "plugin/zlib_save=" -D -v mirror -u user -m Archives dbox:~/temp dsync -o "plugin/zlib_save=" -D -v mirror -u user -m Archives maildir:~/temp dsync -o "plugin/zlib_save=xz" -D -v mirror -u user -m Archives maildir:~/temp And also converting again those maildir messages to dbox (just in case it wouldn't work from dbox format) And also with backup instead of mirror None of this actually works, mails are indeed copied, but not compressed So I am wondering if there is a way to compress those mails? Thank you

5 8

Dovecot EE on SciLinux 6.5: No Config Files in /etc
by Asai 02 Aug '14

02 Aug '14

Greetings, I tried installing Dovecot EE on Scientific 6.5 yesterday, but there was no repo under that release version, so I hardcoded the release version to 6 in yum.repos.d/dovecot.repo. That worked, but when I installed, it didn't install any default configuration files. /etc/dovecot was empty. Is that to be expected for EE? -- --Asai

2 2

Fwd: HIGHESTMODSEQ tracking
by Kostya Vasilyev 01 Aug '14

01 Aug '14

Michael, 2014-07-10 1:37 GMT+04:00 Michael M Slusarz <slusarz(a)curecanti.org>: Quoting Kostya Vasilyev <kmansoft(a)gmail.com>: > > Hello, >> >> I'd like to follow up on someone else's old thread: >> >> http://dovecot.org/list/dovecot/2012-April/082624.html >> >> I understand that Dovecot (that 2012 discussion was about version 2.0.18) >> can return "HIGHESTMODSEQ 1" upon SELECT if persistent modseq tracking was >> never enabled for a mailbox. >> > > This behavior is largely irrelevant ... a client should ignore any > HIGHESTMODSEQ data that is sent if it (the client) hasn't sent a CONDSTORE > enabling command. True, but I was just pointing out a quirk that existed in a older version, to ask for a clarification. > > > I'd like to get a clarification on how to enable proper persistent modseq >> tracking. >> >> Per RFC 4551, "A client supporting CONDSTORE.... indicates its willingness >> to receive mod-sequence updates... by issuing:" >> >> SELECT mailbox (CONDSTORE) >> STATUS (... HIGHESTMODSEQ ...) >> ... others ... >> > > 4551 is deprecated --> it is now RFC 7162. > Thanks, didn't notice that 4551 was "obsoleted". > > Also note there's actually 6 different categories of CONDSTORE-enabling > commands. SELECT/EXAMINE with CONDSTORE is just one of the categories. > There are five listed in RFC 4551, yes, there are six in 7162, but my question was about two specific ones out of those five / six. > > These days, you *really* should be using QRESYNC instead though. There are some mail servers that support CONDSTORE but not QRESYNC. The old chicken and egg IMAP problem :) > > > It seems that Dovecot 2.1.7 (Debian 7.5) enables persistent modseq >> tracking >> after one of the above two commands (and maybe others). So far so good. >> > > Incorrect. Dovecot has supported CONDSTORE/QRESYNC since 1.2.0. Incorrect? I wrote: "it seems that Dovecot 2.1.7 enables persistent modseq tracking...". Are you implying that Dovecot 2.1.7 doesn't enable persistent modseq tracking in this case? I never claimed that earlier versions of Dovecot didn't advertise CONDSTORE or didn't implement it properly, etc. Perhaps I should have written "...after *any* of the two commands... (and maybe others)" -- meaning it does after either of those two commands, and the other ones I don't care about and so didn't test. > And as mentioned above, there are 6 different ways of enabling CONDSTORE. > (Enabling QRESYNC is done 1 way ... the "ENABLE QRESYNC" command). Yes, agreed, noted. I'm asking about two out of those five / six. And not just about what the RFC says, but about how real, out in the field, installed on mail servers that people use, possibly quite old, versions of Dovecot behave. So let me try again: Is sending SELECT ... (CONDSTORE) or STATUS (... HIGHESTMODSEQ ...) enough to enable reliable persistent modseq tracking for all versions of Dovecot which advertise CONDSTORE in their capabilities? Not what the currently relevant RFC says, but how Dovecot versions with CONDSTORE in their caps behave. This is the one thing I'd really like to know. > > > So my questions are: >> >> 1 - Is this (enabling persistent modseq) also the case for all Dovecot >> versions prior to 2.1.7 that advertise CONDSTORE? >> >> There must be people running older versions out there, older than 2.1.7. >> >> If not, how can I branch my logic to not use HIGHESTMODSEQ, given that >> Dovecot doesn't appear to return any version info via its greeting or via >> the ID command? >> > > As noted above, this is irrelevant. As a client author, you should ALWAYS > ignore HIGHESTMODSEQ if you haven't enabled CONDSTORE/QRESYNC . All caps look nice in RFCs, but the real world has more variety :) > > > 3 - I guess the change to return NOMOSEQ instead of "1" for mailboxes with >> modseq tracking disabled, as mentioned in that discussion from 2012, never >> happened? At least on the 2.1 branch? >> > > NOMODSEQ is only relevant *if* you have enabled CONDSTORE. Agreed. However: > Returning NOMODSEQ on mailboxes that don't support persistent > mod-sequences has worked since 1.2.0, at least as far as I know. The linked message from 2012, discussing 2.0.18, says: "2) If a mailbox doesn't have modseqs enabled, return NOMODSEQ. This isn't ideal, but seems like the only possibility" And based on my tests, Dovecot 2.1.7 returns "HIGHESTMODSEQ 1" for mailboxes where modseq tracking has not been enabled. You're largely right about the value only being relevant if the client enabled CONDSTORE, and I don't care too much about this quirk, just wanted to to get a clarification on this as well, if possible. Thanks, -- K

3 7

Differences in "Delivered-To" header between deliver and LMTP
by Jeff Rice 01 Aug '14

01 Aug '14

Hi, I'm transitioning my server over from using the deliver LDA and LMTP. Suddenly a bunch of sieve filters stopped working, and I noticed the contents of the Delivered-To header are different. Using Dovecot's deliver LDA, the contents are a bare email address (foo(a)bar.com) Using Dovecot LMTP, they are in brackets (<foo(a)bar.com>). Is there a reason why this isn't consistent between the two delivery agents? It seems like it ought to be. Jeff

6 7

[PATCH] Fix typo in src/imap-urlauth/imap-urlauth-worker.c
by Jelmer Vernooij 01 Aug '14

01 Aug '14

The attached trivial patch fixes a typo in src/imap-urlauth/imap-urlauth-worker.c. Cheers, Jelmer

2 1

Maybe error in login-common/login-proxy.c/proxy_client_input
by Potapov Sergey 01 Aug '14

01 Aug '14

Hi! It seems that o_stream_cork should be done on proxy->server_output but not on proxy->client_output. o_stream_cork(proxy->client_output); ret2 = o_stream_send(proxy->server_output, buf, ret); o_stream_uncork(proxy->server_output);

2 1

solr_add_definite_query quotes queries
by G H 01 Aug '14

01 Aug '14

So Solr 4.0 and higher supports regular expressions in searching. However, Dovecot is quoting search queries in solr_add_definite_query (via solr_add_str_arg). This breaks regex searching. I do a sample search for emails with "merged" in their body via the query /merg.*/. If you look at the Solr logs, it is sending: q=body:"/merg.*/" which is converted to body:\"/merg.*/\" inside Solr. but if it had sent only: q=body:/merg.*/ then regex would have worked. Is regular expression searching on the dashboard? I'm considering patching fts-backend-solr.c to not quote-enclose the search, but am looking for any better suggestions. Or perhaps not quote-enclose if the search is prefixed with RX: (ie: "RX:/merg.*/")... Thanks, G H

2 1

Re: [PATCH] Fix typo in src/imap-urlauth/imap-urlauth-worker.c
by Jelmer Vernooij 01 Aug '14

01 Aug '14

On Sun, Jul 20, 2014 at 12:50:43AM +0200, Jelmer Vernooij wrote: > The attached trivial patch fixes a typo in src/imap-urlauth/imap-urlauth-worker.c. Ping? > diff -r fd0616d553b0 -r 6fabd9046558 src/imap-urlauth/imap-urlauth-worker.c > --- a/src/imap-urlauth/imap-urlauth-worker.c Fri Jul 11 16:49:35 2014 +0300 > +++ b/src/imap-urlauth/imap-urlauth-worker.c Sun Jul 20 00:29:35 2014 +0200 > @@ -478,7 +478,7 @@ > } > if (client_run_url(client) < 0) { > client_abort(client, > - "Session aborted: Fatal failure while transfering URL"); > + "Session aborted: Fatal failure while transferring URL"); > return 0; > } > }

1 0

Solr 4+ schema.xml?
by G H 31 Jul '14

31 Jul '14

Does anyone have a Solr 4+ compatible schema.xml for dovecot indexing? I am trying to test to see if regex-based FTS searching works through IMAP, but Solr 4.9.0 is throwing an error, "SolrException: undefined field text", on startup with the schema.xml included with Dovecot 2.2.9. Thanks. G H

2 2

Issue with exim and auth protocol
by Mildred Ki'Lya 31 Jul '14

31 Jul '14

Hi, I'm trying to set up exim (4.83) as a submission server, and need to set up the dovecot authentication in exim. I'm having an issue with that (documented at <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756258>) The problem is that exim doesn't follow the handshake as described here: <http://wiki2.dovecot.org/Design/AuthProtocol>. The wiki page says that the client should start the handshake, but exim waits for the server to start and to receive the DONE command until it starts its own handshake. What I actually get is: exim connects to dovecot auth dovecot VERSION 1 1 dovecot SPID 48 And then, dovecot stops (I presume it waits for the client handshake, VERSION and CPID). Exim on its side waits for the DONE. This results in the SMTP connection by exim never replying to the AUTH PLAIN command. This is exim 4.80 (or 4.83) and dovecot 2.1.7. I have another server set up almost exactly the same (but with dovecot 2.1.17) where it does work. In that case, dovecot finishes the handshake before exim starts its handshake. It results in: exim connects to dovecot auth dovecot VERSION 1 1 dovecot MECH PLAIN plaintext dovecot SPID 10905 dovecot CUID 1 dovecot COOKIE d3861d29441f06d962490eab8549fd46 dovecot DONE exim VERSION 1 0 exim CPID 10619 exim AUTH 1 PLAIN service=smtp secured rip=82.247.184.53 lip=80.67.179.36 nologin resp=<base64 encoded string> I don't understand what could change the dovecot behaviour in that regard. Is there a solution that would only require modifying the configuration? Thank you, Mildred

3 6