Missing hits when performing full-text searches
Hi,
we're running Dovecot 2.1.7 together with Solr for efficient fulltext search.
A couple of days ago we reinstalled our Solr server on a new machine. After
adjusting our Dovecot setup to use the new server, it took a few days to
notice that something seems fishy about our full-text search: expected hits
wouldn't be shown among the search results.
For instance, one of the folders (a shared, read-only folder which is
basically a mailinglist archive) with about 210k messages has a plaintext
mail with the text 'Amman'. However, logging into the IMAP server and
issueing a
. SEARCH TEXT Amman
In the folder doesn't yield any hits. It seems that this happens for older
mails only -- trying other keywords, we did notice hits in recent mails but
not in older ones. Some caching related to the old Solr server causing
issues?
Debugging this further, I noticed that the above IMAP command shows this in
the Solr log files:
INFO: [] webapp=/solr path=/select
params={fl=uid,score&sort=uid+asc&q=(hdr:"Amman"+OR+body:"Amman")&fq=%2Bbox:b68ece09e22fb9502d34010017227a26+%2Buser:""&rows=209392}
hits=0 status=0 QTime=229
And indeed, something like
$ curl
'http://indexer:8080/solr/select?fl=uid,score&sort=uid+asc&q=(hdr:"Amman"+OR+body:"Amman")&fq=%2Bbox:b68ece09e22fb9502d34010017227a26+%2Buser:""&rows=209392'
Yields no results. However, I noticed that if I remove the 'fq=' part from
the query then I get a bunch of hits. Alas, I don't know whether those are to
be expected or not.
Does anybody have an idea what might cause this, or what the meaning of that
'box' checksum is?
--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing
Re: Subject tag [Dovecot] is gone
On 2014-06-10 17:23, Koenraad Lelong wrote: op 10-06-14 17:12, Reindl Harald schreef: than you have crap software somewhere on your side What did I do to get such reply ? Don't bother paying too much attention, Harald has been quite the primadonna ever since I joined this list. Pretty sure he's one of those fellows who are doing the 'grumpy curmudgeon' on the Internet but then turn out to be rather quiet/shy guys in real life. ;-) - Frerich
Re: [Dovecot] imap-login killed with signal 11 in Dovecot 2.2.13 (feea8645c4d7)
On 2014-06-09 22:06, Timo Sirainen wrote: Should be fixed by these: http://hg.dovecot.org/dovecot-2.2/rev/7129fe8bc260 http://hg.dovecot.org/dovecot-2.2/rev/5259f6320e52 Thanks for being so transparent with the development of Dovecot. Reading through the last couple of fixes you did I wondered - do you have some separate repository (or directory?) for the (unit) tests? I suppose an IMAP server as popular as Dovecot must have some fairly extensive test suite but I only found the 'run-test.sh' script so far (and the 'src/lib-test' directory which doesn't seem to contain much). -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Sizing MTA servers
On 2014-01-17 10:53, Stan Hoeppner wrote: On 1/16/2014 6:56 PM, Murray Trainer wrote: This is probably a bit off-topic but does anyone have any idea about sizing MTA servers. We have about 200,000 emails/hr incoming and outgoing. I am intending using Exim and Spamassassin on each MTA. How many servers using recent hardware would I need to cope with this mail throughput? The number of boxen is irrelevant to the question of msg rate, as is the CPU. You can easily do your 56 msgs/sec with one box containing a 10 year old 2GHz single core CPU, as long as you have enough memory for the concurrent TCP connections, and sufficient IOPS. The only thing in this scenario needing CPU is spamassassin, unless you forgot to mention clamav. [..] Stan, I just wanted to mention that even though I didn't ask the question (nor is the answer to it relevant to me in practice, right now) I greatly appreciated your elaborate response and the insight. It's pearls like this one which keep me on the list despite the occasional flamewar. ;-) -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] zlib plugin question
On 2013-12-19 17:51, Frerich Raabe wrote: On 2013-12-19 16:07, Przemysław Orzechowski wrote: Is it possible to compress incoming mails delivered via dovecots LDA when using dovecot --version 1.2.9 or do i have to compress them via cron? There is a zlib plugin for Dovecot 1.x you could use. See http://wiki1.dovecot.org/Plugins/Zlib Sorry, I only now noticed that this plugin only allows reading compressed mail files - apparently you would need Dovecot v2.x if you want to compress incoming mail. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] zlib plugin question
On 2013-12-19 16:07, Przemysław Orzechowski wrote: Is it possible to compress incoming mails delivered via dovecots LDA when using dovecot --version 1.2.9 or do i have to compress them via cron? There is a zlib plugin for Dovecot 1.x you could use. See http://wiki1.dovecot.org/Plugins/Zlib -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Size detection/replair does not work with zlib
On 2013-12-12 12:47, Roland Rosenfeld wrote:
Hi!
Usually dovecot auto detects or repairs the size of a maildir
message. So I can place a message named "foo" in the cur directory
and dovecot uses it.
Now I tried the same with a zlib compressed message but here dovecot
doesn't recognize/repair the size of the message.
When I access this folder via IMAP the connection is diconnected and
in dovecot logs I see the following error messages:
[..]
Error: Cached message size smaller than expected (805 < 2666)
Error: Maildir filename has wrong S value, renamed the file from
/somedir/cur/1386772057.M152553P9709.host,S=805:2, to
/somedir/cur/1386772057.M152553P9709.host,S=805:2,
So here dovecot detects the wrong S value, but instead of fixing it
by
using the uncompressed size, it renames to the same file name as
before...
I observed exactly the same issue ever since I enabled the zlib
plugin on our IMAP server, running dovecot 2.1.7.
For what it's worth, I wrote a small shell script which, given a
Maildir directory, looks for all files for which the S= value doesn't
match the effective file size (i.e. for zlib-compressed files,
the S= value should match the *uncompressed* file size, for
plain files the S= value should match the physical file sie). The
script the attempts to print appropriate 'mv' commands for renaming
the files as needed. Maybe it helps, I attached it to this mail.
--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing#!/bin/sh
files=`find "$1" -type f`
for f in $files; do
actual_size=`ls -l "$f" | awk '{print $5}'`
expected_size=`echo $f | sed -e 's,.*S=\([0-9]\+\).*,\1,'`
if file "$f" | grep gzip > /dev/null; then
if test $actual_size -eq $expected_size; then
real_size=`zcat "$f" | wc -c`
# echo "$f (gzipped): expected $expected_size, actual $actual_size,
real $real_size"
real_filename=`echo $f | sed -e
"s,\(.*\)S=[0-9]\+\(.*\),\1S=$real_size\2,"`
echo "mv \"$f\" \"$real_filename\""
fi
else
if test $actual_size -ne $expected_size; then
# echo "$f (raw): expected $expected_size, actual $actual_size"
real_filename=`echo $f | sed -e
"s,\(.*\)S=[0-9]\+\(.*\),\1S=$actual_size\2,"`
echo "mv \"$f\" \"$real_filename\""
fi
fi
done
Re: [Dovecot] Zlib plugin - when does it make sense?
On 2013-11-25 14:35, Jan-Frode Myklebust wrote: On Mon, Nov 25, 2013 at 09:53:14AM +0100, Frerich Raabe wrote: I run a small IMAP server for a dozen guys in the office, serving about 55GB of Maildir. I recently became aware of the Zlib plugin ( http://wiki2.dovecot.org/Plugins/Zlib ) and wondered 1. given that there is about zero CPU load on my IMAP server, is enabling the plugin a no-brainer or are there other things (except CPU load) to consider? Yes, it's a no-brainer. I can't remember how the cpuload was before we enabled zlib, but our cpus are running 80% idle (6 servers, mix of IBM x3550 and x346, serving 15TB mdbox, but was serving maildir with zlib a year ago). Interesting! What zlib compression level did you use? I figure even low levels would work rather well for plain text. Now that I think about "plain text": I also have the fts_solr plugin enabled to speed up the occasional full-text search - does the indexing still work as before when the mail is compressed, i.e. is the reading of the mail centralized so that the individual plugins don't actually know or care? Or would I need to make sure I use 'zlib-aware' plugins? -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
[Dovecot] Zlib plugin - when does it make sense?
Hi, I run a small IMAP server for a dozen guys in the office, serving about 55GB of Maildir. I recently became aware of the Zlib plugin ( http://wiki2.dovecot.org/Plugins/Zlib ) and wondered 1. given that there is about zero CPU load on my IMAP server, is enabling the plugin a no-brainer or are there other things (except CPU load) to consider? 2. For enabling the plugin, I suppose you compress all the existing mail just once and then add 'zlib' to mail_plugins in order to have all future incoming mail saved? Any insight by people familiar with the plugin would be much appreciated - thanks! -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Encryption solution for messages at rest
On 2013-10-30 16:03, Miquel van Smoorenburg wrote: On 28/10/13 23:22, Frerich Raabe wrote: You could imagine a system which requires users to generate a key pair and then submit their public key. The mail system will encrypt all mail received for a user with that users public key. When accessing the mail, the user configures his user agent to use the private key to decrypt the mail. [..] Well you can generate the public and private key on the server, then set the users password as the keyphrase, and leave it stored on the server. Incoming mail would be automatically encrypted with the public key, then stored. When the user logs in to imap/pop the password is not only used for authentication, but also to unlock the private key. Dovecot can then decrypt the messages on the fly. Basically this is how Lavamail worked. It is reasonably secure, but doesn't help against a hostile root user on the server that hacks dovecot to just log the password when a user logs in. Or someone who has acquired your SSL keys and taps your internet connection. The whole idea of using asymmetric encryption was that the server *does not* have the private key. It only has the public key, so it can store incoming mail encrypted using the users public key (which requires no password). Dovecot would then just serve the encrypted mail, all encryption would happen on the client side using the private key which only the client has. In the case of Maildir, I suspect (but I don't know) that Dovecot doesn't treat the individual files as plain data: it does look into them when serving (not only when indexing) to parse some headers or so. So I guess you cannot just encrypt the raw file on disk but you rather have to "rewrite" the mail so that only the body is encrypted but the headers are left untouched. This means that a hostile root user could see the headers, but at least not the body of the message. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Encryption solution for messages at rest
On 2013-10-28 20:23, Reindl Harald wrote: Am 28.10.2013 20:14, schrieb Douglas Mortensen: However, it would be nice to know that even if we were breached, the emails on the server were encrypted and would be completely useless to an attacker. This type of encryption is ideal and some regulations prefer (although don't require) it impossible and useless if someone comes that far he can also read whatever configuration containing the keys In principle, this can be addressed by employing asymmetric key encryption. You could imagine a system which requires users to generate a key pair and then submit their public key. The mail system will encrypt all mail received for a user with that users public key. When accessing the mail, the user configures his user agent to use the private key to decrypt the mail. In practice, it's probably not that easy: 1. I suppose you'd have to be careful to not break features like server-side searching though. If you only store encrypted mail, the only moment where the system sees the plain mail is when it's received. So you'd probably need to index it at that point and then use that index for subsequent queries. Once the mail is written to disk, the server never sees the real data anymore. 2. Different mail storage formats probably work differently well. mbox is right out, with Maildir it might not be acceptable to encode the raw mail file - I don't know whether Dovecot uses any actual contents of files with Maildir (as opposed to the Dovecot-specific indices and the file name). If it does, then you should maybe just encrypt just the body but no headers or similiar. There's surely more to consider, but I think this is anything but "impossible and useless". Accessing sensitive data which is stored on an untrusted system is an old and solved problem, I wouldn't be surprised if you just have to consider implementation details in the case of a mail server. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] secure email server
On 2013-10-23 13:21, Reindl Harald wrote: Am 23.10.2013 13:16, schrieb BONNET, Frank: my first question is : does postfix and dovecot are able to use an encrypted filesystem such as Encfs? dovecot and postfix are userland-applications it's not their job to bother about a filesystem this is a kernel-task Not all userland applications work equally well with all filesystems (consider programs which work poorly with NFS because they are built around the assumption that certain syscalls are fast). - Frerich
Re: [Dovecot] Sieve Filter global vs user specific
On 2013-09-10 15:42, inkubus wrote:
QUESTION: Can cause dovecot somehow not to follow the user specific
rules
that apply to a message after going through my global ones? The mail
has to
remain directly in the inbox (and must not be forwarded by the user
specific
filter aftwerwards)
[..]
My configuration: dovecot.conf (excerpt):
plugin {
sieve = /home/%n/.dovecot.sieve
sieve_dir = /home/%n/.mailstore/sieve
sieve_global_dir = /etc/dovecot/sieve/
sieve_before = /etc/dovecot/sieve/global
}
/etc/dovecot/sieve/global:
require ["vacation","copy","fileinto","body","imap4flags"];
# rule:[Redirect]
if anyof(header :contains "From"
"f...ing.telefonanlage@firma.intern",
header :contains "Subject" "Sprachnachricht")
{
stop;
}
You're almost there, I think. Just add a
fileinto "INBOX";
before the "stop;" to have the message get stored in the INBOX of the
recipient
and then stop any further processing.
--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Calling dovecot-lda correctly from exim for virtual user setup
On 2013-08-02 14:25, Timo Sirainen wrote: On Tue, 2013-07-30 at 14:55 +0200, Frerich Raabe wrote: I'm running Dovecot 2.1.7 on Debian. Exim is the MTA. I was recently made aware of the fact that the way in which Exim invokes dovecot-lda is prone to code injection: dovecot_virtual_delivery: driver = pipe command = HOME=/home/vmail/\$local_part /usr/lib/dovecot/dovecot-lda -f \$sender_address use_shell .. I.e. a command is executed via the shell, and Exim uses non-sanitized user input (mail header fields) to construct the command. Now, the reason I invoked dovecot like that is to pass a plausible value for the HOME environment variable, so that dovecot-lda can determine where the Maildir directory of the recipient is. Is there any way to achieve this without requiring HOME to be set correctly? I looked at the -m switch but as far as I can see that merely defines the destination mailbox, but not the path to the Maildir directory, correct? Maybe set mail_home = /home/vmail/%n ? Sorry for the late reply, I totally forgot to follow-up on this. Setting mail_home didn't seem to help (according to 'doveadm user' the home directory was already computed corretly). It turned out that what *did* help was to pass '-d $local_part' to dovecot-lda. Apparently that makes it do a userdb lookup which in turn makes it figure out the home directory. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Maximum number of connections from user+IP exceeded
On 2013-08-19 23:00, Stan Hoeppner wrote: * a IMAP client opens one connection *per folder* What do you mean by "per folder"? I've been limiting Tbird to 2 IMAP connections for many years and, unsurprisingly, it never opens more than two IMAP connections to Dovecot no matter how many folders I access, tabs I have open, or searches I perform, etc: tcp 0 0 192.168.100.9:143 192.168.100.53:1663 ESTABLISHED 13189/imap tcp 0 0 192.168.100.9:143 192.168.100.53:1672 ESTABLISHED 13192/imap And with the default TB limit of 5 it never opens more than 5. Which clients exhibit this "per folder" connection behavior? That seems totally unnecessary. Any client which supports the 'IDLE' command does this; it's a mechanism to avoid that a client has to poll the IMAP server for new mail. The client does an 'IDLE' call *per folder* which only returns when the server adds new mail to the folder. Hence, the IDLE call blocks the connection, which is why mail clients which use IDLE have to establish multiple IMAP connections, one per folder which is monitored using this feature. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Calling dovecot-lda correctly from exim for virtual user setup
On 2013-07-30 14:55, Frerich Raabe wrote: Now, the reason I invoked dovecot like that is to pass a plausible value for the HOME environment variable, so that dovecot-lda can determine where the Maildir directory of the recipient is. ...for the sake of completeness: this stems from the fact that I use mail_location = maildir:~/Maildir in my dovecot.conf -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
[Dovecot] Calling dovecot-lda correctly from exim for virtual user setup
Hi, I'm running Dovecot 2.1.7 on Debian. Exim is the MTA. I was recently made aware of the fact that the way in which Exim invokes dovecot-lda is prone to code injection: dovecot_virtual_delivery: driver = pipe command = HOME=/home/vmail/\$local_part /usr/lib/dovecot/dovecot-lda -f \$sender_address use_shell .. I.e. a command is executed via the shell, and Exim uses non-sanitized user input (mail header fields) to construct the command. Now, the reason I invoked dovecot like that is to pass a plausible value for the HOME environment variable, so that dovecot-lda can determine where the Maildir directory of the recipient is. Is there any way to achieve this without requiring HOME to be set correctly? I looked at the -m switch but as far as I can see that merely defines the destination mailbox, but not the path to the Maildir directory, correct? -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Archiving mail
On 2013-07-18 14:14, Koenraad Lelong wrote: I'm going to migrate my company-mailserver to new hardware. I would like to take the opportunity to archive some older mail. But I would like to have it still accessible, would this be possible with dovecot ? I mean, I would like to put that older mail from different users (I got about 50 users) on some read-only media but mount that media in the users mail-dirs. That way I will have less to backup after I backup that old mail and store it safely away. I can't convince my users to really clean up their mailboxes, so I backup more than 100GB mail while the total backup is a bit more than 300GB. I cannot really answer your question, but seeing that the size of the backups is what triggers your question: We use Maildir as the mail format and our backups are done using rsync (rsnapshot, to be precise). This seems to scale reasonably well, i.e. rsync just copies those files which need to be copide, and rsnapshot creates hardlinks to previous backups as far as possible. So our nightly backups are actually fairly small, most of them consist of hardlinks to the next older backup we did. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Who all accessed my dovecot server?
Am 7/3/2013 10:32 AM, schrieb pvsuja: I have set up a mail server with dovecot as IMAP/POP3 server, postfix as MTA and roundcube as web mail client. Other mail clients such as Thunderbird is also being used for mail access. Now as a security policy in our organization, I want to know the IP addresses of the machines from which my mail server was accessed. Is there any monitoring tools to get these details? A cron job doing grep "imap-login: Login:" /var/log/maillog might do the job already. The 'rip=' part of the matches tells you the remote IP. Instead of /var/log/maillog you might have to check another file (it depends on your Dovecot setup). -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Dovecot 2 and managesieve
On Jun 25, 2013, at 7:09 PM, Darek wrote: > Having some difficulty finding out whether managesieve is still a separate > package (not seeing it in the FreeBSD ports tree, only one for 1.x) or > whether it was integrated into the main 2.x package. > > I've only been using 1.2.x up to now, and trying to document a system > install. So is it in the main distribution now? It's part of the pigeonhole plugin, I think; see /usr/ports/mail/dovecot2-pigeonhole -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Allowing clients to test their Sieve scripts
On Jun 14, 2013, at 7:05 PM, Ben Morrow wrote: > At 6PM -0700 on 14/06/13 you (Frerich Raabe) wrote: >> >> Nice, judging from the source code it looks very much like what I was >> thinking of! However, as it happens my IMAP server is *very* minimalistic >> (it runs FreeBSD and has just 9 software packages installed, the bare >> minimum I needed for Dovecot and Exim - the only luxury I have is vim :]). >> >> I'm not sure how much stuff PHP pulls in, but I was thinking of writing >> a tiny Python script (since that is included in FreeBSD by default) > > Um, no it isn't. Perl and Tcl were in base for a while, though they > aren't any more, but Python has never been. Probably you pulled it in by > mistake when you installed vim (try the vim-lite port instead). I stand corrected; I do have the vim-lite port installed already, but I just didn't realize that I don't have Python yet - I though it's there but it never was. :-) -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Allowing clients to test their Sieve scripts
Hi, On Jun 14, 2013, at 10:11 AM, Ben Johnson wrote: > It seems as though the only truly reliable method would be to validate > the scripts in consideration of your own environment. As you suggested, > a simple Web form (ideally, one that requires authentication) into which > users can paste scripts and email bodies would do the job. The form > inputs can then be passed to sieve-test. Needless to say, the form > inputs should be escaped very carefully to prevent arbitrary code from > being executed on your system. I just re-read your mail, and I must admit I don't understand one part: why would I need authentication? I was thinking of just serving a HTML form via https which expects you to pass a sample mail and a Sieve script, and when submitting that sieve-test is executed and you see the result. I suppose you were thinking of a different usage, something like - a user logs in with his IMAP credentials, uploads a random mail and then the web server uses the Sieve script which is currently active? -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Allowing clients to test their Sieve scripts
On Jun 14, 2013, at 2:21 PM, Ben Johnson wrote: > In the meantime, here's a very rough-cut of a PHP script that accepts a > Sieve script and an email body, and prints-out the "sieve-test" results. > > http://pastebin.com/7mHL2w0z > > This works fine on my server. Next week, I'll add authentication. > > Would love to know if this works for you, too, Frerich. Nice, judging from the source code it looks very much like what I was thinking of! However, as it happens my IMAP server is *very* minimalistic (it runs FreeBSD and has just 9 software packages installed, the bare minimum I needed for Dovecot and Exim - the only luxury I have is vim :]). I'm not sure how much stuff PHP pulls in, but I was thinking of writing a tiny Python script (since that is included in FreeBSD by default) which implements a simple HTTP server, I did that once and it was fairly straightforward). -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Allowing clients to test their Sieve scripts
On Jun 14, 2013, at 11:42 AM, Ben Johnson wrote: > Sounds as though you've answered your own question. You probably need to > build some type of Web interface for sieve-test that is well-secured and > well-escaped. Looks like it. Kinda surprising that nobody else needed this, though - I wouldn't have thought it's than uncommon a requirement. :-) OTOH, that's some incentive for me to write something which is reasonably reusable as opposed to being specific to my particular setup. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Allowing clients to test their Sieve scripts
On Jun 14, 2013, at 11:07 AM, Ben Morrow wrote: > At 9AM -0700 on 14/06/13 you (Frerich Raabe) wrote: >> >> One thing which came up repeatedly is that clients using the IMAP >> server I run (using Dovecot 2.1) wonder whether they broke their Sieve >> scripts, i.e. it often goes like "I don't know whether I just didn't >> receive any mail, or whether my filters broke. Can you check the >> logs?". >> >> I then usually just run the sieve-test binary (part of the Pigeonhole >> distribution) and send them the output. However, I was wondering - is >> there maybe a way for them to try it themselves? Like, maybe a tiny >> web server which just prints a form asking for a mail file and a sieve >> script, and then it runs sieve-script and prints the output of that? I >> wonder how other people do that. > > Simply providing some way for them to read the .dovecot.sieve.log file > created in their home directory would be a good start. If there are any > problems with delivery they will be logged there. You could set up some > sort of web access, or even have a daily cronjob to mail the file to the > user if it isn't empty. .dovecot.sieve.log really only contains errors, right? Like, trying to fail mail into folders with invalid characters in them or so? I would need something which explains how a given Sieve script is executed for a given mail. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Allowing clients to test their Sieve scripts
On Jun 14, 2013, at 9:50 AM, Thomas Harold wrote: > On 6/14/2013 12:40 PM, Frerich Raabe wrote: >> Hi, >> >> One thing which came up repeatedly is that clients using the IMAP server I >> run (using Dovecot 2.1) wonder whether they broke their Sieve scripts, i.e. >> it often goes like "I don't know whether I just didn't receive any mail, or >> whether my filters broke. Can you check the logs?". >> >> I then usually just run the sieve-test binary (part of the Pigeonhole >> distribution) and send them the output. However, I was wondering - is there >> maybe a way for them to try it themselves? Like, maybe a tiny web server >> which just prints a form asking for a mail file and a sieve script, and then >> it runs sieve-script and prints the output of that? I wonder how other >> people do that. >> > > If you have Thunderbird, you may want to have them try out the Sieve plug-in > available at http://sieve.mozdev.org/ > > It auto-compiles and displays errors in the edit window. > > The other thing we do is use RoundCube webmail (which has a sieve plugin) and > have our users edit their sieve scripts through that instead. It's a > form-based rules editor, so a bit harder for them to goof it up. Thanks for your response (and the others who responded to this thread!). I also have RoundCube setup and indeed many people use that, since you can even switch to an 'Advanced Mode' in the editor in which you just get the raw Sieve script to edit in a text editor. However, I wasn't primarily thinking of syntax errors but rather logic errors in the script, like "Why did this mail get discarded?" or "Why did this mail end up in folder XYZ?". sieve-test can at least print a nice description (and I seem to recall you could even get some verbose output from it so that you could see all the decisions it took). -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
[Dovecot] Allowing clients to test their Sieve scripts
Hi, One thing which came up repeatedly is that clients using the IMAP server I run (using Dovecot 2.1) wonder whether they broke their Sieve scripts, i.e. it often goes like "I don't know whether I just didn't receive any mail, or whether my filters broke. Can you check the logs?". I then usually just run the sieve-test binary (part of the Pigeonhole distribution) and send them the output. However, I was wondering - is there maybe a way for them to try it themselves? Like, maybe a tiny web server which just prints a form asking for a mail file and a sieve script, and then it runs sieve-script and prints the output of that? I wonder how other people do that. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Multiple user sharing a single mailbox
On Jun 13, 2013, at 7:55 PM, Timo Sirainen wrote: > The \Seen flag could be made per-user, preferrably with v2.2's INDEXPVT > setting. Otherwise you'd have to use maildir and you'd have to manually > create a dovecot-shared file to each such maildir (every time a new one is > created). Is there some documentation on the semantics of INDEXPVT? I checked the Wiki page http://wiki2.dovecot.org/SharedMailboxes/Public and also performed a full-text search for "INDEXPVT", but couldn't find anything. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Mailbox conversion/importing
Hi Robert, On Jun 10, 2013, at 8:23 AM, Robert Brockway wrote: > I've done a variety of mail migrations over the years, including some that > were quite large (hundreds of thousands of accounts). I looked at a few > options when doing the first one and ended up concluding that pop/imap was > the best way to go. A specialised migration tool must be less tested (and > perhaps more buggy) than pop/imap servers that are in use around the world > constantly. By using pop/imap proxies we were able to do migrations that > were completely transparent to users. I think this sounds very plausible - can you maybe elaborate a bit on how you did this exactly? Would you say that it even makes sense to use a proxy-based migration if you're moving from one Dovecot installation (serving just IMAP) to another? I'm just asking because I'm planning to replace a FreeBSD-based Dovecot setup (serving just IMAP) to Debian. I already have the Debian system set up, but I'm still undecided how to do the move in a way which is a) preferrably transparent to users and b) possibly even allows me to quickly switch back to the old system again, just in case. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
[Dovecot] File permissions used for automatically created mailbox
Hi, I'm running Dovecot 2.1.12 on FreeBSD (quite successfully so, thanks for this nice piece of software!). One thing which is slightly annoying though is that automatically created mailboxes (I have lda_mailbox_autocreate set) don't have the file permissions I'd like them to have. I'm using a vmail-based system, i.e. all mail is owned by vmail:vmail; another member of the vmail group is called 'backup', which has read access to all mail in order to create backups. All mail is stored beneath /home/vmail, e.g. /home/vmail/frerich/Maildir Right now, newly created mailbox directories (e.g. /home/vmail/bob) have 0700 permissions, but I'd like to have 0750 for all directories and 0640 for all files so that all files and directories are group-readable for backup purposes. Does anybody know whether this is configurable somehow? Right now, my workaround consists running this cron script every night: #!/bin/sh chown -R vmail:vmail /home/vmail/ find /home/vmail/ -type d -print0 | xargs -0 chmod 0750 find /home/vmail/ -type f -print0 | xargs -0 chmod 0640 -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Squat FTS plugin not kicking in
Am 1/8/2013 9:40 PM, schrieb Frerich Raabe: Hi, I'm running Dovecot 2.1.12 on FreeBSD. I configured Dovecot to use the Squat plugin to provide faster full-text searches. The output of 'dovecot -n' is attached to this mail. However, I just noticed that this plugin doesn't seem to kick in. [..] Does anybody have some idea how to get more logging out of index-worker, or whether there's a flaw in my configuration? I just noticed the mistake; apparently the "doveconf -n" invocation to migrate my Dovecot 1.2.18 setup to Dovecot 2.1.10 wasn't quite complete: the 'mail_plugins = fts fts_squat' part is not only needed in the "protocol imap" section but also on the global level! -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
[Dovecot] Squat FTS plugin not kicking in
Hi,
I'm running Dovecot 2.1.12 on FreeBSD. I configured Dovecot to use the Squat
plugin to provide faster full-text searches. The output of 'dovecot -n' is
attached to this mail.
However, I just noticed that this plugin doesn't seem to kick in. A raw telnet
session seems to confirm this:
[..]
. SEARCH BODY abcdefg
* OK Searched 57% of the mailbox, ETA 0:06
* SEARCH 3425 6254 14710
. OK Search completed (17.262 secs).
. SEARCH BODY abcdefg
* OK Searched 63% of the mailbox, ETA 0:05
* SEARCH 3425 6254 14710
. OK Search completed (18.651 secs).
[..]
A SEARCH BODY command doesn't create the dovecot.index.search or
dovecot.index.search.uids files mentioned on
http://wiki2.dovecot.org/Plugins/FTS/Squat . Also, two subsequent SEARCH BODY
invocations don't seem to be any different as far as search time goes.
I checked the logs but couldn't see anything which is related, except:
Jan 8 21:36:10 imap2 dovecot: indexer-worker(frerich): Indexed 0 messages in
INBOX
Does anybody have some idea how to get more logging out of index-worker, or
whether there's a flaw in my configuration?
--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing
# 2.1.12: /usr/local/etc/dovecot/dovecot.conf
# OS: FreeBSD 9.0-RELEASE i386
auth_mechanisms = plain login
disable_plaintext_auth = no
first_valid_gid = 1000
first_valid_uid = 1000
lda_mailbox_autocreate = yes
mail_location = maildir:~/Maildir
mail_privileged_group = mail
managesieve_notify_capability = mailto
managesieve_sieve_capability = fileinto reject envelope encoded-character
vacation subaddress comparator-i;ascii-numeric relational regex imap4flags copy
include variables body enotify environment mailbox date ihave
namespace {
inbox = yes
location =
prefix =
separator = /
type = private
}
namespace {
location =
maildir:/home/vmail/lists/Maildir:CONTROL=~/Maildir/lists:INDEX=~/Maildir/lists
prefix = Lists/
separator = /
subscriptions = no
type = public
}
namespace {
location = maildir:/home/vmail/lists/archive/Maildir
prefix = Lists/Archive/
separator = /
subscriptions = no
type = public
}
passdb {
args = session=yes dovecot
driver = pam
}
passdb {
args = /usr/local/etc/dovecot/dovecot-ldap.conf
driver = ldap
}
plugin {
acl = vfile
fts = squat
fts_squat = partial=4 full=4
sieve = ~/.dovecot.sieve
sieve_before = /usr/local/etc/dovecot/sieve/keep-broadcast-mail.sieve
sieve_dir = ~/Maildir/sieve
}
protocols = imap sieve
service auth {
user = root
}
service imap {
vsz_limit = 512 M
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
inet_listener sieve_deprecated {
port = 2000
}
}
service managesieve {
vsz_limit = 512 M
}
ssl_cert =
Re: [Dovecot] Cannot STORE \Seen flag on some mails
Am 11/28/2012 9:52 AM, schrieb Frerich Raabe: Am 11/28/2012 2:26 AM, schrieb Timo Sirainen: On 27.11.2012, at 15.06, Frerich Raabe wrote: If I relax the ACL, I can mark the mail as seen myself. I guess that means the question is - why didn't the sieve_before manage to set the flag in all cases. Difficult to say, but I don't think it's worth debugging with v1.2. Might be fixed already in v2.1.. Hm, maybe indeed a reason to stop tip-toeing around upgrading to v2.1... the christmas season is coming, maybe this upgrade would be a good proejct for the vacation. ;-) For the record, upgrading to Dovecot 2.1.10 and the Pigeonhole plugin helped as far as I can see. Upgrading wasn't too painful (the doveconf-based conversion helped even though the generated configuration file was incomplete) either. Ever since I upgraded I now longer saw the described behaviour. Just in case anybody ever has the same issue and finds this thread in some email archive. :-) -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Cannot STORE \Seen flag on some mails
Am 11/28/2012 2:26 AM, schrieb Timo Sirainen: On 27.11.2012, at 15.06, Frerich Raabe wrote: If I relax the ACL, I can mark the mail as seen myself. I guess that means the question is - why didn't the sieve_before manage to set the flag in all cases. Difficult to say, but I don't think it's worth debugging with v1.2. Might be fixed already in v2.1.. Hm, maybe indeed a reason to stop tip-toeing around upgrading to v2.1... the christmas season is coming, maybe this upgrade would be a good proejct for the vacation. ;-) Thanks for your comment! -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Cannot STORE \Seen flag on some mails
Am 11/27/2012 1:53 PM, schrieb Frerich Raabe: I first suspected a client issue so I did a little IMAP session by hand: [..] Note how the first 'SEARCH UNSEEN' command shows that '27126' is unseen, the subsequent 'STORE' command succeeds - but then 'SEARCH UNSEEN' still shows 27126 as unseen! Sorry, I only now realized that my IMAP session wasn't very useful since the dovecot-acl file didn't allow my user to modify the \Seen flag (it only allowed it for the user which runs the Sieve script filing the mail into the archive [and marking it as seen]) in the first place. If I relax the ACL, I can mark the mail as seen myself. I guess that means the question is - why didn't the sieve_before manage to set the flag in all cases. -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
[Dovecot] Cannot STORE \Seen flag on some mails
Hi, I'm running Dovecot 1.2.17 on FreeBSD (exact output of 'dovecot -n' is atttached to this mail). The machine is serving a public mailinglist archive which is read-only; all mail arriving for the archive is marked as \Seen using Sieve script. This setup works well most of the time, but I noticed that for *some* mails, the \Seen flag doesn't seem to be stored. Right now I have 31255 mails in one of my folders and I can't seem to mark five of them as \Seen - the others work just fine. I first suspected a client issue so I did a little IMAP session by hand: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready. . LOGIN "xx" "yy" . OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS ACL RIGHTS=texk] Logged in . SELECT "Lists/Archive/squish" * FLAGS (\Answered \Flagged \Deleted \Seen \Draft $NotJunk) * OK [PERMANENTFLAGS ()] Read-only mailbox. * 31250 EXISTS * 0 RECENT * OK [UNSEEN 27126] First unseen. * OK [UIDVALIDITY 1350573750] UIDs valid * OK [UIDNEXT 31265] Predicted next UID * OK [HIGHESTMODSEQ 9512] Highest . OK [READ-ONLY] Select completed. . SEARCH UNSEEN * SEARCH 27126 27127 28484 29835 29838 . OK Search completed (0.000 secs). . STORE 27126 FLAGS \SEEN . OK Store completed. . SEARCH UNSEEN * SEARCH 27126 27127 28484 29835 29838 . OK Search completed (0.000 secs). . LOGOUT * BYE Logging out . OK Logout completed. Note how the first 'SEARCH UNSEEN' command shows that '27126' is unseen, the subsequent 'STORE' command succeeds - but then 'SEARCH UNSEEN' still shows 27126 as unseen! I have all four logging levels being piped to /var/log/maillog (I verified this by running dovecot --log-error) but the file does not show any problems. I checked the file permissions of the Maildir directories, and it all looks dandy to me. Does anybody have some suggestions how to debug this further, or what the reason for this may be? -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing # 1.2.17: /usr/local/etc/dovecot.conf # OS: FreeBSD 9.0-RELEASE i386 protocols: imap imaps managesieve listen(default): * listen(imap): * listen(managesieve): *:2000 *:4190 disable_plaintext_auth: no login_dir: /var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login verbose_proctitle: yes first_valid_uid: 1000 first_valid_gid: 1000 mail_privileged_group: mail mail_location: maildir:~/Maildir mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve mail_process_size: 512 mail_plugins(default): acl imap_acl fts fts_squat mail_plugins(imap): acl imap_acl fts fts_squat mail_plugins(managesieve): mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve imap_client_workarounds(default): delay-newmail netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(imap): delay-newmail netscape-eoh tb-extra-mailbox-sep imap_client_workarounds(managesieve): namespace: type: private separator: / inbox: yes list: yes subscriptions: yes namespace: type: public separator: / prefix: Lists/ location: maildir:/home/vmail/lists/Maildir:CONTROL=~/Maildir/lists:INDEX=~/Maildir/lists list: yes namespace: type: public separator: / prefix: Lists/Archive/ location: maildir:/home/vmail/lists/archive/Maildir list: yes lda: postmaster_address: postmas...@imap2.froglogic.com mail_plugins: sieve acl sendmail_path: /usr/sbin/sendmail auth default: mechanisms: plain login username_format: %Lu passdb: driver: pam args: session=yes dovecot passdb: driver: ldap args: /usr/local/etc/dovecot-ldap.conf userdb: driver: passwd-file args: username_format=%n /usr/local/etc/dovecot-pseudo-users.passwd userdb: driver: ldap args: /usr/local/etc/dovecot-ldap.conf plugin: acl: vfile sieve_before: /usr/local/etc/keep-broadcast-mail.sieve fts: squat fts_squat: partial=4 full=4
Re: [Dovecot] Marking all mail in one folder of public mailbox as read
Am 10/18/2012 5:31 AM, schrieb Timo Sirainen:
Use:
prefix=Lists/anotherlist/
location = maildir:/home/vmail/lists/sharedseen/Maildir
Then deliver the mails to /home/vmail/lists/sharedseen/Maildir root directly.
Of course this means that you need to create a namespace for each such list.
Alternative would be to use prefix=Lists/sharedseen/ and create lists under it.
Thanks, the second version is basically what I did! I added a new namespace
namespace public {
separator = /
prefix = Lists/Archive/
location = maildir:/home/vmail/lists/archive/Maildir
subscriptions = no
}
...and then had my Sieve script fileinto that. Works fine! Thanks for
your help!
--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing
[Dovecot] Marking all mail in one folder of public mailbox as read
Hi,
I'm running Dovecot 1.2.17 on FreeBSD 9 to serve an archive of a few
internal mailinglists. The archive is implemented using a public namespace:
namespace private {
separator = /
prefix =
inbox = yes
}
namespace public {
separator = /
prefix = Lists/
location =
maildir:/home/vmail/lists/Maildir:CONTROL=~/Maildir/lists:INDEX=~/Maildir/lists
subscriptions = no
}
As you can see, the CONTROL/INDEX files are stored per-user to allow
private \Seen flags. The different mailinglists are all sent to the
'lists' user which has a Sieve script to file them into different
folders, so I have directories on my harddisk like
/home/vmail/lists/Maildir/.somelist
/home/vmail/lists/Maildir/.anotherlist
Now, I'd like to mark the mail in *one* of those folders as \Seen by
default. If the INDEX files weren't per-user, it would simply be a
matter of using 'addflag "\Seen";' in the Sieve script of the lists
user. Alas, this has no effect.
Hence my question - how can I have the mail of just one mailinglist get
marked as "read" for all users?
So far, the only option I see is to add a second public namespace, with
a different prefix - and this namespace doesn't use private
CONTROL/INDEX files. However, I'd like to keep using the "Lists" prefix
if possible to avoid too many changes to the clients.
--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Search for substring in header?
Am 10/16/2012 12:20 AM, schrieb Dave Abrahams: on Mon Oct 15 2012, Michael M Slusarz wrote: Quoting Dave Abrahams : on Mon Oct 15 2012, Dave Abrahams wrote: on Sun Oct 14 2012, Michael M Slusarz wrote: Using 2.1.6 and 2.1.9 built --with-clucene --with-libstemmer, I get the same empty result with either of these two commands: UID SEARCH TO isocpp.org UID SEARCH TO "isocpp.org" Am I formatting the command wrongly? Incidentally, if I turn of fts_lucene and turn on fts_squat, I get the same result. Lucene for sure does not support subtext searching. Squat used to... but IIRC things may have changed for v2.1. Try the wiki. Sorry, but what does "try the wiki" mean? Which indexer are you using, that successfully finds the substring match? I don't know what Michael had in mind, but I also seemed to recall that the 'Squat' plugin used to be the only FTS plugin which suppotred substring matches. http://wiki2.dovecot.org/Plugins/FTS/Squat explains: "The main difference between Squat indexes and the others is that Squat provides support for substring searches, while pretty much all other FTS indexes support only matching from the beginning of words. By strictly reading the IMAP RFC it requires substring matching, so to optimize regular TEXT and BODY searches you must use Squat with Dovecot v2.0. [..] However, almost all other commonly used IMAP servers no longer care about this requirement, so Dovecot v2.1 also no longer makes this distinction." I'm not sure how to read this, but I can imagine (and maybe that's what Michael was hinting at) that the Squat plugin for Dovecot >= 2.1 no longer supports substring matches as required by the IMAP RFC whereas previous versions do. P.S.: I wish this list would have a Reply-To configured. :-) -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Shared Squat index for public mailboxes
Am 11.10.2012 um 22:10 schrieb Timo Sirainen:
> On 10.10.2012, at 11.06, Frerich Raabe wrote:
>> I already use this; as I mentioned, the index files of the public readonly
>> mailbox is stored per-user so that each user has his own set of \Seen flags.
>> Here's my public namespace:
>>
>> namespace public {
>> separator = /
>> prefix = Lists/
>> location =
>> maildir:/home/vmail/lists/Maildir:CONTROL=~/Maildir/lists:INDEX=~/Maildir/lists
>> subscriptions = no
>> }
>>
>> Alas, this means that *all* index files (including the Squat index) is
>> stored per-user whereas I'd just to have just *some* of them per-user. :-)
>
> You'll need v2.2 and its INDEXPVT setting.
Hm, you mean the feature introduced by
http://hg.dovecot.org/dovecot-2.2/rev/dbd42f7198eb ? Is there some discussion
of the feature somewhere?
The commit log is a bit unclear to me, it says 'Per-user flags can now be
stored in private index files.' however
http://wiki2.dovecot.org/SharedMailboxes/Public says 'By making each user have
their own private index files, you can make the \Seen flag private for the
users.' (using the INDEX setting).
Makes me wonder - the Wiki talks about 'private index files' when talking about
'INDEX' and the commit says 'private index files' talking about INDEXPVT - what
is the difference? :-)
--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] some questions on AOX or rather a mail system setup
Am 11.10.2012 14:56, schrieb Robert Schetterer: Am 11.10.2012 04:10, schrieb Christoph Anton Mitterer: 3) Is AOX suitable for the local server? [..] Christoph, sorry, what exact is AOX, and what is its relation to the dovecot list I suppose he meant Archiveopteryx (another IMAP server). -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Shared Squat index for public mailboxes
Am 10.10.2012 10:24, schrieb Robert Schetterer:
Am 10.10.2012 10:06, schrieb Frerich Raabe:
I already use this; as I mentioned, the index files of the public
readonly mailbox is stored per-user so that each user has his own set of
\Seen flags. Here's my public namespace:
namespace public {
separator = /
prefix = Lists/
location =
maildir:/home/vmail/lists/Maildir:CONTROL=~/Maildir/lists:INDEX=~/Maildir/lists
subscriptions = no
}
[..]
perhaps meanwhile this helps
-snip
http://wiki2.dovecot.org/SharedMailboxes/Public
[..]
namespace {
type = public
separator = /
prefix = Public/
location = maildir:/var/mail/public:INDEX=~/Maildir/public
subscriptions = no
}
Note how this is basically exactly the same as what I posted, except
that it uses the Dovecot 2 configuration file format ('type = public')
and that it calls the prefix/location "public" instead of "lists".
If you want to change what flags are shared when dovecot-shared file
exists, currently you'll have to modify the source code:
src/lib-storage/index/maildir/maildir-storage.c maildir_open() has
mbox->ibox.box.private_flags_mask = MAIL_SEEN; Change the MAIL_SEEN to
any flag combination you want. See src/lib-mail/mail-types.h for list of
valid flags.
I don't think this is applicable to my case, and a check of the source
code seems to confirm that: I'm not trying to change the set of flags
stored for a given mail but rather the index file of the Squat plugin.
--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing
Re: [Dovecot] Shared Squat index for public mailboxes
Am 10.10.2012 09:49, schrieb Robert Schetterer:
Am 10.10.2012 09:29, schrieb Frerich Raabe:
I'm running Dovecot 1.2.17 for serving mail via IMAP as well as for
providing access to a mailing list archive. The archive is implemented
as a public read-only mailbox with per-user index files (i.e. the \Seen
flags are per-user).
i guess better upgrade to 2.1.x
first
Given that Dovecot 1.2.17 works fine for me, I actually didn't see the
need to upgrade yet.
I recently enbled the Squat plugin to accelerate searches in the message
bodies and noticed that every user (I'm using a virtual user setup) gets
his own dovecot.index.search and dovecot.index.search.uids copies.
Is it possible to share those files among all users of the system? The
squat plugin appears to store the search indices among the other index
files (as explained on http://wiki.dovecot.org/Plugins/FTS/Squat) no
matter what; I considered storing a central copy of the index files
somewhere and then creating symlinks for all users. It should be ok as
far as file-permissions go since all mail is owned by a single vmail
system user, but I wonder whether the indices are really the same (I
noticed their md5 checksums differ) and whether there may be file
locking issues in case two users search message bodies simultaneously.
Can anybody shed some light?
after upgrade
http://wiki2.dovecot.org/Plugins/FTS/Lucene
may be better choice
Why?
this info might help
http://wiki2.dovecot.org/MailLocation
---snip
Index files
Index files are by default stored under the same directory as mails.
With maildir they are stored in the actual maildirs, with mbox they are
stored under .imap/ directory. You may want to change the index file
location if you're using NFS or if you're setting up shared mailboxes.
You can change the index file location by adding :INDEX= to
mail_location. For example:
mail_location = maildir:~/Maildir:INDEX=/var/indexes/%u
--snip
I already use this; as I mentioned, the index files of the public
readonly mailbox is stored per-user so that each user has his own set of
\Seen flags. Here's my public namespace:
namespace public {
separator = /
prefix = Lists/
location =
maildir:/home/vmail/lists/Maildir:CONTROL=~/Maildir/lists:INDEX=~/Maildir/lists
subscriptions = no
}
Alas, this means that *all* index files (including the Squat index) is
stored per-user whereas I'd just to have just *some* of them per-user. :-)
after upgrade come back, ask again, or meanwhile Timo gives better advice
Does this imply that questions regarding Dovecot 1.2.17 are considered
offtopic on this list? If so, I apologize - I'll look for another forum
then.
--
Frerich Raabe - ra...@froglogic.com
www.froglogic.com - Multi-Platform GUI Testing
[Dovecot] Shared Squat index for public mailboxes
Hi, I'm running Dovecot 1.2.17 for serving mail via IMAP as well as for providing access to a mailing list archive. The archive is implemented as a public read-only mailbox with per-user index files (i.e. the \Seen flags are per-user). I recently enbled the Squat plugin to accelerate searches in the message bodies and noticed that every user (I'm using a virtual user setup) gets his own dovecot.index.search and dovecot.index.search.uids copies. Is it possible to share those files among all users of the system? The squat plugin appears to store the search indices among the other index files (as explained on http://wiki.dovecot.org/Plugins/FTS/Squat) no matter what; I considered storing a central copy of the index files somewhere and then creating symlinks for all users. It should be ok as far as file-permissions go since all mail is owned by a single vmail system user, but I wonder whether the indices are really the same (I noticed their md5 checksums differ) and whether there may be file locking issues in case two users search message bodies simultaneously. Can anybody shed some light? -- Frerich Raabe - ra...@froglogic.com www.froglogic.com - Multi-Platform GUI Testing
