We are battling the QP encoding issue. For those unfamiliar with this issue,
when a binary that has been improperly encoded via QP encoding by an email
client passes through Anomy it can become garbled if Anomy converts a CRLF
to a LF (or vice-versa?).
Every once in a while we get a PDF that is unreadable. I realize that the
cause of the problem is the email client being silly, but unfortunately we
can't fix the email client of users not under our umbrella. Therefore we
need to consider a fix for Anomy.
Here is my understanding of the problem:
1. A MUA uses QP encoding to MIME encode a binary file such as a PDF.
2. The message is routed to our mail server.
3. Our mail server hands the message to Anomy, which inspects the message.
4. During MIMEStream::RawRead() Anomy will replace \015\012 with \012, which
breaks the PDF.
5. Anomy packs the message back up and returns to mail server.
6. Mail server delivers to our user.
7. User can't open PDF and so sends us a nice little email with colorful
words. They also CC: the boss.
8. The boss then moves us from our nice cubicles to the basement where we
are then surrounded by old printers flashing "PC LOAD LETTER".
MIMEStream::Write() also seems to be doing something with newlines.
Regardless of how ugly the solution is, what can we do here?
1. We can write code to determine if a PDF is attached. If so then bypass or
abort Anomy entirely. Bad!
2. We can write code to determine that Anomy is dealing with a PDF as part
of the larger message. If so then do not replace \015\012 with \012.
3. We can write code so that Anomy never does \015\012 for any QP encoding.
This kills a good feature of QP encoding which allows users of various
platforms to email one another. Possible?
What can we do here?
--- Dustin Puryear http://www.puryear-it.com