On 05/07/2015 02:32 PM, Reuben Farrelly wrote:
> On 7/05/2015 7:49 AM, Timo Sirainen wrote:
>> On 06 May 2015, at 13:52, Reuben Farrelly wrote:
>>>
>>> On 4/05/2015 11:06 PM, Teemu Huovila wrote:
> Also is there a way to restrict replication users aside from a crude hack
> around system f
Hello.
In order to speed up backups of very very old messages I would like to set
two different limits for mdbox_rotate_size. Like, 50M for primary storage
and 100M or larger for alternate storage.
There is no mention in docs or such a possibility, so I assume it is not
possible. Is that correct?
On 8/05/2015 6:10 PM, Teemu Huovila wrote:
On 05/07/2015 02:32 PM, Reuben Farrelly wrote:
On 7/05/2015 7:49 AM, Timo Sirainen wrote:
On 06 May 2015, at 13:52, Reuben Farrelly
wrote:
On 4/05/2015 11:06 PM, Teemu Huovila wrote:
Also is there a way to restrict replication users aside
from a cr
Do we have a way to keep the user \Seen flags in public folders
when an email is moved in another folder?
Sample test to reproduce:
Step a - UserA and UserB have both read the email in PublicFolderA.
Step b - UserA moves the email to PublicFolderB. UserA still sees the
email as read (with the \S
On 08 May 2015, at 18:24, Panayiotis Fafakos wrote:
>
> Do we have a way to keep the user \Seen flags in public folders
> when an email is moved in another folder?
>
> Sample test to reproduce:
> Step a - UserA and UserB have both read the email in PublicFolderA.
> Step b - UserA moves the emai
Dear Timo,
thank you very much for your answer and for the wonderful DOVECOT project.
Can you please tell us where is the code that moves the index record for
the specified email,
so that we can perhaps provide a manually updated list of users, that we
want dovecot to update also.
This would
Hi,
i keep getting error for using doveadm acl get commands.
Below is the output for grep 'socket_path' :-
grep 'socket_path' /etc/dovecot/dovecot.conf
auth_socket_path = /var/run/dovecot/auth-master
auth_socket_path = /var/run/dovecot/auth-master
[root@mail root]# doveadm acl get -u b.
I've noticed that when using Lucene full text search, most queries use
the indexes and/or header cache and are fast:
. SEARCH BODY test
. OK Search completed (0.001 secs).
. SEARCH SUBJECT test
. OK Search completed (0.053 secs).
. SEARCH BODY test SUBJECT test
. OK Search completed (0.002 secs)
As a followup to my own message:
On 5/8/15 1:34 PM, Robert L Mathews wrote:
> I've noticed that when using Lucene full text search, most queries use
> the indexes and/or header cache and are fast [...] But an OR query that
> mixes headers and body does not use the available
> FTS indexes for the B
