Re: Strange text viewing

[Brian Stafford <brian stafford uklinux net>]

On Tue 15:20, 14 May 2002 Carlos Morgado wrote:
> 
> On 2002.05.14 15:06:26 +0100 Mancini Stéphane wrote:
>> Hi,
>> 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:
> -------------EC469EE12639107494E4D037
> 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 
intermediate MTA.

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.

Brian