CHANGES---------------------------------------------------------------
Thu Feb 06 2002
	- PLD: Corrected testing conditions of the name= substring to test for
		both a space OR a ';' (semicolon) in order to accept the value
		after the 'name=' as being a filename.
		(Thanks to Marc Bleuwart for the supplied mailpack exhibiting this
		issue )

Wed Feb 05 2002
	- PLD: Added total BASE64 decode line count output for failed decoding
		operations when in --debug mode

Sat Feb 01 2003
	- PLD: Corrected some *_init() calls and *_set_verbose() as well as
		*_set_debug().

	- PLD: Broke down the mime.c file into some smaller modules:
		boundary-stack.[ch] - Handles the boundary string ordering for
			the mailpack decoding.

		filename-filter.[ch] - Performs basic filename sanity / paranoia
			checking.

		uuencode.[ch] - A bit of a misnomer, this module currently deals
			with the detection and decoding of uuencoded data.

	- PLD: Merged 3 string handling modules into one.  While this seems to go
		against the flow against the move to modularise the mime.c file
		it is better to have the files XAM_strtok, zstr and strlower all
		merged as they are all part of the same family of strings handlers.

	- PLD: Moved ISO decoding to directly after all the headers have been read
		and a "true blank" has been received.  This way we do not have to
		worry about decoding the individual components of the headers, rather
		they are presented in an already decoded form when the calling program
		gets back the header pointer.

Fri Jan 31 2003
	- PLD: Reordered the MIME_decode_filename() function so that it attempts to
		decode ISO filenames -before- any paranoia filters are applied.  This
		is because certain BASE64 characters ( ie / ) are interepreted as
		paranoid invoking characters, thus are stripped from the filename 
		before ISO decode gets to use them.

		Thanks to Michal Perchel for supplying the mailpack exhibiting this
		property.


Tue Jan 28 2003
	- PLD: Replaced MIME_read() fgetc/fputc calls with a fread/fwrite binary
		functions to prevent ripMIME from terminating its file/stdin reading
		too soon if it received an EOF character.

