- dovecot - dovecot.org

Advantage of LMTP
by Jerry 02 Aug '14

02 Aug '14

Sat, 2 Aug 2014 06:53:58 -0400 Presently, I have: "virtual_transport = dovecot" in my Postfix main.cf file and dovecot unix - n n - - pipe flags=DRhu user=vmail:vmail argv=/usr/local/libexec/dovecot/dovecot-lda -f ${sender} -d ${recipient} in the master.cf file. Is there any advantage to using LMPT instead? All of my users are configured as virtual users. If I change it, do I have to eliminate the above from my master.cf file? -- Jerry

2 1

[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

Configuring pigeonhole/sieve
by Timothy Murphy 02 Aug '14

02 Aug '14

I've been trying for a few days to get pigeonhole/sieve working in order to filter email with spamassassin. Unfortunately I have had no success; and I have found no document which simply tells me what changes I need to make to which files, and what other action I have to take. I'm running CentOS-7 on my home-server, and have postfix + dovecot working perfectly; moreover spam is marked with ***Spam*** added to the Subject header. The only problem is that this spam is getting through to my inbox. It's clear that I'm overlooking some action I should be taking, and I'm sure there must be a document somewhere that gives simple and complete instructions on setting up pigeonhole/sieve to work with SpamAssassin. If anyone knows of such a document I should be eternally grateful. I was told at one point that "You need to pass your mail through dovecot-lda or lmtp", but I have no idea what this means. I see in /var/log/dovecot when I re-start dovecot "Aug 02 00:13:04 master: Info: Dovecot v2.2.10 starting up for imap, pop3, lmtp, sieve, sieve (core dumps disabled", which seems to imply that lmtp is enabled. Any suggestions or advice gratefully received. -- Timothy Murphy e-mail: gayleard /at/ eircom.net School of Mathematics, Trinity College, Dublin 2, Ireland

2 1

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

using flat file for dictionary quota backend
by www-1223 01 Aug '14

01 Aug '14

Hi! I want use flat file for dictionary quota backend, but I didn't find the description of that he has to contain. Somebody can give an example of such file? PS: sorry for my English. Regards, Oleg Ivanov.

1 0