> But ripMIME (as well being a MIME-aware tool) should
> *not* extract that, as it is not a valid message part
> (it's more like a graffity :) ), and then all would
> work well.
Ah, but ripMIME -should- extract it, because it is a part of what email clients do/will see. You see, ripMIME is more than just an 'extraction' tool, it's a tool which is used to break down emails as other email clients will see them. Lets take a hypothetical situation -
Lets say an email client, JoesMTA-2003 has an exploit which comes in via this 'blank space' zone where everyone puts "This is a MIME encoded email", instead of putting that, they use some form of fancy VB string to make Outlook do their bidding. Now, if ripMIME conformed 'strictly' to the standards then this exploit would not be able to be searched for because ripMIME wouldn't be extracting the file.
There are a few things in ripMIME which are extracted outside of the 'strict conformance' of the RFC's, ie:
- UUENCODED attachments within the main text body
- LF-LF delimeted MIME bodies
- and of course this 'blank space' zone data
Perhaps, a simple method of getting around this is to check the _headers_ file to see if there's a boundary specification contained within it (ie, grep "boundary=" _headers_ ) and if so, then start your textfile filtering from textfile1, else start from textfile2.
There are other possible solutions:
1. Single textfile output containing full catencation of all textfile outputs
2. output the 'blank space' zone text to a seperate file, ie, 'blankzone'
Ultimately, forcing ripMIME to -not- extract parts/aspects of a mailpack is against the focus of ripMIME.
I hope that this helps out a bit... let me know
Kind Regards.
--
Paul L Daniels http://www.pldaniels.com
Linux/Unix systems Internet Development
ICQ#103642862,AOL:cinflex,IRC:inflex
A.B.N. 19 500 721 806
> *not* extract that, as it is not a valid message part
> (it's more like a graffity :) ), and then all would
> work well.
Ah, but ripMIME -should- extract it, because it is a part of what email clients do/will see. You see, ripMIME is more than just an 'extraction' tool, it's a tool which is used to break down emails as other email clients will see them. Lets take a hypothetical situation -
Lets say an email client, JoesMTA-2003 has an exploit which comes in via this 'blank space' zone where everyone puts "This is a MIME encoded email", instead of putting that, they use some form of fancy VB string to make Outlook do their bidding. Now, if ripMIME conformed 'strictly' to the standards then this exploit would not be able to be searched for because ripMIME wouldn't be extracting the file.
There are a few things in ripMIME which are extracted outside of the 'strict conformance' of the RFC's, ie:
- UUENCODED attachments within the main text body
- LF-LF delimeted MIME bodies
- and of course this 'blank space' zone data
Perhaps, a simple method of getting around this is to check the _headers_ file to see if there's a boundary specification contained within it (ie, grep "boundary=" _headers_ ) and if so, then start your textfile filtering from textfile1, else start from textfile2.
There are other possible solutions:
1. Single textfile output containing full catencation of all textfile outputs
2. output the 'blank space' zone text to a seperate file, ie, 'blankzone'
Ultimately, forcing ripMIME to -not- extract parts/aspects of a mailpack is against the focus of ripMIME.
I hope that this helps out a bit... let me know
Kind Regards.
--
Paul L Daniels http://www.pldaniels.com
Linux/Unix systems Internet Development
ICQ#103642862,AOL:cinflex,IRC:inflex
A.B.N. 19 500 721 806