Hello everyone.
Thank you very much for your comments Michael.
Very enlightning i must confess.
In fact our servers do not deal with large amounts of emails (about 50
sites per server with about 500 users), but i totally see your point
regarding all the needed processing. I should have tought about that in
the first place.
Regarding the milter, i had both spamassassin and clamav running through
milters on the past, had even set up the gray list milter, but the
spamassassin one became irresponsive every now and then causing high
load, and at the time, due to the work flux i was having, i gave up on
trying to fix that. Guess i will try again :)
Again thanks for yout time and suggestions,
Kind regards,
Gustavo
Michael Stauber escreveu:
> Hi Gustavo,
>
>
>> Regarding my previous topic (local delivery to over quota users
>> and/or almost full quotas, that will become locked and unresponsive
>> untill you give them more free space)
>>
>> This procmail recipe kinda works.
>> Avoids the mailbox to fill up and become unresponsive. Or so i think..
>>
>
> This is a pretty creative approach which sounds familliar. :o)
>
> Integrating SpamAssassin through Procmail (even if you use SPAMd / SPAMc!) is
> the real culprit here. Calling SpamAssassin through /etc/procmailrc is
> actually what causes the issue with over quota emails clogging up the system
> in first place. Additionally it's not really all that easy on the system
> performance to begin with. Adding more CPU and I/O eating processes
> to /etc/procmailrc (like the quota check!) is a band aid which may easen the
> fall out of this method of implementation at the cost of furtherly reduced
> performance.
>
> Secondly: With this method of integration the actual SPAM filtering happens
> well behind the MTA level. So the "child" has already dropped into the well
> and the SPAM is already half way in between the MTA and the mailbox. Sure,
> you can still tag or delete it with Procmail rules - even user specific
> procmailrc rules. But you can no longer reject it at the MTA level - not even
> the most hideous SPAM with scores well over 20.
>
> My old and now retired AV-SPAM v4 was in the same boat as you were and I also
> played with integrating quota checks into /etc/procmailrc as a band aid. It
> works if you have a low level of email traffic, but it doesn't scale well. A
> slight increase in email traffic cause an unproportional rise in CPU and I/O
> usage.
>
> My suggestion would be:
>
> Integrate SpamAssassin through a Milter. That way you can check all emails
> right as the MTA receives them. Let the milter reject SPAM above a certain
> server wide score and let it tag/markup the rest of the SPAM as usual.
>
> Then use and unmodified /etc/procmailrc to do the delivery to the user's
> mailbox. That way the entire over quota stuff is handled as intended.
>
> Finally, use user specific ~/.procmailrc files to delete or quarantine SPAM
> that's above a user specified score.
>
> The difference between integrating SpamAssassin through /etc/procmailrc and a
> Milter is like the difference between night and day.
>
>