Bug 7019 - Proposed revision to --max-size handling
Summary: Proposed revision to --max-size handling
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
Depends on:
Reported: 2014-02-27 00:46 UTC by Martin Gregorie
Modified: 2014-02-27 00:46 UTC (History)
0 users

Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Gregorie 2014-02-27 00:46:30 UTC
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.