Re: [Dovecot] Sieve users script problem.
On 11/11/2012 2:39 AM, Ben Morrow wrote: require ["include"]; include "script1"; include "script2"; and activate that script. >Nov 10 18:35:54 lda(user@domain.local): Debug: sieve: include: >sieve_global_dir is not set; it is currently not possible to include >`:global' scripts. It's not clear to me what's happening here: does that script use the 'include :global' command? If you want that to work you will need to create a system-wide scripts directory and set the sieve_global_dir parameter to point to it. If OTOH you wanted to include a script from the user's sieve/ directory, you need to leave off the :global tag. Ben Thanks, Now I kind of understand it but from the documentation it feels like there is a default and directory which works always.(Or this what I understood) Since its not like that it makes my options limited but stil this can do what I need. I need it to filter mails into sub-directories for my user only so it's fine. Thanks Again, Eliezer -- Eliezer Croitoru https://www1.ngtech.co.il IT consulting for Nonprofit organizations eliezer ngtech.co.il
Re: [Dovecot] v2.1 memory usage
On 2012-11-11 17:20, Reindl Harald wrote: > Am 12.11.2012 02:11, schrieb Daniel L. Miller: > >> On 11/6/2012 12:30 PM, Timo Sirainen wrote: >> >>> On 6.11.2012, at 17.26, Ed W wrote: >>> On 05/11/2012 23:22, Timo Sirainen wrote: > On Mon, 2012-11-05 at 23:40 +0200, Timo Sirainen wrote: This also provides a nice abstraction to OpenSSL, making it again possible to implement other backends like GnuTLS or NSS. (Except login process code doesn't use lib-ssl-iostream yet.) Does libtomcrypt implement enough? >>> It doesn't do SSL, which is all Dovecot cares about. >> Can the GnuTLS OpenSSL compatibility layer be used safely? > > where is the problem with openssl? I don't know what the problem is - I just know that I've heard from a number of developers (including the Postfix & Dovecot developers) that they don't like OpenSSL - but while GnuTLS looks interesting they aren't interested in working on the interface - though they're willing to accept patches. (My full apologies right now if Timo or Wietse are offended by my speaking out of turn). I'm no security expert, but I do know that OpenSSL has had issues with version compatiblity. I had a very troubled time during an OpenSSL/Postfix upgrade that left me non-functional until I found the exact version pairings required. The tiny bit of Googling I've done tells me GnuTLS seems to be a more standards-compliant implementation, and MAY be "safer" than OpenSSL. However, as OpenSSL is the de-facto standard used by most Linux programs, acceptance of GnuTLS is quite limited. I've been intrigued by what I've read about it, and took a quick look at enabling support in Dovecot for GnuTLS directly - but while it didn't seem overly heavy at first glance the fact that Timo doesn't want to do it tells me I'm underestimating the complexity. -- Daniel
Re: [Dovecot] Solr 4.0 - lucene - FTS
On 2012-11-08 03:45, Charles Marcus wrote: > On 2012-11-07 10:14 AM, Timo Sirainen wrote: > >> No, fts-lucene and fts-solr are separate backends. But I do have some small plans to add a few more features to fts-solr. > > Thanks again Timo, but one last follow-up... > > According to the wiki, Solr is the preferred method, but that seems > weird to me - it requires a full blown Solr server that dovecot > communicates with using HTTP/XML queries? Maybe not that big a deal, but > just sounds like overkill to me, unless you are maybe already using Solr > for website searches (which I'm not and have no need for). I would much > prefer something simpler that doesn't require any external dependencies > like that, so, next choice is Lucene... > > Looks much simpler, only requires Lucene's C++ library... > > But it builds only a single Lucene index for all mailboxes - not sure if > this is good or bad? Seems like it would be better/more efficient (and > less chance of index corruption, but most importantly, less overhead in > the event that one gets hosed and dovecot needs to rebuild it) to build > individual indexes for each mailbox, then, maybe, to provide support for > searching ALL mailboxes, have a master index that basically just > maintains a list of all of the individual indexes to be used for the > search (so it doesn't have to scan all available mailboxes, but which it > can do in the event that *it* ever got hosed). > > Obviously I don't know much about all this, so may be totally off base... > > Thanks again, and for listening to my ramblings, My, probably wrong, impression is this: The concept of running a "full blown Solr server" seems intimidating - until you actually do it. It's just another Java process. If you're already using Java for something else then I don't think there's much concern - my (again, probably wrong) understanding is once you've got one Java process running, other than process-specific variables/caching the overall overhead of the Java VM is shared - so in for a penny in for a pound. Lucene development is actively done in Java, with Solr being the primary reference implementation. The C libraries (I know of two) are then derived from the Java library - so the C implementations always lag behind the Java one, and it looks like there's much more active work going into the Java library. There's no question the Lucene implementation in Dovecot is the simplest for an administrator to work with - but the Solr version sure looks a lot more powerful. The tradeoff is sometimes needing to fiddle with configuration settings (not like we ever need to that for anything else, right?), especially with new versions of either Dovecot or Solr. Having a single index store - I suppose theoretically increases a point of failure, but given that the FTS indexes are a partial duplicate of and generated from the mail storage I'm not losing sleep over it. I put my Solr installation on the same raid array as my mail store - I'm not seeing any issues with it but I don't claim to be a senior admin. I'm currently running Solr 4.0. A few tweaks are needed to get it running, but once it's up it goes quite smoothly. -- Daniel
Re: [Dovecot] mbox vs. maildir storage block waste
On Thu, 2012-11-08 at 17:54 -0800, Robin wrote: > The performance is surprisingly bad ... doing almost everything. > Searches through IMAP, bulk importation of mail folders, large > numbers of simultaneous mail deliveries, you name it. Have you made systematic tests? I.e. compared times for all of these with those from the different dovecot backends. > There wasn't a task that the dbmail setup performed faster than > Dovecot, in either low or high load situations. Which backend did you use? > When pressed on this lack of performance, I was instructed to "add > more RAM" to the DB machine, and that for ideal performance I should > have more RAM than my mailbox sizes. *sigh* This sounds great for a > very small installation, but this clearly is not something that > scales. Yeah... that’s truly disappointing... Do you have detailed numbers? I guess you’ve "only" tried dbmail? > The dbmail folk are earnest and hard-working, and I don't mean to cast > the slightest bit of negativity on their project. I think the > assumptions about what SQL servers can do well often doesn't square > with the reality of many applications that people try to fit them > into. hmm... > remove filesystem journaling, write barriers, etc on the mail db > mountpoint. All something I wouldn’t want to do on my production systems ;) Thanks for your detailed information :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: [Dovecot] v2.1 memory usage
Am 12.11.2012 02:11, schrieb Daniel L. Miller: > On 11/6/2012 12:30 PM, Timo Sirainen wrote: >> On 6.11.2012, at 17.26, Ed W wrote: >> >>> On 05/11/2012 23:22, Timo Sirainen wrote: On Mon, 2012-11-05 at 23:40 +0200, Timo Sirainen wrote: This also provides a nice abstraction to OpenSSL, making it again possible to implement other backends like GnuTLS or NSS. (Except login process code doesn't use lib-ssl-iostream yet.) >>> Does libtomcrypt implement enough? >> It doesn't do SSL, which is all Dovecot cares about. >> > > Can the GnuTLS OpenSSL compatibility layer be used safely? where is the problem with openssl? please leave us in peace with gnuTLS and see how it affects OpenVAS / Greenbone Sceurity Assistant on distributions like Fedora the whole year what about config compatibility like ssl_cipher_list = ALL:!LOW:!MEDIUM:!SSLv2:!MD5:!aNULL:!eNUL:!ADH:!AESGCM:!EXP:HIGH signature.asc Description: OpenPGP digital signature
Re: [Dovecot] v2.1 memory usage
On 11/6/2012 12:30 PM, Timo Sirainen wrote: On 6.11.2012, at 17.26, Ed W wrote: On 05/11/2012 23:22, Timo Sirainen wrote: On Mon, 2012-11-05 at 23:40 +0200, Timo Sirainen wrote: This also provides a nice abstraction to OpenSSL, making it again possible to implement other backends like GnuTLS or NSS. (Except login process code doesn't use lib-ssl-iostream yet.) Does libtomcrypt implement enough? It doesn't do SSL, which is all Dovecot cares about. Can the GnuTLS OpenSSL compatibility layer be used safely? -- Daniel
Re: [Dovecot] Sieve puts incoming message into inbox on any problem with submission_host
On 11/9/2012 2:24 PM, Christian Rohmann wrote: Hello dovecot-users, I have a question/suggestion regarding the submission_host feature of the lda (either via dovecot-lda binary or lmtp) in combination with sieve. The same applies to vacation messages being sent out. Especially with an (unconditional) redirect action, users don't expect to find messages in their inbox. Also problems with the submission_host could very much be temporary and a little delay in delivering a message is better then putting it somewhere the user doesn't expect a message to be. Yes, I agree. With the normal sendmail configuration this situation was much less likely to occur since messages would be queued locally first. Is there any way to change the behavior of dovecot or the sieve plugin to tempfail in case a message cannot be sent out? Not currently, I've been thinking about something like that for use with the extprograms plugin, which presents similar challenges. I know that with multiple sieve actions it gets more complicated as there could be corner cases were the first message can be sent via the submission server and another message produced by the same sieve script cannot. Exactly. And other kind of actions even make this more annoying. The Sieve interpreter tries to do things atomically as much as possible. With outgoing messages, that is rather difficult, so these actions are performed only after all other actions, e.g. local folder deliveries, succeed. So, in the current implementation simply issuing a temp fail would yield the even nastier result of duplicating deliveries; it is not possible to simply undo local message deliveries at that stage anymore. To solve this definitively I'll have to do some redesign of the action execution sequence. I'd love sieve to behave like this: a) if submission host is unreachable (hostname wrong, timeout, ...) -> tempfail The simplest solution right now would be to perform a pre-check on whether the message submission is likely to succeed or not. Regards, Stephan.
