CHANGE HISTORY
==============
27th Oct 2003
-------------
  a) Versions of bogofilter later then 0.14.5.4 don't appear to echo the
     filename back when the -bp parameters are used. This confuses BOGOD
     which is looking for the echo. BOGOD has therefore been changed so
     that it looks for EITHER the echoed filename OR the same first few
     bytes of the original message (usually the Return-path: header).

18th Oct 2003
-------------
  a) Finally got around to displaying something inthe top half of the
     screen. Display will now show some stats for each server to which
     a connection is made.

17th Oct 2003
-------------
  a) Begun the process of turning BOGOD into a fully-fledged daemon! It
     is now possible to use TCP/IP to communicate between PROXYC & BOGOD.
     The former method of using a NamedPipe will be retained, but in
     future will only be used for shutting down BOGOD.

  b) As part of the same change, a proper protocol will be introduced for
     BOGOD and the programs that communicate with it. This protocol will
     be loosely based on the spamc/spamd protocol that can be found in
     SpamAssassin. With a protocol in place, it should then be possible
     to release a development toolkit to enable people to write their
     own code that will make use of BOGOD. This kit will probably just
     consist of a header file, an import libray and a DLL.

  c) Once the toolkit is in place, the next logical step should be to
     develop a REXX front-end!

13th Oct 2003
-------------
  a) Changed the way that ProxyC\BogoD finds and uses bogofilter. This
     should be more in line with how the bogofilter code works when it
     comes to locating bogofilter.cf & wordlist.db.

11th Oct 2003
-------------
  a) Discovered a problem when using ProxyC in conjunction with PMMail/2.
     PMMail/2 crashes when ProxyC is receiving a large message. This
     appears to happen when a very large (> 1.5 Mb) message is being
     downloaded. Obvious conclusion is that PMMail/2 after issuing the
     RETR command, times out and doesn't know how to handle the condition,
     because ProxyC won't give the +OK until it has received the message
     and passed it through bogofilter. On a 64kb BRI ISDN line, it takes
     about 5m20s to download a 2Mb file. PMMail/2 times out well before
     ProxyC can download the message and send a +OK response.

     Solution: institute an upper limit on the size of a message that can
     be filtered by ProxyC/bogod/bogofilter. Limit presently set at 1Mb.
     The result of this is that there will be *no* X-Bogosity header in
     these large messages. Entries suggesting that the message was not
     filtered because of size will show up in proxyc.log.

  b) Corrected the way that ProxyC starts up to include a check for a
     running copy of bogod. This *should* prevent multiple copies of
     bogod from being started. Note that bogod limits the number of
     ProxyC clients that can be active, so starting a second copy of
     ProxyC will work if the -l parameter is different. The second copy
     will not, however, become 'active' until the earlier copy has been
     terminated.

7th Oct 2003
------------
  a) Created MSGTRACE.EXE to format the msgtrace.dmp file to stdout. At
     the same time, changed the format of the data in the file as well
     as the source of the data. File now includes what the mail-reader
     issues as well as what the POP3 server sends back.

4th Oct 2003
------------
  a) Blind APOP authentication is not possible! With the introduction
     of the ability to concurrently process multiple accounts on
     multiple servers, APOP can no longer work as an authentication
     method. The problem stemming from the fact that PROXYC does not
     know the address of the server until it receives the APOP command
     from the mail-reader. In order to receive the APOP command, PROXYC
     has already issued a POP3 Greeting of its' own, which, out of
     necessity, must include a timestamp that will be different to that
     issued by the POP3 server to which we are connecting. Thus, the MD5
     checksum issued my the mail-reader can not be validated by the POP3
     server. Only by PROXYC - and PROXYC doesn't know the 'secret'. As
     MD5 is not reversible - Catch 22!

     To make APOP work in the interim, PROXYC would need to know the
     'secrets' used by the mail-reader. Then the incoming MD5 checksum
     could be verified, and the correct MD5 checksum generated for the
     server to which a connection is made. Not an ideal situation!

     The annoying thing is: in the original case of a single POP3 server,
     the APOP command issued by the mail-reader could be successfully
     passed on to the POP3 server.

     The only solution to this anomaly is eventually turn PROXYC into a
     self-contained POP3 server with an RPOP application on the back-end
     to fetch and store mail locally. Until that happens, APOP and AUTH
     methods of authenication must be left in abeyance.

     So, for the time being, APOP and AUTh commands will result in PROXYC
     responding with '-ERR Command not accepted'.

  b) Started work on adding a routine to run some Perl-Compatible
     Regular Expressions on the raw message text. SpamAssassin contains
     some interesting REs that might identify SPAM without the need to
     run the message through bogofilter. If this shows some promise then
     it may be possible to run these on the results of a TOP <n> 1 command
     and so pick out spam based only on RFC822 headers.

2nd Oct 2003 - Version 0.1.5a
-----------------------------
  a) Decided not to release 0.1.4a for reasons of incompleteness. 0.1.4a
     included code to intercept the USER command and parse the account
     string to pick up a hostname and port number. This works fine, but
     I realised that I also needed to do something about the APOP and
     AUTH commands at the same time! Hence, 0.1.4a not released.

  b) Decided that the AUTH command was too complex to be mucked about
     with at this stage. Consequently, version 0.1.5a of ProxyC will
     NOT support it. If a mail-reader uses the AUTH command, ProxyC
     will give an -ERR response.

  c) Added a logfile for PROXYC - called (imaginatively) proxyc.log

