CHANGES---------------------------------------------------------------
Mon Mar 17 2003
- PLD: Emergency release of 1.3.0.2
- PLD: Fixed major bug in the MIMEH_headers_read() call which would
cause the first line of the headers to be overwritten by following
lines ( in memory ) - Ultimate effect of this is that several files
would not be decoded because the vital file information would be
lost.
- PLD: Unified logging output across all modules
- PLD: Fixed space retention on header-wrapped filenames ( again
thanks to Kees Damen for providing a suitable mailpack )
Fri Mar 14 2003
- PLD: Fixed linewrap filename issues in headers ( thanks to Kees Damen
for pointing this issue out ).
- PLD: Fixed 0 length string issue with PLD_strncpy and replaced
existing algorithm with a more robust one as provide by 'Defrost'
- PLD: Rolled in unified pldstr module which replaces strlower,
XAM_strtok and zstr.
Sat Mar 01 2003
- PLD: Patched parameter parsing code to allow it to accept non-space
seperated parameters, ie, -d/tmp ( Patch supplied by Bernard Fischer )
Sat Feb 22 2003
- PLD: TNEF: Corrected pointer clobbering on 64-bit systems in TNEF decoding,
and added memory allocation free'ing. Both patches submitted by
Bernard Fischer and adapted by PLD
Thu Feb 19 2003
- PLD: Fixed content-type 'trailing' issue causing ripMIME to report
the previous content-type if the new attachment headers did
not contain a content-type. ( Mailpack contributed by Bernard Fischer )
Wed Feb 19 2003
- PLD: Converted command-line options to use hyphens '-' rather
than underscores '_' for word seperators. NOTE, the old
underscore seperators will still work but they are considered
depricated.
- PLD: Added multiple additional verbosity options:
--verbose-oldstyle : Output information in the format
used from the 1.2.x series of ripMIME
--verbose-contenttype : Output content-type information
of each file decoded ( Contributed by Thomas E Dell )
- PLD: Introduced a new verbose information format for file details.
The new format uses name=value pairings for the output, this
allows parsers to easially decode the output into useful data
if need be. An example of the output is now:
Decoding content-type=text/html filename=foobar.html
Currently only 'content-type' and 'filename' are reported but more
options will most likely be added in the future.
- PLD: Commenced v1.3-dev development.
Fri Feb 07 2003
- PLD: Released as 1.2.17.0 ( This is the last 1.2.x release, we
will now move to 1.3-dev and 1.4-stable releases
Thu Feb 06 2003
- 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 2003
- 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.
