Hi,
I have another problem with a msg that just came in.
Some idiot sent a huge email, and amongst the half-dozen
attachments, was a video. Unfortunately, this attachment
was corrupted, so that the headers were elsewhere, resulting
in the attachment looking like this:
------=____1102359685177_mjnrnPN17R
CMCaydY5mzxGm2QCqAGLObOMCAAAAAAAABgAAAAECodyrjEepzxGO5ADADCBTZWgAAAAAAAAA
ki82QAAAxkEAABZ+QzAAAMEhIgAAAAAAAMeRDcpDlQB4AAAAAAAAABCuqhQAAAAAkOrgEgAA
AAC4CwAAAAAAAAIAAADISAAAyEgAAIC+FgCRB9y3t6nPEY7mAMAMIFNlcgAAAAAAAABAnmn4
TVvPEaj9AIBfXEQrUM3Dv49hzxGLsgCqALTiIAAAAAAAAAAAHAAAAAgAAAABAAAAAABhAQIA
gD4AANAHAACAAhAACgAAJAAADgCAAgAAAYACgAIBAACRB9y3t6nPEY7mAMAMIFNlgQAAAAAA
AADA7xm8TVvPEaj9AIBfXEQrAFf7IFVbzxGo/QCAX1xEKwAAAAAAAAAAMwAAAAAAAAACAAAA
AABAAQAA8AAAAAIoACgAAABAAQAA8AAAAAEAGABXTVYxAIQDAAAAAAAAAAAAAAAAAAAAAAC1
and so on, and so on. The problem is that when ripmime gets to
MIMEH_read_headers(), it keeps reading lines in and reallocing
space for it. So when MIMEH_are_headers_RFC822() is called, it
tries to do the strstr() looking for the headers on a *3 Meg* buffer.
Needless to say this takes a very long time, chewing up CPU. I have
code to check for hung processes, and it kills it after using 2 minutes
of CPU time.
Can the loop in MIMEH_read_headers() be modified to not add any
more text after a certain point? Shouldn't you be able to find
any headers in the first however-many KB, and fail if you don't?
I realize corrupted messages don't happen very often, but we still
need to deal with it gracefully when it does.
Brian Bebeau
Mycom Group, Inc.
bbebeau@mycom.com
----------------------------------------------------------------------------------------------
This message has been scanned by mycomPRO mailMAX II.
For further information, visit http://www.mycompro.com
_______________________________________________
Ripmime-general mailing list
Ripmime-general@pldaniels.com
http://www.pldaniels.com/mailman/listinfo/ripmime-general
I have another problem with a msg that just came in.
Some idiot sent a huge email, and amongst the half-dozen
attachments, was a video. Unfortunately, this attachment
was corrupted, so that the headers were elsewhere, resulting
in the attachment looking like this:
------=____1102359685177_mjnrnPN17R
CMCaydY5mzxGm2QCqAGLObOMCAAAAAAAABgAAAAECodyrjEepzxGO5ADADCBTZWgAAAAAAAAA
ki82QAAAxkEAABZ+QzAAAMEhIgAAAAAAAMeRDcpDlQB4AAAAAAAAABCuqhQAAAAAkOrgEgAA
AAC4CwAAAAAAAAIAAADISAAAyEgAAIC+FgCRB9y3t6nPEY7mAMAMIFNlcgAAAAAAAABAnmn4
TVvPEaj9AIBfXEQrUM3Dv49hzxGLsgCqALTiIAAAAAAAAAAAHAAAAAgAAAABAAAAAABhAQIA
gD4AANAHAACAAhAACgAAJAAADgCAAgAAAYACgAIBAACRB9y3t6nPEY7mAMAMIFNlgQAAAAAA
AADA7xm8TVvPEaj9AIBfXEQrAFf7IFVbzxGo/QCAX1xEKwAAAAAAAAAAMwAAAAAAAAACAAAA
AABAAQAA8AAAAAIoACgAAABAAQAA8AAAAAEAGABXTVYxAIQDAAAAAAAAAAAAAAAAAAAAAAC1
and so on, and so on. The problem is that when ripmime gets to
MIMEH_read_headers(), it keeps reading lines in and reallocing
space for it. So when MIMEH_are_headers_RFC822() is called, it
tries to do the strstr() looking for the headers on a *3 Meg* buffer.
Needless to say this takes a very long time, chewing up CPU. I have
code to check for hung processes, and it kills it after using 2 minutes
of CPU time.
Can the loop in MIMEH_read_headers() be modified to not add any
more text after a certain point? Shouldn't you be able to find
any headers in the first however-many KB, and fail if you don't?
I realize corrupted messages don't happen very often, but we still
need to deal with it gracefully when it does.
Brian Bebeau
Mycom Group, Inc.
bbebeau@mycom.com
----------------------------------------------------------------------------------------------
This message has been scanned by mycomPRO mailMAX II.
For further information, visit http://www.mycompro.com
_______________________________________________
Ripmime-general mailing list
Ripmime-general@pldaniels.com
http://www.pldaniels.com/mailman/listinfo/ripmime-general