Thanks all who replied with good advice. I think I'll go for the (short)
local.conf solution. I don't like messing around with all separate files
in conf.d. As long as they don't conflict with my settings, it will be OK.
Egbert Jan
Charles Marcus schreef op 19-6-2014 15:55:
> On 6/19/2014 4:54 AM
On 06/19/14 10:52 AM, Laeeth Isharc wrote:
1. Is this now reasonably stable for large mailboxes (c 2mm messages)?
We have not had any problems. YMMV and should be tested before putting
into production.
2. Will this leave the filename in the message body unchanged? So for example
if I hav
Am 19.06.2014 14:28, schrieb MrLINK:
> Hi,
>
> using dovecot-2.0.9-7.el6.x86_64 on CentOS release 6.5 (Final) I have an
> issue with thunderbird imap chunking. Some attachments are corrupted,
> because Thunderbird is just storing the first chunk. Since there are some
> workarounds by editing the "
Am 19.06.2014 16:52, schrieb Laeeth Isharc:
> 1. Is this now reasonably stable for large mailboxes (c 2mm messages)?
dunno
> 2. Will this leave the filename in the message body unchanged? So for
> example if I have the same attachment called proposalfromvendor.pdf and
> proposaltoclient.pdf
Hi.
Two questions:
1. Is this now reasonably stable for large mailboxes (c 2mm messages)?
2. Will this leave the filename in the message body unchanged? So for example
if I have the same attachment called proposalfromvendor.pdf and
proposaltoclient.pdf in two different emails, will the origina
Hi,
using dovecot-2.0.9-7.el6.x86_64 on CentOS release 6.5 (Final) I have an
issue with thunderbird imap chunking. Some attachments are corrupted,
because Thunderbird is just storing the first chunk. Since there are some
workarounds by editing the "mail.imap.fetch_by_chunks" via about:config this
I tried to edit http://wiki2.dovecot.org/procmail but got stuck on the
TextCha. Approaching this list instead seems to be a time-tested secondary
approach, and I wasn't completely comfortable making these changes without
discussion anyway. So here goes.
The SENDMAIL= assignment is not only irrel
Hi,
It seems the use of login_trusted_networks is overloaded.
Example:
* It's used for indicating which hosts you trust to provide XCLIENT
remote IP's.
* It's used for indicating from which hosts you trust logins enough to
disable auth penalty. (like in a webmail)
However... trustwise, this
