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.
> 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. 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.
> 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.)
Cheers.
--- Amir
