F
Francois Grieu
Right after applying the Office 2001 Update 9.0.6
[on a PowerMac G4 running MacOS 9.2.2], I noticed
somme attachments of received messages are damaged,
most notably compressed files, and resource forks.
The problem affects received attachments encoded using
"base64" as "application/octet-stream" when the size of
either the data or resource fork is not a multiple of 3;
they loose their one or two last bytes.
It is reproducible. With SimpleText, create a file containing
exactly 4 letters. Save it. Make a duplicate. Change the
file type of the duplicate to "xxxx". Send both files
as attachment in an email to self, with the default attachment
settings (AppleDouble, no compression).
Receive the message and extract the two attachments. Change
the type of the duplicate file back to "TEXT". Notice that
the content is truncated to 3 chars, while the same file
sent as "TEXT" is OK (both are encoded as "base64", but only
the "xxxx" one is sent as "application/octet-stream").
Also note that ResEdit reports that the resource fork
of both received files is damaged beyonfd repair.
As a workaround, drag the whole received email to the
desktop, which saves it as a file with the undecoded
attachment; then extract the attachment using Stuffit
Expander 7.0.3 (version 6.0.1 will not do).
The faulty code appears to be in the library
"Microsoft Framework 2001" version 9.0.6 (8320).
The problem is cured by reverting to
"Microsoft Framework 2001" version 9.0.5 (7407).
Unfortunately, this library is destroyed by the
Office 2001 Update 9.0.6, and there is not source for
it that I could locate on the net.
Also, Entourage 2001 version 9.0.6 is still affected
by several unrelated bugs that pleague earlier versions:
- When decoding an attachment encoded as quoted-printable,
and the last byte of a 65536 byte block is either a
space or a tab, it is lost.
This tends to randomly corrupt big attachments encoded
as quoted-printable, including text-only PDF files sent
by some some Unix mailers which notice the base64 version
would be bigger. For a test case, see
http://fragrieu.free.fr/QuotedPrintableBug.sit
- When decoding an attachment encoded as quoted-printable,
and a line ends without the = sign, Entourage decodes this
line-ending as 0x0D, when RFC 2045 unambiguously prescribes
it should be decoded as 0x0D 0x0A.
This tends to corrupt PDF files encoded as quoted-printable
by (another) Unix mailer.
- When sending text in a message (HTML or text-only),
Entourage creates line breaks to respect the 76-character
limit of RFC 2045, THEN encode some special characters
(dicriticals, the = sign..) using the = sign as prefix.
The result is often lines that are longer than 76 characters,
and this is NOT compliant with RFC 2045.
This is especially nasty in France, where we use a lot
of diacriticals, and many recipents see extra line breaks.
Demonstration: Make an HTML email with a line containinng
50 times the sign = between two empty lines. Save. Examine
the source.
Francois Grieu
[on a PowerMac G4 running MacOS 9.2.2], I noticed
somme attachments of received messages are damaged,
most notably compressed files, and resource forks.
The problem affects received attachments encoded using
"base64" as "application/octet-stream" when the size of
either the data or resource fork is not a multiple of 3;
they loose their one or two last bytes.
It is reproducible. With SimpleText, create a file containing
exactly 4 letters. Save it. Make a duplicate. Change the
file type of the duplicate to "xxxx". Send both files
as attachment in an email to self, with the default attachment
settings (AppleDouble, no compression).
Receive the message and extract the two attachments. Change
the type of the duplicate file back to "TEXT". Notice that
the content is truncated to 3 chars, while the same file
sent as "TEXT" is OK (both are encoded as "base64", but only
the "xxxx" one is sent as "application/octet-stream").
Also note that ResEdit reports that the resource fork
of both received files is damaged beyonfd repair.
As a workaround, drag the whole received email to the
desktop, which saves it as a file with the undecoded
attachment; then extract the attachment using Stuffit
Expander 7.0.3 (version 6.0.1 will not do).
The faulty code appears to be in the library
"Microsoft Framework 2001" version 9.0.6 (8320).
The problem is cured by reverting to
"Microsoft Framework 2001" version 9.0.5 (7407).
Unfortunately, this library is destroyed by the
Office 2001 Update 9.0.6, and there is not source for
it that I could locate on the net.
Also, Entourage 2001 version 9.0.6 is still affected
by several unrelated bugs that pleague earlier versions:
- When decoding an attachment encoded as quoted-printable,
and the last byte of a 65536 byte block is either a
space or a tab, it is lost.
This tends to randomly corrupt big attachments encoded
as quoted-printable, including text-only PDF files sent
by some some Unix mailers which notice the base64 version
would be bigger. For a test case, see
http://fragrieu.free.fr/QuotedPrintableBug.sit
- When decoding an attachment encoded as quoted-printable,
and a line ends without the = sign, Entourage decodes this
line-ending as 0x0D, when RFC 2045 unambiguously prescribes
it should be decoded as 0x0D 0x0A.
This tends to corrupt PDF files encoded as quoted-printable
by (another) Unix mailer.
- When sending text in a message (HTML or text-only),
Entourage creates line breaks to respect the 76-character
limit of RFC 2045, THEN encode some special characters
(dicriticals, the = sign..) using the = sign as prefix.
The result is often lines that are longer than 76 characters,
and this is NOT compliant with RFC 2045.
This is especially nasty in France, where we use a lot
of diacriticals, and many recipents see extra line breaks.
Demonstration: Make an HTML email with a line containinng
50 times the sign = between two empty lines. Save. Examine
the source.
Francois Grieu