Tk Library Source Code

The while {$moreP} loop in mime::parsepart will loop
forever when fed bad data such as the file attached,
which is a spam email.  I'm sure it's formatted badly,
but that should cause an error, not an infinite loop.

This bug is open more than ten years. It need sto be revalidated and either fixed or wontfixed. Poking the priority to fraw attention.

Logged In: YES 
user_id=240

I committed two of the spammy email messages as well as two
new test cases to CVS, in order to have something to test
this problem against.

Logged In: YES 
user_id=24077

well, the "official practice" when encountering bad mime
data is to wrap the thing inside an application/octet-stream
and declare victory. experience shows that any other
recovery strategy just doesn't work.

perhaps the thing to do here is to keep the "error ..." and
put a wrapper around the proc that creates an
application/octet-stream bodypart.

/mtr

Logged In: YES 
user_id=240

Reopening because the fix in CVS doesn't seem optimal.

Further thoughts:

1) Mime should try and parse even bad data, by default, on the
   principal of "be liberal with what you accept".

2) Maybe we should have an option to tell it to be strict,
in which
   case it errors out on bad data?

Logged In: YES 
user_id=191529

Here's my patch to mime.tcl, which seems to handle things
better than davidw's patch:

--- mime.tcl.orig       2003-06-11 22:22:18.000000000 +0200
+++ mime.tcl    2003-06-11 22:24:56.000000000 +0200
@@ -682,10 +682,11 @@

     set inP 0
     set moreP 1
+    set retries 0
     while {$moreP} {
         if {$fileP} {
             if {$pos > $last} {
-        #        error "termination string missing in
$state(content)"
+                if {[incr retries]>50} {error "termination
string missing in $state(content)"}
                  set line "--$boundary--"
             } else {
               if {[set x [gets $state(fd) line]] < 0} {

Logged In: YES 
user_id=75003

Made the change, and committed to head.

Logged In: YES 
user_id=24077

yes, we should remove the '#' character to get the original
behavior.

Logged In: YES 
user_id=282725

this properly errors out if you remove the # comment from
the line
error "termination string missing ..." (in mime 1.3.2)

File Added - 44163: 14167

Logged In: YES 
user_id=240

Uploading a spam file that triggers the bug.

File Deleted - 34302: 

Logged In: YES 
user_id=240

Deleting file that isn't the right spam...

File Added - 34309: latest.diff

Logged In: YES 
user_id=240

The attached patch seems to make the problem go away, but I
don't know if it really fixes it.  It still passes all the
tests.

File Added - 34302: 10776