[imp] Attachment corruption problem

[Michael M Slusarz]

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:
>
> Array
> (
>     [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

___________________________________
Michael Slusarz [slusarz at horde.org]