[imp] Attachment corruption problem
Michael M Slusarz
slusarz at horde.org
Wed Apr 26 09:37:25 PDT 2006
Quoting "Daniel A. Ramaley" <daniel.ramaley at DRAKE.EDU>:
> I browse to form.html and upload the file that Imp corrupts. The output
> of form.php is:
> [userfile] => Array
> [name] => DU41.PAK
> [type] => application/octet-stream
> [tmp_name] => /var/tmp/phpu7O6Sb
> [error] => 0
> [size] => 16919
> -rw------- 1 apache apache 16919 Apr 26 10:39 /var/tmp/phpu7O6Sb
> aef5ca0e5d56df5dcaf3cf7fe5975d74 /var/tmp/phpu7O6Sb
> The file size in the ls listing, and the MD5 sum both match the original
> file. So i know the file can get to the server without corruption.
> Therefore Imp must be corrupting the file when it encodes it. I'm just
> trying to get Imp to correctly choose a binary encoding so the file
> won't be corrupted. Is there a way to do that?
Then the issue is in the MIME Magic detection. We really don't want
to send application/octet-stream data if at all possible because that
often times leads to the situation where the user doesn't know what to
do with the file. So we so a MIME magic analysis of the file to try
to "guess" what the file actually is (i.e. if the file is an
image/jpeg, if we correctly guess using MIME Magic, this will most
likely allow the message received to view the image in their mail
reader. if we send as application/octet-stream, they may only get an
opportunity to download the message since the remote mail program may
not be "smart" enough to figure out it is actually an image attached
to the message).
An option for us is to allow the user to select what MIME type to send
the message as if we do a MIME magic analysis. This will allow the
user to revert back to sending as application/octet-stream in the case
where mime magic analysis is incorrect.
Of course the most correct solution would be for someone to fix the
mime magic detection algorithim to correctly identify the file.
Michael Slusarz [slusarz at horde.org]
More information about the imp