Mon Jan 27 2003
	- PLD: Corrected segfault in parameter parsing if the last parameter was 
		a -d, -i or -p.  Whole parameter parsing block moved to its own
		function.

	- PLD: Replaced scandir() calls in mime.c ( for post-decode cleanup ) with
		opendir()/readdir() - Solaris ( and possibly other OS's ) have 
		different implementations of scandir() compared to Linux/BSD

	- PLD: Silenced several messages in MIME_headers and MIME tnef decoding which
		were appearing despite having -v selected

Sun Jan 26 2003
	- PLD: in MIME_decode_filename(), removed limitation of filenames only having
		a space character and lengths greater than two (2).

	- PLD: Corrected header unfolding in MIMEH_read_headers()
		This rectifies the situation where some filenames are cropped because they
		were spread over two lines in the headers.

	- PLD: Moved ISO decoding functions and QuotedPrintable functions into a new
		module called 'libmime-decoders'.  

	- PLD: Initialised encoding_type in the ISO decoding routines in order to 
		silence some compilers about a 'usage unitilised' warning.

	- PLD: Corrected situation where an attempt to extract a file name would
		be misled due to a substring 'name' appearing anywhere within headers.

		Narrowed down the conditions required in order for a 'name' word to appear.
		This corrects the issue as reported by Chris Hine

	- PLD: I've sorted out the Quoted-Printable decoding
		issues.  Who would have thought such a relatively simple 
		decoding process could cause so much pain.  As a consequence
		some of the prior 'patches' have now been removed as they are
		no longer needed. ( removed patches: Mirko Buffoni )

Sat Jan 25 2003
	- Planning on releasing as 1.2.17.0

Fri Jan 24 2003
	- Created a new function to handled decoding of ISO encoded strings, now called
		MIME_decode_ISO().  This function is used by MIME_decode_filename() and
		will also be used by any programs wanting to decode other ISO encoded strings
		such as email addresses and such.

	- Removed MIME_init_hexconv() call ( which previously setup the BASE64 conversion
		matrix - but we now have a compile-time static array setup for that )

	- Renamed 'quick_clean_filename()' to be MIME_filename_paranoid_filter()
		which is called from within MIME_decode_filename()

	- Renamed MIME_clean_MIME_filename() to MIME_decode_filename() as its
		primary function is mostly to handle ISO decoding as well as path
		prefix stripping.

	- Deprecated --no_paranoid and rather added in --paranoid. 
		Setting --paranoid on will result in any high-ascii
		characters to be set to _'s

	- Changed void return value of quick_clean_filename to 'int'

	- Added testing of '=' char prior to a ? for testing presence of
		an ISO encoded filename in MIME_clean_MIME_filename()

	- Added functional handling of ISO encoded filenames in headers
		( see MIME_clean_MIME_filename() ).  Still need to merge
		the functions of MIME_clean_MIME_filename() and quick_clean_filename()

Wed Jan 22 2003
	- Corrected functioning of --no_nameless operations.

Tue Jan 21 2003
	- Added trailing \n break after decoding a QuotePrintable line
		(submitted by Mirko Buffoni )


Mon Dec 16 2002
	- Corrected soft-break decoding of Quoted-Printable encoded data

Tue Nov 12 2002
	- Released as 1.2.16.21
	- Updated FFGET module to 1.0.0.3 release - fixes garbage-end
		problem with some BASE64 decodes which don't terminate
		their data with a \n[\r]

Sat Nov 09 2002
	- NOT-RELEASED (internal use only, see 1.2.16.21)  1.2.16.20
	- Changed the strlower() function to use unsigned char rather
		than signed char, this allows for non-ASCII conversions
		on the tolower() call without breaking (ie on non-english
		character sets)

Wed Nov 06 2002
	- Released as 1.2.16.19
	- Added a patch from Phil Brutsche to deal with space-embedded
		filename, name MIME fields.


Fri Oct 11 2002
	- Corrected segfault when a filename with a \" ending was encountered
	- Cropped filenames with ? in them which are NOT ISO encoded to only
		include the part before the ?

Thu Oct 10 2002
	- Updated the logger file which contained a segfault issue
		when sending a string containing a % symbol to syslog.
	- 

Wed Jun 26 2002
	- Added MIME-headers save-file closing function. This prevents
		a segfault when MIME_unpack() is called multiple times
		within the same program.

Fri May 31 2002
	- Release as 1.2.16.16
	- Fixed same issue for Double-CR saved files
	- Failure to prefix the unpackdir onto the recursive decoding of 
		mailpacks extracted from within mailpacks (ie, EML files) caused
		extractions to directories other than the present-working-dir to 
		fail [partially] due to not being able to locate the newly created
		/ extrated mailpack.
		
		That teaches me to 'ignore' the warnings that were popping up in my
		syslogs about 'Cannot locate file'.
		
		
Sun May 26 2002
	- Release as 1.2.16.15
	- bug causing ripMIME to enter into an infinite loop if the boundary
		contained the phrase "boundary=" within it.  Thanks to
		Steffen Clausjuergens for supplying the mailpack exhibiting
		this defect!

Sat May 25 2002
	- Release as 1.2.16.14
	- Minor bug in FFGET_raw() causing missing of decoding due in 
		mailpacks which have mixed EOL definitions, ie, the 
		email uses \n only in the main headers, but then switches
		to \r\n in the bodies [ Can someone /PLEASE/ tell me why
		any peice of email software would do this !?!? ]

Wed May 22 2002 
	- Release as 1.2.16.13
	- Corrected block-boundary read line error with FFGET_fgets()
	- Corrected segfault error with UUDECODE due to XAM_strtok() 

Sun May 12 2002 (Mothers Day - Be nice to your mother and take the day off
		from IRC'ing or sufing the net)

	- Release 1.2.16.12 .... one day I'll release 1.2.17.0

	- Improved nested decoding.  There was a very strange size-specific
		decoding mishap which was causing some packs to unpack 
		flawlessly, others to fail, with the only difference being that
		one had more than 1089 bytes of headers. Cleaning up the memory
		leak issues resolved it.  Though I'm always a bit fearful of
		such dissapearing bugs.

	- Cleaned up memory free'ing, used 'ccmalloc', nice little tool
		I recommend it to people trying to at least get a coarse
		view of what is being left out. I found that simply by fixing
		up the memory leaks I had, one of my "wierd" bugs went away
		very nice of it.

Tue May 07 2002 pldaniels@pldaniels.com
	- Added new function to MIME_headers object, to return the
		current status of the headers save status. This allows
		us to prevent opening up multiple FILE *'s on the same
		named _header_ file, potentially causing corruption
	- Removed the "WARNING: Possible pointer size being sent" debugging
		message.

Tue Apr 30 2002 pldaniels@pldaniels.com
	- Updated TNEF with patch supplied by Joe Gooch (Thanks Joe)
		corrects segfault when decoding certain TNEF's.
	- Added new function in FFGET.  FFGET_set_watch_SDL() tells FFGET
		to either be watching out for ^M^M sequence, or not to
		(1, 0 respectively).  This is required so that we can 
		prevent ripMIME from interpreting the ^M^M sequence if it's
		found in the email BODY as a SDL-Outlook exploit.
		Thanks to Elio de Santi for the mailpack which revealed this

Fri Apr 26 2002 pldaniels@pldaniels.com
	- Lots of fixes in the FFGET routines. Including the introduction
		of a two-stage FEOF status.  Initially we mark that we've
		reached the end of the /real/ file by flagging FILEEND, 
		then, when we actually try to read a new data block using
		FFGET_getnewblock() we flag FFEOF.  Previously we'd flag
		FEOF too early. This would cause corruption of various 
		attachments.

Tue Apr 23 2002 pldaniels@pldaniels.com
	- corrected memory leak causing "Killed" messages on large 
		mailpacks with lots of text/print-quotable attachments
Mon Apr 22 2002 pldaniels@pldaniels.com
	- Re-tuned the UUencode line detection sequence.  If anyone is
		aware of a /precise/ method to detect a uuencoded attachment
		in mailpacks, both as RFC and Outlook[stupid], please email
		me on pldaniels@pldaniels.com

Fri Apr 19 2002 pldaniels@pldaniels.com
	- Corrected FFGET_fgets() function which was returning NULL 
		one call too early.  Rather than sending back the last
		"partial" line read (end of buffer), it would assign
		the data to the buffer, but also return NULL, which 
		caused some programs to exit early from their reading
		loops.
		
		I'm actually quite surprised things even worked with
		this error... amazing what can slip by.


Sun Apr 14 2002 pldaniels@pldaniels.com
	- Corrected _headers_ file output location, which was defaulting
		to the execution dir, rather than the unpackdir

Fri Mar 08 2002 pldaniels@pldaniels.com
	--Released as 1.2.16.6

	- Added ability to decode "x-uuencode" files even though this
		type technically is not specified by the RFC's (one 
		should be using BASE64 or QuotePrintable.

	- Corrected UUencode filename extraction from the header 
		triple

Thu Mar 07 2002 pldaniels@pldaniels.com
	--Released as 1.2.16.5

	- Fixed XAM_strtok() call which was occasionally failing if
		there was a delimeter at the end of the string.

Wed Mar 06 2002 pldaniels@pldaniels.com
	- Renamed zstrncpy.[ch] as zstr.[ch] as it's becoming a generic
		library with more than just the zstrncpy function in it.
		It now contains the zstrncat and zstrncate calls

Tue Mar 05 2002 pldaniels@pldaniels.com
	--Released as 1.2.16.4
	
	- Replaced all strncpy and strcpy routines with zstrncpy() calls.


Sun Mar 03 2002 pldaniels@pldaniels.com
	--Released as 1.2.16.3
	
	- Replaced file write routines in BASE64 and UUDEC decoders so that they
		use buffered write (reduces the number of fwrite() calls. This
		also gained another 10% of performance over direct write.

Sat Mar 02 2002 pldaniels@pldaniels.com

	- Replaced in MIME_base64_decode() the FFGET_fgetc() call with a direct 
		source code from the FFGET_fgetc() routine. Whilst this does mean
		that I will have to keep track of the changes I make in FFGET_fgetc
		and ensure that I port them across to the BASE64 decode routine, it
		does make for a good 10% gain in performance as shown on a 80Mb data
		test suite.

	- Converted Base64, Hexconv and UUDEC routines into static (compile time)
		fixed tables so that there isn't any need to build them each
		time the program is run. This saves us on startup time, although
		minimal, it does help.

Thu Feb 28 2002 pldaniels@pldaniels.com
	- Released as 1.2.16.2
	- Updated FFGET routines with patch as supplied by J.Gooch
	
Tue Feb 26 2002 pldaniels@pldaniels.com
	- Moved to 4 digit version numbers

	- Added f->FFEOF = 0 to the ffget_set_stream function.  Was causing
		an intermittent FEOF() status based on random data without
		it being there.

Sat Feb 23 2002 pldaniels2pldaniels.com
	- Committed ripMIME to local CVS

Wed Feb 20 2002 pldaniels@pldaniels.com
	- Releasing as v1.2.16
	- Cleaned up FFGET routines and added more comments.
	- Added new DEBUG mode selection routines.  Now debugging can be
		activated on a per-level basis, with (default) now there being
			*_DNORMAL == Debug normal
			*_DPEDANTIC == Pedantic debugging (lots of output)

		ie, in mime.c, there is now lines like

			if (MIME_DPEDANTIC) fprintf(stdout,"%s",line);

		This replaces the existing non-level sensitive routines of

			if (_MIME_debug) ....


	- HUGE stuff up.  Non-quoteprintable encoded text files were not
		being written out because I accidently left out the fprintf
		statement in MIME_decode_text() routine... REALLY bad MISTAKE.
		This was causing text files to be written out as 0-byte files.

		Fortuntely this error was picked up by the Xamime testing suite.

	- Releasing as v1.2.15 (I wonder if these releases will stop coming
		out so quickly)

	- _FINALLY_ fixed TNEF decoding, many thanks to Chea Chee Keong
		for the help provided, very valuable.

	- Releasing as v1.2.14

	- FEOF detection mishandling in MIME_decode_uu() cleaned up (uses
		the FFGET_feof() call rather than feof(), which (the feof)
		could prematurely return TRUE rather than when FFGET returns
		true, this is due to the fact that the FFGET routines will
		(on the last valid read) read up to the end of the file causing
		feof() to return TRUE, however, until all the data is read out
		of the FFGET buffer, it should not return true.  Hence, all
		routines using feof() were replaced with FFGET_feof()

Mon Feb 18 2002 pldaniels@pldaniels.com
	- Releasing as v1.2.13

	- CRCR logic cleaned up in FFGET_fgets() (thanks to Joseph Gooch for
		his help in resolving the logic routines)
	- Initialisation of ungetc flag in FFGET
	- Removed MIME detection debugging output
	- Added anti \0 poisoning filtering

Sun Feb 17 2002 pldaniels@pldaniels.com

	- Releasing as v1.2.12
		Although I've not had a chance to verify that ripMIME extracts all
		the possible \r explioits which can be used against Outlook/Express
		I am certainly confident it can extract most of them.  I've ran this
		ripMIME against about 600Mb of normal emails, all of which have extracted
		correctly in regression tests.

		I'm _STILL_ seeking more assistance to deal with TNEF decoding.  I have
		one mail pack which refuses to correctly extract, rather it results in
		the TNEF routines attempting to access data beyond the limits of the file
		(yes, it's protected against that, but it's still annoying!)

	- Added FFGET_fgets() true blank detection for reads, this is to
		deal with potential trickery as mentioned in bugtraq regarding
		fgets() falsely returning a single \n as though it was a blank line
		when really, it was just the previous fgets didn't have enough
		buffer space to include the last \n.

	- Corrected file Unique Nameing name cropping.

Fri Feb 15 2002 pldaniels@pldaniels.com

	- Made ripMIME report its version via STDOUT instead of STDERR

	- Changed "Decoding TNEF format" report to report to STDOUT instead
		of STDERR

	- Replaced entire file I/O routines to use FFGET, which now supports
		fgets(), fgetc() and raw-get routines.  This was done so that we
		could (originally) detect the presence of an offending <CR><CR>
		double byte in the headers of some emails which may be used to
		exploit Outlook's interpretation.

	- Fixed zstrncpy which was copying one byte too few when a strncpy
		was done.  This was causing filename crop problems. -NOTE- this
		was primarily due to the fact that the size of buffer specified
		was inclusive of the \0 terminator.... as apposed to an actual BUG

	- Added into MIME_headers the ability to decode "Content-Location"
		to extract filenames from the new Microsoft MHF formatted emails
		(basically it's a bundled together WWW page HTML + images)

Thu Feb 14 2002 pldaniels@pldaniels.com
	- Added header detection of double CR exploit usable against
		MS Outlook (This feature is more of use to programs which
		actively filter against exploits such as Inflex/Xamime

	> Need more help with TNEF decoding!!!!!

Wed Jan 30 2002 pldaniels@pldaniels.com
	- v1.2.11
	- Added ability to decode MULTIPLE UUEncoded attachments within the
		same body of text.

Tue Jan 29 2002 pldaniels@pldaniels.com
	- v1.2.10
	- Corrected mistaken use of 'n' count in UUdecode byte count resulting
		in excessive sized files (with useless data)
	- v1.2.9 released
	- Removed non-used functions MIME_getchar() and MIME_insert_X_header()
	- Added UUDecode routines
	- Added --no_uudecode option

Mon Jan 28 2002 pldaniels@pldaniels.com
	- v1.2.8 released

	- Patch suppled by Tim J. Robbins for buffer-smash as specified by
		BugTraq applied
Thu Nov 15 2001 pldaniels@pldaniels.com
	- Corrected potential buffer overrun situation in raw-decode mode
	- Corrected buffer overrun with MIME_headers which allowed massive
		sized filenames to cause segfaults (Thanks to Tristan Aston
		for bringing this to my attention)
	- Various code cleanups and extentions to the mime.[ch] files to
		deal with new advances in Xamime (http://xamime.com)

Fri Nov 09 2001 pldaniels@pldaniels.com
	- Replaced several sprintf()'s with snprintf
	- Set a global _MIME_STRLEN_MAX length to 1023 and used
	 	with snprintf() to avoid buffer-overflows as reported by
		Tristan Aston (Solaris 8).
	-
Mon Nov 05 2001 pldaniels@pldaniels.com
	- Resolved TNEF segfault issue with some winmail.dat packs which do
		not seem to conform to the standard which we have for the current
		tnef decoding module.  Some winmail.dat packs still dont unpack
		but that's an issue with the MAPI data I believe (anyone want to
		help?)
	- Added "RAW" format for encoding, RAW basically is a slower form of
		read/decode, but, it will at least correctly (??) save non-format
		specified files.  RAW decoding routines are kept in rawget.[ch]
		which is nothing more than a specific version of fgets().  This may
		change later [back to fgets()].  The difference is that rawget
		returns how many bytes it read, because the data returned by a
		binary file may contain \0's which would otherwise fool length
		testing function calls (ie, strlen()) into indicating there are
		less bytes than what there really is.  This could be resolved by
		performing a test for the \n or \r, but it's more overhead.
	- Added patch from Xerox to correct occasional issue with non
		constant BASE64 line lengths (previously used to determine when
		the encoding had finished)

Fri Oct 26 2001 pldaniels@pldaniels.com
	- 1.2.5 released
	- Removed mailbox "\n\rFrom " line detection routines out of text
		decoding section, created new function MIME_unpackmailbox()
		which will break apart the mailbox email at at time and feed it
		to MIME_unpack()
	- [mime.c, tnef.h, tnef.c ] Fixed issue with TNEF decoding segfaulting
		if -d param was used in ripMIME
	- [config.h] Cleaned up the __BYTE_ORDER mangling issue by renaming
		as __TNEF_BYTE_ORDER
	- Added numerous debugging messages available by using --debug on
		ripMIME
	- [tnef.c] Removed extensive deadcode from tnef modules
	- [tnef.c] Removed compressed RTF decoding
	- Improved error reporting and messages

Thu Oct 18 2001 pldaniels@pldaniels.com
	- 1.2.4 released
	- Added TNEF decoding ability through use of modified tnef2txt
  		library as created by Brandon Long (blong@uiuc.edu), April 1997.
		As yet, I have not been able to successfully contact this person.


Tue Oct 09 2001 pldaniels@pldaniels.com
	- Updated MIME Boundary stack "cmp" operation so that it pops off
		any boundaries -above- the detected one.  This is because
		technically, all boundaries should be nested in their occurances.
		This is a hoped fix for most of the .eml attachment extraction
		problems that were occuring.

Tue Sep 11 2001 pldaniels@pldaniels.com
	- Cleaned up source and added in more comments
	- Released v1.2.3

Mon Sep 10 2001 pldaniels@pldaniels.com
	- changed the detection string for quoted-printable from
		"quote-printable" to "quoted-printable".  A small, but oh so
		painful mistake!
	- changed boundary line detection in header files to improve the
		detection and extraction of multiply-nested mailpacks

Sun Sep 9 2001 pldaniels@pldaniels.com
	- Improved name= parameter discrimination when headers have mixed in
		<META ... name="..."> components.  Now correctly decodes name= when
		the headers have a <ID 23523535255> type identifier.
	- Changed XAM_strncasecmp and strlower to use inline/macro version of
		isupper / tolower

Wed Aug 29 2001 pldaniels@pldaniels.com
	- Added ability for ripMIME to uncompress BASE64 encoded inline
		mailpacks (these are like forwarded emails, but they've been
		coded up in BASE64 format! I kid you not!)

	- Added Handling for Quote-Printable filenames

Fri Aug 24 2001 pldaniels@pldaniels.com
	- Added recursive calling if mailpack contained encoded mailpack
		ie, when we get a named rfc822/message type attachment.

	- Inserting new code from MIME_headers.[ch] which will do explicit
		analysis of the headers in a single-line stream format. Makes
		things far far easier to deal with later.

Tue Aug 21 2001 pldaniels@pldaniels.com
	- mime.c: added explicit handling of mailbox format (/var/spool/mail)

Fri Aug 03 2001 pldaniels@pldaniels.com
	- mime.c: added --no_paranoid option for filename filtering

Wed Aug 01 2001 pldaniels@pldaniels.com
	- mime.c: MIME_test_uniquename(): used strrchr rather than XAM_strtok()
		to locate the last '.' seperator for filenames. Fixes problem with
		misnaming of multiple .'d filenames.

Tue Jul 31 2001 pldaniels@pldaniels.com
	- XAM_strtok.c: Corrected end-of-tokens bug in XAM_strtok(), would
		return a null string when it should return the remainder of the
		string.
	- mime.c: added additional method for renaming of file
			--prefix
			--infix
			--postfix
	- mime.c: added "--unique_name" function to preserve existing filenames
		when decoding (ie, no clobbering)

Tue Jun 12 2001 pldaniels@pldaniels.com
	- mime.c: replaced strncasecmp() with XAM_strncasecmp() to permit
	portability to sysV and others
	- mime.c: replaced random() call with rand()
	- Added early exit routine for base64 if it detects two consecutive
	hyphens ('-'), this is needed in order to deal with 1-in-1000
	situation where a small file is encoded, and there is no separating
	double CR\LF between the end of the base64 encoding, and the new
	boundary line.


Sun Jun 03 2001 pldaniels@pldaniels.com
	-Release as 1.0.2
	- Fixed occasional issue of a second attachment decoding to 57 bytes
		in a BASE64 decode, added extra test routine for the length
		comparisons so that a length of 0 could not be accepted.
		MIME_decode_64:
				else if (p_length == -1) {
++					if (t_length > 0) p_length = t_length;
				}

	- Replaced strtok() calls with own XAM_strtok() from the XaMime project
		NOTE- This strtok call DOES NOT compress consecutive delimeters like
		strtok. The behaviour of XAM_strtok() is more like that of strsep().

		The replacement was required to ensure thread-safety, as strtok() is
		far from being thread-safe (it's bad enough when you 'accidently'
		nest strtok() calls!. XAM_strtok() can be safely nested.


Mon May 21 2001 pldaniels@pldaniels.com
	- Fixed issue of ripMIME not successfully extracting a RFC822
		"embedded" pack if it started with "From" or ">From"

Mon May 14 2001 pldaniels@pldaniels.com
	- Replaced fgetc() calls in BASE64 decoding routine with a set of
		routines as defined in the new module ffget.[ch].  These new
		routines read in the MIME encoded file line at a time using
		fgets() and then feed out the file char at a time using the call
		FFGET_fgetc(). Speed improvement is nearly DOUBLE thanks to this
		routine (the more BASE64 decodes you do the better.

Mon Apr 02 20:54:45 EST 2001 pldaniels <pldaniels@pldaniels.com>
	- Added new var, _no_nameless[= 0].  If set to something other than
		zero, then any attachments without an internally specified filename
		will be removed (After processing)
	- Added CLI param to turn on no_nameless.

Wed Mar 28 14:26:06 EST 2001 pldaniels <pldaniels@pldaniels.com>
	- Added patch for filename cleaning. Fixed patch to not overwrite '.'s
	- Put MIME_clean_MIME_filename() into action, hopefully ISO filenames
		should be supported without kludgy characters now.

Tue Mar 27 21:39:24 EST 2001 pldaniels <pldaniels@pldaniels.com>
	- Added MIME_get_attachment_count() which returns how many filename'd
		attachments were found.
	- Added in _current_line for the purpose of debugging, good for being
		able to tell where ripMIME is through the reading of a mailpack
	- Added "default" encoding method as being PLAINTEXT in the event
		that there is no encoding format handled specifically (Thanks to
		Hans Arder for supplying mailpack to display this)

Tue Mar 21 <pldaniels@pldaniels.com>
	-PR5
	-a debugging line in the collect_headers fn was causing potential
		encoding-format loss due to absorbing the vital Content-Type
		line.

Fri Mar 16 <pldaniels@pldaniels.com>
	-Prerelease 4
	-Implemented a stack based boundary layer detection system to
		allow for nested in-line attachments, as typically generated
		by drag'n'dropping files to email
	-ISO filename decoding commenced, needing more examples of mailpacks
		with ISO encoded filenames!
	-Created the "daily update" version of ripMIME, to follow suit with
		the new Inflex style of releases.


Tue Feb 13 <pldaniels@pldaniels.com>
	-Prerelease 3
	-Fixed up some quote-printable glitches (pack supplied by
		James Cownie, thanks!)

Tue Jan 30 00:49:51 EST 2001 worker <worker@inflex>
	-Prerelease 2
	-Removed tmpnam() call out of MIME_XHeader() function, not that this
		 is actually ever used by ripMIME (its part of the cInflex suite)
		 thanks to both Dave DeMaagd and Justin (SuidAfrika) for pointing
		 this out to me.
	- Corrected directory naming spec so that there aren't double //'s
		(Thanks to James Cownie for preliminary notification)

	-Changed the 'From' line detection routine to work with both un-read
		(ones with just 'From joe@xxx.bbbb') as well as READ emails (ones
		with '>From joe@xxx.bbbb'). Thanks to Sven for pointing this out
		(Im too used to using pop3-pickup ;) Also allowed the FROM line to
		be detected in the MIME_find_next_header() function.

Sun Jan 28 15:10:49 EST 2001 worker <worker@inflex>
	-v1.0.0 PreRelease 1
	-Added in multiple-email (sequential) and nested (forwarded) email
		attachment extraction support (painful!)
	-Passed ripMIME through several thousand "real life" emails to
		verify extraction ability
	-Modified flag passing structures to contain most in struct _MIME_info
		(required to get nested emails to extract correctly)
	-Allowed user to turn on/off each logging option (syslog or stderr)
	-Tried cleaning up comments a bit
	-Added in more _debug() calls, making watching the process of decoding
		via syslog() a bit easier.

Fri Jan 12 11:00:12 EST 2001 worker <worker@inflex>
	- Added patch supplied by Rolf to also counter for boundary specifiers which dont' have
	enclosing "'s

Tue Jan 09 13:38:16 EST 2001 worker <worker@inflex> (0.1.10)
	-Added ability to handle mailpacks which had no CR/LF separator after the end of BASE64
	decoding (Thanks to Hans Harder for suppling the mailpack!)

Sun Jan 07 00:02:19 EST 2001 worker <worker@inflex> (0.1.9)
	- Removed error reporting code from mime.c which said that end-of-file had been reached,
	this is no longer required as we correctly handle plain-text (into the _headers_ file)
	-Considering to release as v1.0.0

Sat Dec 30 23:47:18 SAST 2000 worker <worker@inflex> (0.1.8)
	- Added print-quotable decoder
	- release 0.1.9

Thu Dec 28 22:13:56 SAST 2000 worker <worker@inflex>
	- Handler for mailpacks WITHOUT a boundary specified (single file emails)
	- Forgot to change the version indicator in 0.1.7

Sun Dec 24 23:32:09 SAST 2000 worker <worker@inflex>
	- Modify base64 decoder to allow a _MAXIMUM_ of 76 chars on the line.
	  and capable of any length of line less than 76 chars.
	 - Release 0.1.7

Fri Dec 22 23:02:57 SAST 2000 worker <worker@inflex>
	Commenced fixing ripMIME for new style of MIME headers which have multiple
	statements on a single line.

Sat Nov 25 17:45:45 SAST 2000 worker <worker@inflex>
	version 0.1.6
		-Applied patch from Matthew to allow input from STDIN
		-Added feature to allow headers to be dumped to a file (for picking up
			kak virus etc)
		-Added more comments to source code

Thu Nov 23 18:30:20 SAST 2000 worker <worker@inflex>
	version 0.1.5
		-Corrected EOL detection for 76 char MIME encodings

Thu Nov 23 18:30:20 SAST 2000 worker <worker@inflex>
	version 0.1.4
		-Corrected End of encoding MIME breakage
		-Added better -DDEBUG reporting via syslog()

Mon Oct 30 09:45:04 SAST 2000 worker <worker@inflex>
	version 0.1.3
		-Added input parameters to allow for more control
		-Added ability to specify own text-only filename prefix

Mon Oct 30 00:46:05 SAST 2000 worker <worker@inflex>
	version 0.1.2
		-Added code to remove zero byte files.

Sun Oct 29 18:16:46 SAST 2000 worker <worker@inflex>
	version 0.1.1 released.
