Re: bug? in quoted-printable handling?

From: Dave Cridland (
Date: Wed 16 Jan 2002 - 17:06:32 UTC

  • Next message: Paulius Bulotas: "Re: bug? in quoted-printable handling?"

    On Wed, 2002-01-16 at 14:30, Bjarni R. Einarsson wrote:
    > On 2002-01-16, 10:58:03 (+0000), Dave Cridland wrote:
    > > On Wed, 2002-01-16 at 08:09, Paulius Bulotas wrote:
    > > > I try to send dbf file, which size is 39422 bytes and after receiving
    > > > it, the size is 39425 (I suspect three extra 0xD in front of 0xA, for
    > > > one I'm really sure).
    > ...
    > >
    > > What appears to be happening is that =0A (\n in C) gets translated into
    > > a real line break - either by the Sanitizer or by Cyrus - in as much as
    > > I can tell, it's done by both.
    > I'm not sure encoding a =OA like that is legal QP. Possible yes,
    > but the "correct" behavior may be undefined by the standard.

    I think it's perfectly legal...

    > > Whatever is doing it also translates trailing = (meaning, the following
    > > line break doesn't count) into no line break at all, reformatting the
    > > part into 80 chars wide.
    > Which is perfectly normal behavior...

    Possibly, but nothing else is doing it.

    > > The problem is that if you read the attachment on, say, a Windows
    > > machine, or a Mac, the line break characters are different, and you'll
    > > potentially be changing the size and content of the file.
    > I'm going to have to look at what the RFC says to pass judgement on
    > whether this whole issue counts as a bug or not. I rather suspect
    > not. QP encoding is by nature ambiguous about various newline
    > related issues - it's only intended for text data, binary data is
    > always supposed to be Base64 encoded.
    > > Of course, it's fine if it's a text type.
    > QP should never be used for anything /but/ text.
    > Mail clients doing otherwise are broken... which doesn't mean we
    > don't have to accommodate them (after all, without broken mail
    > clients there wouldn't be much need for the Sanitizer), but it does
    > effect my prioritization a bit. :-)

    I'll look into providing a QP decoder and encoder which will produce the
    same output as the input...

    It strikes me that where Anomy Sanitizer is not intending to change the
    attachment, it should not be doing so, and while it may not be a bug
    exactly, it's certainly not a required effect.


    hosted by