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).
I've attached a test case, to detirmine what happens to files sent
through Sanitizer with odd line-break characters (=0A and =0D).
I sent this by creating an ordinary text file containing the text below
marked as Test Case, and sending it using:
sendmail -v -oi myuser <filename
I've sent this through both Sanifilter to Cyrus and not through
Sanifilter to Cyrus, passed it only through sanitizer.pl, and passed it
through sendmail directly to the local mailer (/var/spool/mail). My
sanitizer configuration would pass this through with "accept".
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.
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.
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.
Of course, it's fine if it's a text type.
With Base64, the line breaks are always ignored, so the problem isn't
From: Dave Cridland <firstname.lastname@example.org>
To: You <email@example.com>
Subject: A test email.
Content-Type: multipart/mixed; boundary="thisistheboundary"
This is a MIME message.
Content-Type: text/plain; charset=iso-8859-1
This is a test message to test:
1) Whether the Sanitizer mangles line endings in email inside
quoted-printable encoded parts.
Dave's Test name is:
Dave's Test ID is:
This is an unknown sort of=20=0A=0Dfile which is very odd indeed.=0D=
It has strange=0Dline endings, and commonly has =0A=
=0Dline breaks in odd places.=
This bit=0Ais also odd.=
Sample output of the quoted-printable bit after going through Cyrus:
This is an unknown sort of=20
=0Dfile which is very odd indeed.=0DIt has strange=0Dline endings, and
=0Dline breaks in odd places.This bit
is also odd.