Re: The QP encoding issue - again!

From: Dustin Puryear (
Date: Mon 10 Nov 2003 - 23:18:17 GMT

  • Next message: Marvin Herbold: "Re: The QP encoding issue - again!"

    I'm glad you mentioned that. That is actually the plan of attack that we
    decided on, but for some reason I didn't list it. If someone has already
    done this then let us know. I would hate to reproduce the effort. Thanks!

    Reports suggest that this happens mostly with some graphics files and PDFs.
    Anyone have experience with this on other files?

    ----- Original Message -----
    From: "Systems Administrator" <>
    To: "Dustin Puryear" <>
    Cc: <>
    Sent: Monday, November 10, 2003 5:08 PM
    Subject: Re: [anomy-list]: The QP encoding issue - again!

    On Mon, 10 Nov 2003, Dustin Puryear wrote:

    > We are battling the QP encoding issue. For those unfamiliar with this
    > 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,
    > 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
    > 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.
    > Possible?
    > 3. We can write code so that Anomy never does \015\012 for any QP
    > This kills a good feature of QP encoding which allows users of various
    > platforms to email one another. Possible?

    4. You can add the \r\n back in afterwards if it's a PDF.


    > What can we do here?
    > ---
    > Dustin Puryear

    Tim Nelson
    Systems Administrator
    Sunet Internet
    Tel: +61 3 5241 1155
    Fax: +61 3 5241 6187

    hosted by