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.
> 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...
> 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. :-)
-- Bjarni R. Einarsson PGP: 02764305, B7A3AB89 firstname.lastname@example.org -><- http://bre.klaki.net/
Check out my open-source email sanitizer: http://mailtools.anomy.net/ Spammers, please send plenty of email to: email@example.com