Many thanks for solving this problem.

This bug is fixed.  (Sort of forgot that null characters WERE valid 
characters allowed in RFC 822 - at least in a quoted string - but were 
removed in RFC 2822.  So I should go and fix that up also.).

All of this should be in Horde_Mime 2.1.0.

Changes have been made in Git (master):

commit da81a37bbd0c14338746efcafc5d3670d27e80ef
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed Mar 27 20:43:21 2013 -0600

     [mms] More accurate/comprehensive Horde_Mime::is8bit() check (Bug #12127).

  framework/Mime/lib/Horde/Mime.php |   25 +++++++------------------
  framework/Mime/package.xml        |    2 ++
  2 files changed, 9 insertions(+), 18 deletions(-)

http://git.horde.org/horde-git/-/commit/da81a37bbd0c14338746efcafc5d3670d27e80ef

Changes have been made in Git (master):

commit 537347aa29977d7337d8afbe597f663d70277a30
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed Mar 27 19:54:26 2013 -0600

     [mms] Need to always add charset information to MIME encoded 
parameters if they are not displayable in pure US-ASCII (Bug #12127).

  framework/Mime/lib/Horde/Mime.php           |   10 ++++++----
  framework/Mime/package.xml                  |    1 +
  framework/Mime/test/Horde/Mime/MimeTest.php |   19 +++++++++++++++++++
  3 files changed, 26 insertions(+), 4 deletions(-)

http://git.horde.org/horde-git/-/commit/537347aa29977d7337d8afbe597f663d70277a30

Changes have been made in Git (master):

commit 50f1505733f3455acd897142186abe5f8f84788d
Author: Michael M Slusarz <slusarz@horde.org>
Date:   Wed Mar 27 19:52:57 2013 -0600

     [mms] Correctly quote forbidden characters in MIME parameter data 
(Bug #12127).

  framework/Mime/doc/Horde/Mime/UPGRADING     |   11 ++++++++++
  framework/Mime/lib/Horde/Mime.php           |   29 +++++++++++++++++---------
  framework/Mime/package.xml                  |   11 ++++++---
  framework/Mime/test/Horde/Mime/MimeTest.php |    8 +++++++
  4 files changed, 45 insertions(+), 14 deletions(-)

http://git.horde.org/horde-git/-/commit/50f1505733f3455acd897142186abe5f8f84788d

OK... starting to make sense.  We encode MIME parameters in the header 
to the same charset as the text body.  So that's why the null 
characters are in the header.

But MIME encoding should embed the the charset in these headers.  So 
there is something wrong with that.

Here's one UTF-16LE text file with a BOM, gzipped for safety. We 
appreciate your help. Thanks.

But this is still potentially an issue similar to what I described.   
For example: the browser may send UTF-16 as the charset, but the PHP 
conversion methods mishandle it since that is NOT the charset that the 
text really is.  And/or the fact that PHP string conversion methods 
are known to be buggy with UTF16LE (i.e. iconv() on certain systems).

At a minimum, I need an example file that triggers this behavior.   
Might want to zip/tgz before adding to the ticket to prevent the data 
from being munged.

Many thanks Michael for your prompt response, but unfortunately the 
reply misses the main point of the original bug report. Horde/IMP 
wrongly encodes the metadata about the UTF16-LE encoded text file 
attachment, i.e. the MIME headers describing the attachment then 
contain UTF16-LE. Those headers should never ever contain NUL bytes 
nor 8-bit data of any kind. That is the key problem. (This bug is not 
about the difficulties detecting the correct charset).

IIRC, this is a known limitation with uploading text data in browsers. 
  Browsers rarely (if ever?) insert charset information into the 
Content-Type of the uploaded file.  So we pretty much have to assume 
that the file being uploaded is the same charset as the browser (which 
is assumed to be the same charset the underlying OS is using).

See, e.g., 
http://stackoverflow.com/questions/6459741/how-to-determine-if-uploaded-file-is-in-utf-8-or-utf-16

BOM's could potentially be used to fix this some of the time.  But 
there's no guarantee they will exist, or won't be stripped/munged by 
some intermediate process.

Hi! If I try to send a utf-16 (little endian with the tag byte 
sequence FF FE at the beginning) encoded text file as an attachment 
and I've enabled saving attachments to the Sent folder with the 
message, IMP creates a very strange header for the MIME part of the 
attachment: all the values of the header keywords end up encoded as 
utf-16 (except that the Content-Transfer-Encoding loses the final NUL 
byte). Like this:

--clip--
--=_pRVOz2N9C9oTNFcAA1MfBg1
Content-Type: text/plain; charset=u^@t^@f^@-^@1^@6^@l^@e^@;
  name=m^@a^@a^@l^@a^@m^@p^@o^@1^@b^@.^@t^@x^@t
Content-Disposition: attachment; 
filename=m^@a^@a^@l^@a^@m^@p^@o^@1^@b^@.^@t^@x^@t^@;
  size=146736
Content-Transfer-Encoding: q^@u^@o^@t^@e^@d^@-^@p^@r^@i^@n^@t^@a^@b^@l^@e
--clip--

here, ^@ stands for the null byte. The MIME part headers should be 
7bit clean, and at least Sendmail apparently converts this to ASCII 
while sending, so the receiver gets the message as they should, but 
the IMAP backends do various things for the saved attachment. Cyrus, 
for instance, complains that the message contains NUL bytes and 
doesn't save it at all to the Sent folder - except for a buggy version 
I happen to be running...