Klementine

========================================================================
Release_0_17BLD003
    Release date: 2006-04-11

    Changes since last public release (0_16BLD010):

    Bug fixes:
    - Fixing the nasty bug that caused the application to hang
      in case a message with an empty "To:" field was detected.
========================================================================
Release_0_16BLD010
    Release date: 2006-04-04

    Changes since last public release (0_15BLD006):

    Modified:
    - The DupCheck rule now also check for equal recipients
      to decide if two mails are equal.
    - The source package no longer contains required jar files.
      There is a separate package now for the required jars.

    Bug fixes:
    - Correct treatment of seriously wrong from addresses
    - Correct termination in case another instance is already running
========================================================================
Release_0_15BLD006
    Release date: 2006-03-11
    Changes since last public release (0_13BLD016):
    New Features:
    	- Logging panel in UI now functional
    	- Online help created.
    Bug fixes:
    	- Encoded header fields are now decoded before they
    	  are set into the table cell in the UI
========================================================================
Release_0_13BLD016
    Release date: 2006-02-22
    Changes since last public release (0_12BLD024):
    New Features:
    	- Graphical User interface in its first version
    	- Script to install initial configuration
    	- Store result summary after each run for generation
    	  of history reports
    	- Each (rejecting) rule may be configured to not delete a
    	  matching mail on the server but instead just leave it there.
    	  Such mails will appear in the "postponed" list and may
    	  be deleted in a subsequent run.
========================================================================
Release_0_12BLD024
    Release date: 2005-12-30
    Changes since last public release (0_11BLD020):
    New Features:
    	- Prepend a + sign to a line in the "postponed" file to flag
    	  a postponed message to be accepted.
    	  Explanation:
    	  If messages that have no matching rule to accept them are 
    	  postponed ("Download only white mails" is set to true) a file
    	  for each account is created that keeps a single line for
    	  each of such messages. If you do not want to add a pattern
    	  for those messages to your white rules you can just prepend
    	  a single plus sign (+) to the lines of those messages which you
    	  would like to accept.
        - New global option "SaveResults". If this is set to true the
          application will save the results of the filtering to disk.
          The various files will be written to the directory "results"
          underneath $KLEMENTINE_HOME. There will be a set of files
          for postponed, for accepted and for rejected messages. For 
          each account one file will be created for each set.

        - A first version of the UI is available! But do not expect
          too much - it is just a beginning.

    Modified behaviour:
	- The file name for log4j configuration can no longer be specified
	  in the configuration file but must be located in the
	  directory KLEMENTINE_HOME (which is the directory from where
	  the executable is started if not explicitely set)!
	  Explanation: Since log4j is configured to watch its config
	  file the application will react on any change to it.
	  If you successively load multiple config files using the GUI
	  it would mean to watch several log4j config files. This is not 
	  possible and as a consequence only the first log4j config file
	  that is read will be honored and watched throughout the
	  complete lifetime of the executable.

	- With the upcoming UI it is no longer possible to have everything
	  in a single jar archive. I had to drop the beautiful tool 
	  "one-jar" and install a complete directory structure :-(
========================================================================
Release_0_11BLD020
    Release date: 2005-11-07
    Changes since last public release (0_11BLD017):
    	- LDAP-Version 3 implemented (Version 2 is taken as fallback
    	  if Version 3 fails)
    Bugfixes
    	- Explicitely closing transport connection after sending message.
    	  Depending on the SMTP server processing could take very long in
    	  case many messages were subject to be delivered. This was due
    	  to not explicitly closing SMTP connections.
========================================================================
Release_0_11BLD017
    Release date: 2005-09-27
    Changes since last public release (0.10B021):
    	- Delivery to local store implemented.
    	  All messages are fetched from the remote store and buffered 
    	  on the local disk. The delivery to the final destination (ResendTo)
    	  then takes place referring to the locally stored messages.
    	  This was done to circumvent problems that occur if you have
    	  a great amount of messages in several remote stores and the
    	  delivery to the local destination address is comparatively slow.
    	  In such cases the remote accounts sometimes lost their patience
    	  and closed the connection.
    	  With the local buffering the connection to the remote store can
    	  be closed relatively early. Of cause all messages that have been
    	  buffered locally will be deleted on the remote store (provided
    	  you have not set KeepOnServer to true). If your computer crashes
    	  or is shut down after the messages have been deleted on the 
    	  server but before the delivery to the final local destination
    	  is finished special care must be taken to ensure that no message 
    	  is lost. I guarantee that you can switch off your computer at
    	  every stage during processing and no message will be lost:
    	  Messages will not be deleted on the server until they have 
    	  successfully been stored on the local disks. Messages that have 
    	  been stored on the local disk will not be deleted until they
    	  have successfully been delivered to their final destination.
    	  Messages that have been stored locally and could not be delivered
    	  during the same run of the program will be resurrected and 
    	  delivered in a subsequent run of the program.
    	- "Download only white mails" introduced.
    	  There are two possibilities that tag a mail to be
    	  downloded from the remote server: Either it matches an accept
    	  rule or it does not match any rule. Often it is relatively simple
    	  to create quite good accept rules but it is very hard to catch all
    	  spam by deny rules. As my accept rules are rather mature 99% of 
    	  the mails that do not match any rule are spam mails. If you set 
    	  this parameter to true mails not matching any rule will not be
    	  downloaded but just their signature (From, Subject, and DateSent)
    	  is written into a file. Taking a short look at this report it is 
    	  simple to give the "go" to delete these mails in a subsequent run. 
    	  See the next paragraph for details.
	- "Delete postponed mails of last run" introduced.
	  Mails that have been examined during the last run and did not
	  match a rule are written into a file (provided the respective
	  config parameter is set to true). If you have checked that those
	  mails are all spam create a file named "deletepostponed.flag" 
	  in the directory that is given in the environment variable
	  KLEMENTINE_HOME. You must also make sure that the user under which
	  the Klementine application is run has write access to this file.
	  If this file exists and is writable mails that have been postponed
	  during the last run will be marked for deletion on the server.
	  The  file "deletepostponed.flag" will automatically be deleted so
	  that no mails will accidentally be deleted without having checked
	  the signatures of the postponed mails and deliberately having
	  created the deletion flag file.
	  If there is a mail among the postponed that is no spam you should
	  adapt your accept rules so that this mail is matched. I suggest not
	  to create the deletion flag file before the new rule has been verified.
 
	
========================================================================
Release_0_10BLD021
    Release date: 2005-01-21
    Changes since last public release (0_8):
    	- Code redesign (preparation for graphical user interface)
    	- Switch to JavaMail 1.3.2
    	- Improving robustness
========================================================================
Release_0_8BLD013
    Release date: 2004-09-16
    Changes since last public release (0_6): 
        - Fixing problem with decoding subject line with newline characters
        - Fixing problems with malformed From fields
        - Improving robustness
        - Several minor bugfixes