Tickets :: Comment on [#3565] Attachment modification (newline structure changes)

* Your Email Address
* Spam protection	Enter the letters below: . ..__ . .. ,.__ \| \|[ __\| \| \./ [__) \|__\|[_./\|/\\| \| \|
Comment	>> I finally had time to do a little bit research about the problem. > >> There are two parts about this. > >> > >> 1. If user has't for example Office application installed and tries > >> to send document attachment it gets sent as text/plain. This is > >> normal because browser doesn't know file type and sends > >> application/octet-stream. IE6, IE7, FF1.5 and FF2 behaves exactly > >> this way. Only Opera 9.1 has builtin MIME detection for my tested > >> Word Document Type. This means that you can't rely on user client/OS. > > > > This is an incorrect statement. I don't have office on my computer, > and FF and IE attach .doc files as application/octet-stream (exactly > like it is supposed to). > > > >> 2. If you can't rely on user client/OS configuration then it means > >> that your server must be presicly configured to give Horde the right > >> mime type. > > > > As mentioned above, this is incorrect. > > > >> Even with > >> fileinfo PECL module installed they still reported text/plain. And > >> with only some hacking through config files I found this -> > >> http://mail-archives.apache.org/mod_mbox/httpd-cvs/199807.mbox/%3C19980718113554.10097.qmail@hyperreal.org%3E Seems like most of the office documents was dissabled by default in vanilla apache since 1998! This means that very large base of UNIX type OS'es that uses vanilla apache is affected by the problem most >> probably > >> too. > >> > >> Now back to the point. I know that it is faster to send plain text > >> attachments and plain text, and wiser used space way, and I agree > >> with you that having possibility to read those attachments in console > >> programs is good. BUT, for the sake of large user base without office > >> installed and for the sake of large admin base with vanilla apache > >> configuration, PLEASE revert IMP to encode all text/plain attachments > >> with base64 again > > > > This has already been discussed in this ticket (and elsewhere) ad > nauseum. Your requested changes are not going to happen. We may > consider patch implementing a configuration option, or a patch > allowing MIME magic tests to be skipped, but we will always send > messages by default in the least altered format possible, especially > when we are EXPLICITLY TOLD the data is text.
Attachment
Watch this ticket

Saved Queries