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.
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} {
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
Logged In: YES
user_id=240
Deleting file that isn't the right spam...
Logged In: YES
user_id=240
Uploading a spam file that triggers the bug.
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)
Logged In: YES
user_id=24077
yes, we should remove the '#' character to get the original
behavior.
Logged In: YES
user_id=75003
Made the change, and committed to head.
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=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=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
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.
This bug is open more than ten years. It need sto be revalidated and either fixed or wontfixed. Poking the priority to fraw attention.