1st Oct 2003 - Version 0.1.4a
-----------------------------
  a) PROXYC should now be able to handle multiple accounts on multiple
     POP3 servers concurrently. To accommodate this, changes need to be
     made in the mail-reader configuration. See the README file for
     details and an example.

     Although PROXYC now has this ability, bogofilter can only handle
     one message at a time [linux ports strike again!]. To enforce
     this restriction, PROXYC treats bogofilter as a serially-reusable
     resource and controls access to the pipe via a mutex semaphore.

29th Sept 2003
--------------
  a) Version 0.1.2a
     Emergency fix for POP3 server that only returns +OK in response to
     a RETR command.

  b) version 0.1.3a
     More fixes to try and prevent out-of-synch problems between BOGOD
     and bogofilter.

     More fixes to prevent random crashes in PROXYC. These crashes are
     happening outside the message download process which has already
     been protected. This current spate of crashes appears to be caused
     by a problem in thunking code emitted by OpenWatcom 1.1. Even now,
     the Vio functions are 16-bit and require a thunk when called from
     32-bit code.

  c) Added code to try and record crash information in the trace file
     .\msgtrace.dmp

28th Sept 2003
--------------
  a) Fixed some minor bugs that may have caused problems with some mail
     readers.

  b) Now have a workable mechanism for preventing crashes in PROXYC from
     causing other problems with BOGOD or a mail reader. In particular, a
     trap D encountered whilst processing a downloaded message before it
     is given to the reader, will result in an -ERR response. Whilst not
     perfect, this does in fact keep everything running and allow a clean
     shutdown to take place.

27th Sept 2003
--------------
  a) Once again, the variety if POP3 has servers caught me out! Why can't
     they all send the same format responses! This now makes 3 different
     variations of the +OK response that I've seen:-
       1) +OK <n> octets follow
       2) +OK message follows
       3) +OK

     Are there any more out there?! At least I haven't heard of a server
     that responded -ERR (or -ERR <some text>)!

     Should now handle any server that does one of the above. All I was
     interested in was gaining some early indication of how big an email
     is. With the last two, I've had to make a guesstitmate of 8kb.

  b) Fixed a possible source of some crashes when closing PROXYC down. This
     was the first time I had encountered this particular problem, and it
     showed that attempts to recover from a crash gracefully are not all
     I thought they were. Oh well, back to the drawing board!

24th Sept 2003
--------------
  a) Changed BOGOD to try and be more intelligent when it comes to
     parsing the X-Bogosity header. BOGOD has always assumed that the
     user had left the format and name of this header as the default
     setting. It is now known that BOGOD and/or PROXYC would crash if
     this were not the case.

     All details as to how this line is formatted are available in the
     bogofilter.cf configuration file. BOGOD now reads this file on
     startup to determine whether the user has made any changes to the
     default settings for :-

      1) spam_header_name
      2) spamicity_tags
      3) header_format

     BOGOD should now be able to dynamically parse the added RFC822 header
     line (spam_header_name) using whatever format (header-format) and tags
     (spamicity_tags], the user has selected. Note that in terms of RFC822,
     it makes little sense to define a header_format that doesn't have the
     '%h: ' sequence in column 1 of the line, unless you want to do
     something like this:-

     spam_header_name = "X-Mine"
     header_format = "X-SpamStatus: %c, %h"

     PMMail filters should then be looking for h.X-SpamStatus and not
     h.X-Mine

     The alternate, brute-force solution for this was to force any user
     changes in bogofilter.cf back to their defaults. This I believe, would
     have been unacceptable.

  b) There have been one or two minor quibbles with the size of the command
     window that PROXYC runs in. Rather than return to a boring 25*80 frame,
     I decided that the users should be able to select their own window
     size. To accomplish this, I have introduced a proxyc.cf configuration
     file. ProxyC will create a default version of this file when it is first
     run. It is an ASCII text file, so can be changed with any, decent text
     editor.

  c) There is an undocumented (until now) switch, -d, that will perform some
     form of limitied tracing of data passing between ProxyC and the outside
     world. If enabled with the switch, ProxyC will create a file named
     MSGTRACE.DMP in the working directory.

     NOTE: DATA IS CAPTURED WHEN THE MAIL-READER ISSUES A RETR COMMAND. The
     program will NOT record any userids or passwords.

     If you have problems using ProxyC, restart it ising the -d switch. Then,
     retrieve one message (if you can). Then, send the MSGTRACE.DMP file to me
     along with a detailed decription of your problem. I have seen that not
     all POP3 servers behave the same as mine, and I need to have some details
     about all those servers that I've never come across, so that I can make
     ProxyC as robust and general as possible.


23rd Sept 2003
--------------
  a) Corrected a problem when the POP3 server doesn't indicate the size
     of the incoming message. PROXYC would crash! Thanks to Serge Vikulov
     for having a POP3 server that doesn't behave in exactly the way I
     interpreted RFC1725!

  b) Begun adding a 'prettier' UI to PROXYC.EXE. Suggestions for any
     improvements or additions are very welcome!

  c) Reorganised BOGOD code so that I can take advantage of some extra
     planned facilities. Essentially, this is preparation for being able
     to initiate a 'training' run from PROXYC. To do this, some irritating
     bugs in bogofilter have to be circumvented. Circumvention is only
     possible if bogofilter is shut down before the training run is started.
     This reorganisation should make it possible to terminate bogofilter,
     do the training run and then restart bogofilter.
