Date: Sat, 26 Jul 2003 18:09:13 -0700
From: "Daniel M. Zimmerman" <dmz@tffenterprises.com>
To: cgpsa-discuss@tffenterprises.com
Subject: CGPSA 1.1 Released
Message-ID: <44849574.1059242953@babylon2.caltech.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

CGPSA 1.1 has been released. It contains a bunch of improvements, and a 
decent amount of cleaned up code; it is recommended that all CGPSA users 
upgrade to this version. Please try to keep discussion about this release 
on the CGPSA discussion list (cgpsa-discuss@tffenterprises.com, 
subscription address cgpsa-discuss-on@tffenterprises.com).

For those of you running 1.1b4, there are no code changes between 1.1b4 and 
1.1 except for the version number.

The release is available from <http://www.tffenterprises.com/cgpsa/>.

Changes (since 1.0.8):

- Parallel requests mode is now turned on by default on non-Windows 
platforms.

- Modified the processing of message headers to preserve more  information 
about the Envelope-To addresses.

- Added the ability to specify a list of destination domains that should 
always have their mail scanned, with the "scan_domains" setting. This makes 
it possible to use CGP as a relay/gateway server (to filter and process 
email for other domains).

- Added date/time stamp to the standard error output generated by CGPSA. 
Output generated by other Perl code (such as SpamAssassin) is not date/time 
stamped.

- Changed CGPSA's output functions to wrap lines to a reasonable number of 
characters (around 150), to work around the CommuniGate log line length 
limit.

- Added signal handling: if the main CGPSA process receives a HUP, it 
reloads all of its own and SpamAssassin's preferences before processing the 
next CLI command it receives.

- Partially worked around the behavior whereby, when parallel_requests is 
off and use_user_prefs is on, users' SpamAssassin preferences get "stacked" 
on top of each other. Now, the SpamAssassin preferences in the default home 
directory are loaded before each set of user preferences, so they are 
"stacked" on top of the user prefs; this means that, if the default 
preferences file contains explicit settings for every parameter changed in 
a  user preference file, SpamAssassin will return to these defaults between 
users.

- Worked around SpamAssassin's problem with extremely large messages, by 
only scanning the first 250K of each message.

- Changed the location of the per-user configurations used by CGPSA (old 
configurations will automatically be moved to the new location).

Known Issues:

- If CGPSA has to truncate a message in order to scan it, that message will 
almost definitely trigger the SpamAssassin rule "MIME_MISSING_BOUNDARY". 
This probably won't cause non-spam messages to cross the spam threshold, 
but it is a possibility.

- When CGPSA catches a HUP signal and reloads its preferences, it leaks 
some memory (as a result of the old SpamAssassin, or parts thereof, not 
going away). This cannot be fixed with the current version of SpamAssassin; 
work is underway on a patch to SpamAssassin to enable a fix.

- Entries in the CGP log that are line-wrapped have "\t" as their leading 
character when CGPSA is used with Perl earlier than 5.8. This is a result 
of limitations in the older Text::Wrap code.

-Dan

------------------------------------------------------------------
Daniel M. Zimmerman                                TFF Enterprises
M/S 256-80 - Caltech                http://www.tffenterprises.com/
Pasadena, California  91125  USA            dmz@tffenterprises.com