Hello all, hello Julian,
we're having this same problem in a courier server we have. Sometimes
the filter is taking a lot of CPU and people is unable to send mails.
People using Outlook re-send the same email many times because it's
stored in the Outbox folder and retried. It's quite annoying for them
and for me (as administrator) to handle this situations.
Is there a way to limit the emails that get filtered? For example if
the mail size is bigget than X. I can't find a way to do this for this
kind of filters nor in the spamassassin config files.
I think it's a pity not to fix this problem, because this is a nice
and smooth way to integrate spamassassin into courier (you don't have
to use third parties software/scripts or a second SMTP server) but the
fact that the filter is not multithread and courier is not able to run
several instances of the filter is making it unsuable for a production
environment.
Does anybody have a solution for this issue?
Thanks!
On Sat, Jul 12, 2008 at 11:01 AM, Julian Mehnle <jul...@mehnle.net> wrote:
> Timothy S. Nelson wrote:
>> On Tue, 7 Nov 2006, Sam Varshavchik wrote:
>> > Whatever you're running for a mail filter, clamd or spamassassin, is
>> > crashing.
>> > [...]
>>
>> Ok, I've taken over this job from the guy who wrote the original
>> message. Anyway, the filter isn't crashing, but it is processing very
>> slowly. When the number of Unix domain sockets that are connected to it
>> gets to 128, the errors above appear. If there's some way to fix this,
>> I'd love to hear about it.
>
> What do you mean by "the number of Unix domain sockets that are connected
> to it"? Do you mean the number of connections to Courier::Filter for
> which Courier is waiting to be established? (Currently C::F doesn't
> accept more than one connection at a time because multi-threading isn't
> supported yet -- see below.)
>
> If that's what you mean, then I suspect that nothing is crashing at all in
> the first place, but Courier merely refuses to wait for a 129th
> connection to be accepted by C::F and rejects the message with a
> temporary SMTP status code ("432 Mail filters temporarily unavailable").
>
>> The filter in question is pureperlfilter, which is written by Julian
>> Mehnle, who has requested that support messages for that module also be
>> directed to this list.
>
> Right. Sometimes I am a bit slow with answering questions, though, for
> which I apologize.
>
>> Anyway, I have a question for Julian and others close to
>> Courier::Filter -- is there any chance that the multithreading support
>> will be entering alpha/beta testing sometime soon?
>
> Technically yes, because I had it implemented years ago already, but Perl
> 5.8's threading implementation had a nasty memory leak, so I disabled it
> again. I don't know whether current versions of Perl 5.8, or Perl 5.10,
> have that fixed.
>
> However I intend to eventually reimplement threading support with a worker
> thread pool design rather than the old one-thread-per-connection design
> (which was also a memory waste). It's just not something I have the time
> to do right now. Probably later this year.
>
>> If it helps, the SpamAssassin module is the one thats slowing
>> everything down. I tested this by removing it from the pureperlfilter
>> config.
>
> Good to know, and thanks for your thorough analysis.
>
>> I'm still using Courier::Filter version 0.17, but after reading the
>> Changelog, I'm guessing this won't make a lot of difference.
>
> Right, upgrading to C::F 0.200 won't help against your specific problem.
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> courier-users mailing list
> courier-users@lists.sourceforge.net
> Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
