On Mon, Sep 09, 2002 at 09:42:21AM -0700, Michael Elkins wrote: > Brian Grayson wrote: > > I downloaded 1.4 on Friday just to see, and the same problem > > occurs. The fundamental problem is once the CTE code sees a > > nonzero value of lobin, it goes into quoted, regardless of > > whether hibin is nonzero. The following patch does the right > > thing for my testcase here, but I don't know if there's a good > > reason why the lobin/quotable check currently ignores whether > > there are any hibins or not. > > > > After a bit of inspection, the file rep.5k has hibins and > > _no_ lobins, and hence goes properly into 8bit encoding. But > > the file rep1k has a lobin (0x0b at offset 0x340, for example), > > so it short-circuits into quoted-printable. Try mailing the > > base64-encoded version of that to yourself, and it should > > choose quotable, even in 1.4. > > 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.
Argggh! I found out the fundamental problem. It's not with the encoding type -- quoted-printable should be fine even in the presence of 8-bit characters (right?), except we have an Exchange server as our mail server. The Exchange mail server is apparently un-encoding the quoted-printable attachment, and then re-encoding it buggily. I visually verified this by telnet'ing to the SMTP port, and cut-and-pasting a MIME mail with a quoted-printable attachment. If I send that mail to \bgrayson, I get different results than if the mail goes through our Exchange server. So it appears to me that Exchange goes into the mail message and mucks around, and manages to also corrupt some mail while it's in there.... For example, I sent (and received from \bgrayson): %PDF-1.2=0D%=E2=E3=CF=D3=0D=0A317 0 obj=0D<< =0D/Linearized 1 =0D/O 319 =0D= /H [ 728 767 ] =0D/L 363450 =0D/E 62838 =0D/N 100 =0D/T 356991 =0D>> =0Dend= obj=0D xref=0D317 16 = When I let Exchange touch it, I end up with: %PDF-1.2=0D%=E2=E3=CF=D3 317 0 obj=0D<< =0D/Linearized 1 =0D/O 319 =0D/H [ 728 767 ] =0D/L = 363450 =0D/E 62838 =0D/N 100 =0D/T 356991 =0D>> =0Dendobj=0D = So, for a solution, is there an easy way for me to tell mutt, "Never use quoted-printable because the world unfortunately has Exchange servers"? Has anyone else seen this problem? Thanks. And sorry about the wild goose chase -- I didn't realize until now that quoted-printable should be able to handle arbitrary binaries without corruption (at least I _think_ it should be able to do so). (Microsoft just lost more respect from me. Which is amazing, since I didn't think there was any more to lose!) Brian
