You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Justin Kim <ju...@mezine.com> on 2007/10/19 22:09:25 UTC
Disabling URIDNSBL plugin
Hi All,
I need a help.
I don't know what is causing my postfix server to defer messages couple of
times daily.
When postfix server is deferring messages, our users does not get the email
delivery until the deferring action is done.
It usually takes 5 mins to 10 mins.
I was looking at the maillog. I couldn't find the cause.
Postfix + Spamassassin + Amavisd-new + Dovecot works great except this issue
of deferring messages.
By looking at the logs, I can only tell there is something that keeps one
spam checking process running for 5~10 mins.
I was thinking of disabling URIDNSBL from spamassassin.
Would this cause any problem?
I still want to have similar performance of discarding spams like now. I
haven't had any or not many of the false positive reports so far.
Any comments or constructive advice would be appreciated.
Please help!
Thanks,
Justin
Re: Disabling URIDNSBL plugin
Posted by Byung-Hee HWANG <bh...@izb.knu.ac.kr>.
Hi Justin,
On Fri, 2007-10-19 at 13:09 -0700, Justin Kim wrote:
> Hi All,
>
> I need a help.
> I don't know what is causing my postfix server to defer messages couple of
> times daily.
> When postfix server is deferring messages, our users does not get the email
> delivery until the deferring action is done.
> It usually takes 5 mins to 10 mins.
> I was looking at the maillog. I couldn't find the cause.
>
> Postfix + Spamassassin + Amavisd-new + Dovecot works great except this issue
> of deferring messages.
> By looking at the logs, I can only tell there is something that keeps one
> spam checking process running for 5~10 mins.
> I was thinking of disabling URIDNSBL from spamassassin.
> Would this cause any problem?
> I still want to have similar performance of discarding spams like now. I
> haven't had any or not many of the false positive reports so far.
>
> Any comments or constructive advice would be appreciated.
For the solution,
I think you would better talk with postfix-users@postfix.org ;;
Sincerely,
--
Byung-Hee HWANG <bh...@izb.knu.ac.kr> * আমি তোমাকে ভালোবাসি
InZealBomb, Kyungpook National University, KOREA
"I spoke for the good of the Family, not for myself. I can take care of
myself."
-- Tessio, "Chapter 28", page 399
Re: Disabling URIDNSBL plugin
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Micah Anderson wrote:
> * mouss <mo...@netoyen.net> [071020 09:38]:
>> Micah Anderson wrote:
>>> Do you think running a bayes expire via cronjob is necessary if you are
>>> running a INNOdb based bayes DB (with this patch[1])?
The patch could make it fast enough that you'll never had child timeouts
after 600 seconds causing an expiry to abort. I read the patch but
there's not enough context in it to say anything for sure. I haven't
reviewed the code it patches.
>>> Also, if you postpone the bayes expire to instead run it via cron aren't
>>> you just making the expiration stack up and instead are delaying this
>>> condition until later (when the cron job runs) and for longer (because
>>> the expiration hasn't been run in a while)?
The problem isn't the duration it takes so long as it actually
completes. An auto expiry must complete within the child timeout limit
(default of 600 seconds) less the time that child already took to scan
the message it was passed before it decided to also do an expiry.
Moving the expiry outside of spamd gives you all the time you need to do
it. spamd will still continue to scan messages while you do it, you
just might not have access to a particular bayes DB while the expiry is
running).
>> doing it once a day at 3 AM is not like doing it when delivering mail.
>
> Unless you deliver mail 24 hours a day for people all over the world.
> Then 3am in one place is noon in another.
Abu Dhabi in your case. Deliver a lot of mail there? :)
Again, you can still process mail while the expiry is running, and since
you're not getting one of your spamd children to do it, you're not tying
up your spamd resources. Further the expiry isn't in danger of being
aborted due to a child timeout.
If you're concerned about a once a day expiry taking to long do it twice
a day. OR if you're not having any issues with auto expiries, keep
using them.
Daryl
Re: Disabling URIDNSBL plugin
Posted by mouss <mo...@netoyen.net>.
Micah Anderson wrote:
> * mouss <mo...@netoyen.net> [071020 09:38]:
>
>> Micah Anderson wrote:
>>
>>> Do you think running a bayes expire via cronjob is necessary if you are
>>> running a INNOdb based bayes DB (with this patch[1])?
>>>
>>> Also, if you postpone the bayes expire to instead run it via cron aren't
>>> you just making the expiration stack up and instead are delaying this
>>> condition until later (when the cron job runs) and for longer (because
>>> the expiration hasn't been run in a while)?
>>>
>>>
>>>
>> doing it once a day at 3 AM is not like doing it when delivering mail.
>>
>
> Unless you deliver mail 24 hours a day for people all over the world.
> Then 3am in one place is noon in another.
>
>
>
>
Then run it at a different hour each day...
but as Daryl says, the point is to separate the "cleanup" and the
delivery processes.
Re: Disabling URIDNSBL plugin
Posted by Micah Anderson <mi...@riseup.net>.
* mouss <mo...@netoyen.net> [071020 09:38]:
> Micah Anderson wrote:
> > Do you think running a bayes expire via cronjob is necessary if you are
> > running a INNOdb based bayes DB (with this patch[1])?
> >
> > Also, if you postpone the bayes expire to instead run it via cron aren't
> > you just making the expiration stack up and instead are delaying this
> > condition until later (when the cron job runs) and for longer (because
> > the expiration hasn't been run in a while)?
> >
> >
>
> doing it once a day at 3 AM is not like doing it when delivering mail.
Unless you deliver mail 24 hours a day for people all over the world.
Then 3am in one place is noon in another.
Re: Disabling URIDNSBL plugin
Posted by mouss <mo...@netoyen.net>.
Micah Anderson wrote:
> * Daryl C. W. O'Shea <sp...@dostech.ca> [071019 14:59]:
>
>> Justin Kim wrote:
>>
>>> I don't know what is causing my postfix server to defer messages couple of
>>> times daily.
>>>
>>> By looking at the logs, I can only tell there is something that keeps one
>>> spam checking process running for 5~10 mins.
>>>
>> Likely bayes auto expiry. Disable bayes_auto_expiry and do the expiries
>> via a cron job instead.
>>
>
> Do you think running a bayes expire via cronjob is necessary if you are
> running a INNOdb based bayes DB (with this patch[1])?
>
> Also, if you postpone the bayes expire to instead run it via cron aren't
> you just making the expiration stack up and instead are delaying this
> condition until later (when the cron job runs) and for longer (because
> the expiration hasn't been run in a while)?
>
>
doing it once a day at 3 AM is not like doing it when delivering mail.
> Micah
>
> 1. http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5661
>
>
>
Re: Disabling URIDNSBL plugin
Posted by Micah Anderson <mi...@riseup.net>.
* Daryl C. W. O'Shea <sp...@dostech.ca> [071019 14:59]:
> Justin Kim wrote:
>> I don't know what is causing my postfix server to defer messages couple of
>> times daily.
>
>> By looking at the logs, I can only tell there is something that keeps one
>> spam checking process running for 5~10 mins.
>
> Likely bayes auto expiry. Disable bayes_auto_expiry and do the expiries
> via a cron job instead.
Do you think running a bayes expire via cronjob is necessary if you are
running a INNOdb based bayes DB (with this patch[1])?
Also, if you postpone the bayes expire to instead run it via cron aren't
you just making the expiration stack up and instead are delaying this
condition until later (when the cron job runs) and for longer (because
the expiration hasn't been run in a while)?
Micah
1. http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5661
Re: Disabling URIDNSBL plugin
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
Justin Kim wrote:
> I don't know what is causing my postfix server to defer messages couple of
> times daily.
> By looking at the logs, I can only tell there is something that keeps one
> spam checking process running for 5~10 mins.
Likely bayes auto expiry. Disable bayes_auto_expiry and do the expiries
via a cron job instead.
> I was thinking of disabling URIDNSBL from spamassassin.
> Would this cause any problem?
> I still want to have similar performance of discarding spams like now. I
> haven't had any or not many of the false positive reports so far.
Well, if you disable the URIDNSBL plugin you won't have "similar
performance of discarding spams like now". The URIDNSBL plugin hits on
a lot of spam, so disabling it will cause your spam TP rate to fall and
thus a corresponding decrease in the number of messages you can discard.
> Any comments or constructive advice would be appreciated.
Rather than discarding messages, I would suggest (and hope that you just
misspoke) that you instead reject them at SMTP time.
Daryl