Package: libcamel1.2-8 Version: 1.6.3-3 Severity: wishlist Tags: patch This is in no way a bug in Camel -- its behaviour is absolutely standard and normal. Some PDF files (and possibly other types as well) are being sent as 7bit, if the result from the stream filter returns that as a "best" encoding. For example, all documents generated by XSane (regardless of whether the option "Save PDF zlib compressed" is enabled or not), and nearly all documents generated by pstoedit.
However, when the e-mail gets processed by Microsoft Exhange or Lotus Domino, and the recipient opens the attachment, it is a blank page. Maybe \n gets replaced with \r\n or perhaps it is doing something similarly evil; I don't know. I'm pretty much sure that the problem is with exactly these servers, as the it occurs only to our customers who have Exchange or Domino. (We use Evolution + Exim4 and all other recipients receive the attachments w/o problem). So far I've been overcoming the issue by sending PDF files to such recepients with Mutt (which sends them as "quoted-printable"), but my colleagues can't use it so I had to think of another solution. The attached (possibly crippled) patch solves the problem and I've been testing it for more than 2 weeks without any ill effects. I'll perfectly understand if it is rejected by the maintainers or upstream; just thought that it's good to report this issue. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
camel_pdf_encoding.patch
Description: Binary data
