On 2002-09-09 09:42:21 -0700, Michael Elkins wrote: >Thanks for the extra info. I looked into this more closely, and I >see that there are a couple of factors that come into play into >this situation. First, I noticed that your PDF attachment was >labeled improperly as "text/plain". This is not so bad in itself, >but that piece of code that checks for which transfer encoding to >use assumes that it really is text, which is a problem. Since >there was no extension to the file, Mutt fell back into making a >guess as to whether or not the file was of type text/plain or >appliation/octet-stream. Mutt guessed text/plain because it saw >only a few lobins in the file. However, Mutt failed to notice that >there were bare CRs in the file when choosing the transfer >encoding. The attach patch checks info->binary even for the >text/plain case. I just tested this and it correctly chose base64 >encoding for the file.
While the problem clearly lies with mutt mis-treating the PDF file as text, I'm not entirely sure that just changing content-transfer-encodings is the right kind of fix... This may also be a problem with either the old MIME encoder (which is what I tend to believe), or it may come from the special-casing text mode has to do for CR-LF sequences (i.e., line ends), regardless of the content transfer encoding. If it's the latter, there's ultimately nothing we can do about this - apart of not using text mode to transfer binary files. In order to test things, I saved the quoted-printable version of the file to my hard disk, and then sent it to myself using mutt-1.4 and 1.5 (as text/plain, with quoted-printable encoding), and then saved the file. The new file was identical to the old one, down to the byte. Can you guys reproduce this? Or was I already using a mis-treated version of the file as my test case? (MD5 checksum: 57631c6d362944c179c24cbe1512ce2e) -- Thomas Roessler <[EMAIL PROTECTED]>
