On 2/20/2014 5:16 PM, Martin Gregorie wrote:
On Thu, 2014-02-20 at 16:39 -0500, Kevin A. McGrail wrote:
On 2/20/2014 4:35 PM, Amir 'CG' Caspi wrote:
If it's a size issue, how can I increase the size limit for sa-learn?
But, I don't think it's a size issue since these messages are under 512k
each.
--max-size= I believe. Default is 256K.
Sorry, no. According to my manpage (SA 3.3.2) there is no --max-size
option and (second try) sa-learn --max-size is rejected as an unknown
option.
Try 3.4.0
--max-size <b> Skip messages larger than b bytes;
defaults to 256 KiB, 0 implies no limit
I'll fix KiB to read KB.
On the same subject, is there any change that a max-size configuration
parameter could be supplied via local.cf?
Don't believe so.
1) IMO a single central setting is better than remembering to specify
and change it in several scripts. Currently it needs to be set to
the same value in every script or MTA configuration that can run
spamc and/or sa-learn and its quite easy to miss one.
My systems run with different limits in different places and in fact on
different servers with spamc connecting to spamd boxes on other
systems. Unifying wouldn't be something I would want to see.
2) There currently seems to be no way of overriding the default max
message size for the commands spamassassin, spamd or sa-learn.
I believe this is false.
Typically if you were using spamassassin, a size limit it would be
implemented by your .procmailrc implementation for example.
Spamd would be limited by spamc -s parameter.
sa-learn has the --max-size option added with 3.4.0
3) It improves system documentation to have all parameter settings in
one place.
SA is an API as well as a collection of programs implementing the API.
It's a Swiss army tool with a whole bunch of configurable settings.
And, as in my case, many of the tools can run on different servers by
different users, etc. One place for parameters is very hard.
But if you want to discuss further and can provide patches that don't
break existing functionality, I'm always looking to get more people
involved and submitting patches.
I accept that setting the message size in local.cf may slow spamc down
slightly if spamd doesn't already send a reply to spamc, which could
pass the setting back, before accepting the message but the overhead of
adding the reply message should be quite small.
More to the point, spamc would have to process all config files first
which would slow it down. The point of spamc is to be a VERY
lightweight connection to spamd.
regards,
KAM
