On 2/20/2014 5:38 PM, Amir 'CG' Caspi wrote:
On Thu, February 20, 2014 3:29 pm, Kevin A. McGrail wrote:
Unifying wouldn't be something I would want to see.
Well, no one is arguing to _force_ unification, but to provide an option
for it. That is, max-size could be set in local.cf and would become a
global parameter, but could still be overridden with CLI options.
I think based on your idea below, the CLI could not override it. For
example, if I have a max size on spamd, how could spamc override it?
Right now, spamd has no limit and spamc enforces a limit.
As with before, just because *I* don't want to see it just means that
you have to figure it out on your own and come up with a patch that
doesn't break existing functionality but adds what you want. And I'm
willing to discuss the concept and test patches because I see some
merit. But I know I have other issues I want to focus on right now with SA.
Typically if you were using spamassassin, a size limit it would be
implemented by your .procmailrc implementation for example.
Well, at least in 3.3.2, there is no apparent max-size parameter for
spamassassin (the direct SA executable, not spamc/spamd or sa-learn).
Older messages from the archives of this very mailing list seems to
suggest that spamassassin itself has no message size limit.
That is correct. There is no size limit in that scenario of using the
spamassassin executable directly. However, in the real-world, there is
almost 0 necessity to use that in a live environment because the startup
time is too high.
As noted, if you were using spamassassin, you would likely using
something like .procmailrc with a rule that limits the size ala:
:0fw
* < 1572864
spamc
certainly does, which as you say is overridden with the -s parameter.
sa-learn apparently has a hardcoded limit, although as I mentioned in my
previous email, I'm not seeing any error in the debug output that it's
skipping due to size.
Please try with 3.4.0 and if there is still no output in debug, let me
know and I'll add something. But from looking at the code, I believe
this is addressed:
info("archive-iterator: skipping large message: ".
"file size %d, limit %d bytes", -s _, $opt_max_size);
Questions that will be answered by "that is solved in 3.4.0" aren't
really going to get much support from me...
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.
Actually, if a limit is imposed centrally in spamd, I think this could be
accomplished without any changes to spamc except to remove spamc's default
size limit. spamc would remain lightweight, simply piping email to
spamd... if the message exceeds spamd's size limit, spamd would simply
regurgitate the X-Spam-Status: No header, which is exactly what spamc
currently does locally when the message size limit is exceeded -- the
difference is only that spamc would send the message to spamd and spamd
would barf, rather than spamc barfing locally. Only spamd would have to
read its central config. (A local size limit COULD still be imposed for
spamc via CLI, the difference is that no local size limit would exist by
default, it would have to be done via CLI.)
More to the point though, a local size limit SHOULD be imposed. Do you
really want Spamc sending giant messages to spamd just to have it say,
no, that's too large?
If you really want this, I'd say off the cuff you should implement a new
version of the spamc protocol and have the spamc/spamd negotiate whether
the connection was going to be accepted by sending the message size
ahead of time coupled with a local.cf option for the spamd max message size.
You can open a feature request for this at bugzilla and I'd be happy to
help testing any patches you might come up with.
However, in my case, I use spamc and multiple factors to determine what
the max size is to send to spamd. For example, if our load average is
very low, I will send very large messages to spamd. I enjoy the
flexibility of the setting.
regards,
KAM
