Re: Strange text viewing
- From: Brian Stafford <brian stafford uklinux net>
- To: chbm chbm nu
- Cc: Balsa List <balsa-list gnome org>
- Subject: Re: Strange text viewing
- Date: Tue, 14 May 2002 16:28:25 +0100
On Tue 15:20, 14 May 2002 Carlos Morgado wrote:
> On 2002.05.14 15:06:26 +0100 Mancini Stéphane wrote:
>> I've just received a message that balsa 1.3.5 views in a strange manner.
>> The mail is in an attached part and what I view follows. It's very strange
>> What's the matter ?
> the mime header of the text part of the message you attached is:
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: base64
> this is crap as the the transfer-encoding is *not* base64. balsa decodes
> the part as if it were base64 and shows that few lines of garbage. any
> comments brian ?
It seems like the original message was transmitted with the incorrect
content-transfer-encoding: header, or it might have been munged by an
An intermediate MTA might change the content transfer encodings if a message
was relayed from an 8 bit clean connection to a 7 bit only one, i.e the first
few hops offer the 8BITMIME extension but a subsequent one does not. IIRC,
some sendmail configurations will rewrite the message MIME structure when this
is the case (I'm prepared to believe that sendmail will stop at nothing to
reformat all your messages, particularly the headers).
I would have thought it unlikely the original MUA (Nutscrape 4.75) would
encode a message incorrectly, however, it's possible that Nutscrape might
screw up in an unusual configuration. For instance, when told to assume 8 bit
clean and the submission MTA does not support 8BITMIME. If this is the case
changing the preferences to assume 7 bit connections might help (I can't
remember the exact place in the preferences dialog for this though).
In any case, a client doesn't have much chance to behave correctly when
incorrect content-transfer-encodings are specified. It might be possible to
devise a heuristic to detect when data declared as base64 is not actually
encoded and attempt to use it verbatim but I reckon this will cause more
problems than it solves. Perhaps it might be better to detect the coding
error and present the save to file option instead of attempting to display the
data (as for unknown MIME types). At least then a user can muck around with
the invalid content using standard unix tools.
] [Thread Prev