[imp] Mac attachment testing report

[Michael M Slusarz]

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:

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

     * 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.

     * 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.

     * 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.

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.

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.

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 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.

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder