On Sun, 5 Sep 2010, COGZ wrote:
The problem with editing the users .mailfilter file is that they could
overwrite it with their control panel. Seems like a shell script wrapper
would be best. Any suggestions on how to configure?
Is there any way you can hook control panel to throw a warning if they use
spamassassin and recommend spamc instead?
User education is the _best_ option...
John Hardin wrote:
On Sun, 5 Sep 2010, COGZ wrote:
I know there are a number of ways to limit the size of a messages that
are scanned with spamassasin, but I am having problems with
configurations. Spamc seems to have this capability already build in by
default. Is there a config file that I can change to call spamc when the
call is made from the .mailfilter that is in the users mail folder and
contains code to call spamassassin. (xfilter "/usr/bin/spamassassin -p)
If the user is explicitly calling spamassassin that way there's little you
can do on the SA side to override it. Can you educate your users to call
spamc instead of spamassassin?
If you have administrative access you could change the users' .mailfilter
files...
Perhaps replace /usr/bin/spamassassin with a shell script wrapper that
calls spamc? That would be fairly fragile and would impact people outside
the scope of .mailfilter files.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhar...@impsec.org FALaholic #11174 pgpk -a jhar...@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Where We Want You To Go Today 07/05/07: Microsoft patents in-OS
adware architecture incorporating spyware, profiling, competitor
suppression and delivery confirmation (U.S. Patent #20070157227)
-----------------------------------------------------------------------
12 days until the 223rd anniversary of the signing of the U.S. Constitution
