Re: config best practice
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, Jiri Bourek wrote: >> For example, let's say you have single config file and only single >> line differs from default configuration - say "auth_verbose". When >> you upgrade, the packaging system tells you "the configuration was >> changed" and you need to either manually figure out all changes and >> apply them to your configuration or lose your own configuration >> changes (or attempt a 3-way merge) > > I prefer putting all of mine in one file in conf.d named > 99-myconfig.conf. > > This causes this file to be loaded last, so it overwrites any settings > defined in the other config files. > > > Charles
Re: Sis attachment deduplication
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 have the same attachment called proposalfromvendor.pdf and proposaltoclient.pdf in two different emails, will the original names be kept ? Or will it replace the filename with some kind of numeric hash ? There are no changes. It is completely transparent. It stores the attachments using an internal hash.
Re: IMAP Chunking Thunderbird
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 "mail.imap.fetch_by_chunks" via about:config this > is not the best choice for me because every client has to be edited. Is > there a way to set a central value on the dovecot server (i.e disable > chunking since this is not a client behaviour only)? > > Thanks in advance! > > > MrLINK > > > > -- > View this message in context: > http://dovecot.2317879.n4.nabble.com/IMAP-Chunking-Thunderbird-tp48549.html > Sent from the Dovecot mailing list archive at Nabble.com. > i got no problem report with thunderbird on 2.0.x 2.0.9 is not recent , latest is 2.0.21 better would be 2.1.17 best should be 2.2.13 i found some rpm repo http://www.city-fan.org/ftp/contrib/yum-repo/rhel6/x86_64/ Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: Sis attachment deduplication
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 in two different emails, will the original names be kept > ? Or will it replace the filename with some kind of numeric hash ? the message body must not be changed never, not in any single case for no reason why? because it breaks all sort of sigend mails dunno how this is implemented, in case of dbmail each message is splitted in it's mimeparts, they are all stored with a sha1sum and referenced to the messages, fetch a message re-constrcuts the whole mail from it's mimeparts and everytime a new mimepart arrives it's verified with the existing checksums to decide if a new record is needed or only a reference - after all references are gone the record for a mimepart is deleted signature.asc Description: OpenPGP digital signature
Sis attachment deduplication
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 original names be kept ? Or will it replace the filename with some kind of numeric hash ? Many thanks. Laeeth Sent from my iPad
IMAP Chunking Thunderbird
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 is not the best choice for me because every client has to be edited. Is there a way to set a central value on the dovecot server (i.e disable chunking since this is not a client behaviour only)? Thanks in advance! MrLINK -- View this message in context: http://dovecot.2317879.n4.nabble.com/IMAP-Chunking-Thunderbird-tp48549.html Sent from the Dovecot mailing list archive at Nabble.com.
Procmail wiki text -- don't muck with SENDMAIL
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 irrelevant, but actually wrong. The note down in the update section about Ubuntu explains the problem well enough, but it applies to all the sections on the page. My proposed edit was to simply remove SENDMAIL and SENDMAILFLAGS from all the recipes on the page, and then remove the Ubuntu section altogether, because it would no longer add anything useful to the page. If somebody in the Dovecot community with edit access to the wiki wants to implement this change, I would be grateful on behalf of the people who try to use Procmail with Dovecot. -- If this were my real .signature, it would suck less. Well, maybe not.
Suggestion: Split login_trusted_networks
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 is trusting two different entities. The first case you put trust in the host. In the second case, you actually put trust in the user which uses the webmail (unless of course the webmail it self implements auth-penalties). So you can't have one set of hosts which you trust for XCLIENT and another set of hosts you trust for not being the origin of brute force attacks. /Peter
