				AUTO7P UPDATE

Version 1.31a
- Fixed bug that sometime caused mulafunction in the inquiryfile function if
  the server directory was not \AUTO7P
		==================================================

Version 1.31b
- Fixed bug in the reconstruction of original sender of multiple CP messages.
- Fixed bug caused by the presence of \ in start of the path. Some time the
  temporary file created by auto7p was not deleted.
- Modified the command auto7p part, now accept also hex value, is preceeded by
  the prefix 0x, like C standard. For example, to split out the part 12 of a
  file, you may insert the command AUTO7P PART 12 or AUTO7P PART 0x0C
		==================================================

Version 1.32
- The line that specify the auto7p sysop messages call now accept an asterisk
  like callsign. If you put * like call, no sysop messages will be generated.

- Add a new parameters in auto7p.cfg, in line 7. Previusly this line tell
  auto7p the max size of the import block. Now exist a second number in the
  line, just after the max block, that tell auto7p how to treat the error
  request. So, for example, if the previsuly line was:
	50
  The actual will became:
	50	3

  This value, 3 in the example, is set in kbytes, and accept value of:

  -1: 
  If -1 is specified, all the error request generated will be automatically
  sent, exactly like in the previusly version.

  Between 1 and 1000:
  Any value between 1 and 1000, specify the estimated correction limit that 
  will be automatically sent. For example, if you set 5, all error messages
  that will cause a correction file (at the start bbs) lowest of 5 kbytes, will
  be sent automatically, the others will be put into a file called ERRORS.BIG,
  in the AUTO7P working directory, waiting for sysop examine.

  0:
  0 means that all the error messages will be put into the ERRORS.BIG,
  regardless of its lenght.

  All the value not in the above range will cause the set to -1.

  Remember that the limit value is NOT the size of your .err file, but is the
  estimated size of the correction file that will be created on the remote bbs.
  So this value will increase trough the net, due to the R line added by bbs.

  The format of the file ERRORS.BIG is exactly like the mbl-rli forward. How to
  process it? You may use serveral modes.... with an editor you may read it,
  erase the unwanted messages, copying the remaining into the MAIL.IN bbs file,
  but i think that the provided program BIGERR.EXE is more useful hi hi.
  Se the related doc for the usage of BIGERR.
		==================================================

Version 1.32a
- there are a bug inside the release 1.32a... under certain condition, the
  server attempt to use an invalid letter unit. This release fix the problem.
- Starting from this version, the server will be distribuited in a not
  compressed form... this may help the creation of patch for little bug 
  whitout resend the entire exe file.

Version 1.32b
- to avoid unwanted result, due to some facts happened in the net, is now
  possible to limit the size of the 7mf file in the decoding phase (pratically
  the size of the original file). If for example the size of the file exceeded
  the max allowed size, the files are not decoded, and the server send a
  message to the sysop for furter actions. Big messages are not deleted, but
  are maintained in the auto7p directory. 

  The parameters is set in auto7p.cfg line 7, the same that set the max size of
  the import block and the max size of error request file. Vale are expressed
  in KBytes, and accept value between 0 and 1000000. Value of 0, or over
  1.000.000 (1 Giga bytes!), disable the size check control.

For example:

#  MaxBlock    MaxCorSize    MaxOrgSize
   50		5		2000

that means: 50   Kbytes max split block
	    5    Kbytes max estimated correction size
	    2000 Kbytes max allowed in the reconstruction of the org file.
		
