[imp] Mac attachment testing report

[Joe Kletch]

On Mar 3, 2004, at 11:19 AM, Michael M Slusarz wrote:

> Quoting Joe Kletch <joe at kletch.com>:
>
>> Hey all,
>>
>> I setup a number of webmail clients, including IMP, and a test 
>> protocol
>> to test their ability to handle Mac files that are not BinHexed or
>> Stuufed.  My client gave me a tall order to find a webmail client that
>> could handle these diverse requirements and none were able to.
>>
>> If your interested the report is located here:
>>
>> http://webmail.burtonmayer.com/report.html
>>
>> At this point I am not too optimistic that anyone will work on this as
>> even Apple is moving away from their old file format.  Any comments 
>> and
>> suggestions will be appreciated.
>
> Ummm.... I would really like to see these messages, because all the 
> encoding
> formats you have listed are handled by Horde (following the specific 
> RFCs).
>
> Additionally, it would be great if you could explain in your boxes 
> _what_ is
> incorrectly being displayed.  I notice that if *any* of the following 
> "fail",
> you put a "No" down with no explanation:

I'll expand the test data to detail each item being tested for my next 
set of tests. You have access to the messages now.

>
>     * Ability to download the attachment.
>     IMP provides a download link to _every_ attachment, so obviously 
> this can
>     not be where the tests are failing.

Correct.

>
>     * The file name is correct.
>     I have not found a message that does not have its filename 
> correctly
>     displayed on the screen.  Now, if you are talking about what the 
> *browser*
>     is trying to save the attachment as (in the Save As dialog box), 
> you are
>     talking about a whole other
>     topic, namely broken browsers, not broken webmail applications.  I 
> assume
>     that Mail.app is a local mail application on Macs - if so, this is
>     somewhat of an unfair comparison you are making.  I should surely 
> hope that
>     a native Mac application can correctly save messages on the local 
> system.
>     But when you are working with cross-platform browsers, it is much 
> more
>     difficult to try to
>     predict what any one kind of browser will do.  We have workarounds 
> for many
>     broken browsers, but without you telling us what browser you are 
> using for
>     these tests or if this is whatis failing, it is difficult to 
> understand
>     or fix what is wrong.

As clarified in another email--the browser I am testing with is Safari 
on OS X 10.3.2. The file names were always correct with IMP. On tests 
using Opera and Internet Explorer I had similar results, but chose to 
limit  to Safari.
>
>     * The icon for the file type was visible and correct.
>     Now this is *truly* an unfair comparison/test.  You are expecting 
> a webmail
>     application to understand ALL of your _local_ file type settings.  
> You
>     obviously are expecting way too much from a cross-platform 
> application.
>     We show icons
>     for the most common file types (i.e. images, compressed files), 
> but can't
>     be expected to show images for all possible file types.  Macintosh 
> Mail.app
>     will obviously win since it has access to a much larger database of
>     OS-specific file types/icons.  For example, we sure don't have an 
> icon
>     specific to Quark Express,since how often do people get a Quark 
> Express
>     attachment in the mail (obviously, if you are in some kind of 
> publishing
>     business, you will receive this much more often, but those people 
> are in
>     the minority).  I personally think that "failing" an application 
> because
>     it doesn't show the correct icon is an awfully weak test of webmail
>     performance.
>
Icon as it it appears once downloaded to the HD, which I believe is 
related to the resource form data being included/reintegrated in the 
download. With most files the icon shown on the local computer is 
designated by the files extension (OS X is moving this way now as 
well), but with old Mac files this data or metadata is in the resource 
fork.

When downloaded using IMP the data is OK but if the icon is missing 
that implies that the resource fork may not have been properly brought 
along and then what else may be missing from the resource fork that is 
important.


>     * Double clicking on the file opens the file correctly and in the 
> correct
> application.
>     If, after downloading a file, this test doesn't work, then your 
> message is
>     corrupt.  This has nothing to do with webmail viewing.  I have 
> never seen
>     IMP fail on this kind of test unless the data is corrupt - IMP is 
> simply
>     sending the data it sees in the message.

Same message opened with Mail.app and double clicking the file opens it 
in the right application, with IMP the file can be opened but only by 
the 'Fiile Open' menu in the application.  Again I agree it may not be 
a fair test--but I am tasked to see if can work.

I'd like to better understand how IMP is recombining the resource and 
data fork with Mac attachments.

>
> Notes about specific encoding formats:
>
> appledouble:
> I am looking at an appledouble message in IMP right now.  Horde/IMP 
> supports
> multipart/appledouble messages just fine as long as they are in RFC 
> 1740
> format.

I am beginning to think is the one encoding format I need to focus on.  
I'll take a look at this RFC, see it if the client I used to send 
Outlook Express meets it and if not runs some tests with one that does. 
  Even trying to send the attachment from IMP on the OS 9 machine.

>
> MIME/Base64:
> This is the most common method of sending e-mail attachments, so IMP 
> has
> supported this encoding since the very beginning.  So obviously, it is
> something else causing this test to "fail" on your system but without 
> further
> details, it is difficult to comment any more.

The file does download with the correct name and it can be opened from 
within the application. But the icon as discussed above is not there.

>
> UUencode:
> IMP works just fine with UUencode data - make sure that this line 
> appears in
> imp/config/mime_drivers.php:
> $mime_drivers['imp']['plain']['uuencode'] = true;
It was 'false' I changed it to 'true' and tried again. The file did not 
download but only opened the raw ascii iin the IMP window.  I believe 
you pointed out elsewhere that this file looked corrupt, so I can chalk 
that up to the client not doing the encoding correctly.  The data that 
is shown when clinking on the IMP download link:
"begin 644 2 x 2 Golf Ad B-W.eps
M)2%04RU!9&]B92TS+C$@15!31BTS+C`-..... and on and on..."


>
> It would be great to help you out, but I am a bit doubtful that IMP 
> truly does
> "fail" in all of your tests, or that you are expecting too much from a
> cross-platform, centralized email system.  As mentioned above, if you 
> could
> give further details as to why each test failed, that would help a 
> bunch.
>

Let me know if you need more.

Joe Kletch