https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7019
Bug ID: 7019
Summary: Proposed revision to --max-size handling
Product: Spamassassin
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P2
Component: spamc/spamd
Assignee: [email protected]
Reporter: [email protected]
This suggested revision to the method of handling message size limits is still
driven by spamc. Its objectives are:
* allow installations using the same configuration as 3.4.x to show the same
expected behaviour.
* to provide a centralised method method of registering a non-standard maximum
message size and making it available to all interested parties, i.e spamc,
spamd, sa-learn and spamassassin
* to minimise and impact on spamc/spamd throughput
The revision is presented here by describing how it works:
When spamc is asked to send a message to spamd for processing its first action
is to send a message to spamd and getting a reply. This exchange uses the same
session that will transfer the message to spamd for processing.
The possibilities are:
- If spamc sends zero size (no --max-size option), spamd returns the max-size
value from local.cf if one was defined by a max-size parameter, and 512k if
undefined, This preserves the current default behaviour.
- If spamc sends a nonzero size (from a --max-size CL option), spamd returns
the smaller of that or the 256MB hard limit.
After this exchange the size limit is compared with the message, which is sent
to spamd provided that its size does not exceed the returned value and
processing proceeds as at present.
This approach does what I'd like and can also support KAM's variable limits
scheme without requiring changes on his part by allowing his client side to
have complete control of the processed message size via the spamc --max-size
option. His scheme looks like a good one for handling traffic peaks on a high
volume, heavily loaded mail system while not interfering with spam detection
unless it is absolutely necessary.
sa-learn, spamassassin and any other message handling programs that get added
to the SA package should all honour the configured max-size value set in
local.cf along with its 512KB default value because this eliminates surprises
that can arise when hand running tests on anomalous messages. For the same
reason all SA programs should honour the 256MB hard limit and should probably
implement a --max-size option as well.
--
You are receiving this mail because:
You are the assignee for the bug.
