LSTOWN-L Archives

LISTSERV List Owners' Forum

LSTOWN-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
GŽran Larsson <[log in to unmask]>
Mon, 13 Mar 2000 14:43:10 +0100
BDY.TXT (101 lines)
Hi,

Thanks for your input. I feel though I didn't explain enough.

We have not changed the list configuration in any way. The only new  
thing was the bottom banner and we didn't have any problems with the  
swedish characters before this change. But what is most peculior is  
that it is only in the body text the characters get distorted. The  
swedish characters in the bottom banner show up correctly. Is this of  
any help in trying to pin point our problem?

Göran  

-----Ursprungligt meddelande-----
Från: nitewing
Skickat: den 11 mars 2000 03:05
Till: LSTOWN-L
Ämne: Re: Bottom banner problem


On Fri, 10 Mar 2000, Stan Ryckman wrote:

>At 12:00 PM 3/10/00 -0500, Francoise Becker wrote:
>>On 10 Mar 00, at 10:22, G ran Larsson wrote:
>>
>>> We just started to use a Bottom Banner on one of our lists. The  
problem  
>>> is that it seems to upset the characters i the body text. The  
swedish
>>> characters å, ä and ö doesn't show up properly. Instead the text is
>>> full of f=F6 and such. This is true to postings to Hotmail,  
GroupWise,
>>> LotusNotes and perhaps some other e-mail applications.

Bottom banners certainly have their limits in MIME-encoded messages,
but I find it very difficult to believe that bottom banners are
causing *this* problem, based on my own experience with them.

>>
>>This is due to the fact that there isn't only one way to encode
>>special characters. Some email applications use quoted-printable,
>>others use 8-bit.
>
>That should not be the reason.  The mail protocols allow the encoding
>to be specified via a Content-Transfer-Encoding header, which
>allows conversion as needed (to QP for transfer through a 7-bit
>gateway, or to 8bit for display, etc.).  If no such header is
>present, it means 7bit, and there shouldn't be any high-bit
>characters at all.

Assuming, of course that the recipent's mail program knows how to
interpret them, and that all the mail transport agents involved are
capable of handling them.

>
>>If you assume quoted-printable, then it will look
>>like garbage on mail using 8-bit codes. If you assume 8-bit codes,
>>it will look like garbage on mail using quoted-printable.
>
>Not if properly labeled, and properly interpreted at the client side.
>I don't know, however, whether LISTSERV attempts to match up the
>bottom banner encoding with any CTE header it may put on the mail.

Rest assured, it does nothing of the sort.

The bottom banner is simply tacked on to the end of the raw message.
On a plain vanilla 7-bit message with no MIME encoding this is no
problem.

In a single-part "quoted-printable" message it normally causes no
problems either, except in special situations.  I have an "=a" in the
middle of one of my bottom banners, which is not valid "quoted
printable" encoding.  When Pine encounters a quoted-printable message
with that bottom banner tacked on, it chokes on it with a cryptic
enough error message that it took me some time to figure out what was
going on.

In multi-part messages where the end of the raw message is not part of
the message text (or any attachments for that matter), the banner will
simply "disappear" from view although it is still physically present
in the "raw" message.  I remember threads a while ago on this list
describing this situation.

Was there something else that also changed recently that might cause
this?  The most common cause I've encountered is subscriptions with
the "SHORTHDR" setting, which causes all the MIME encoding information
to be stripped out of the headers, wreaking havoc with MIME-encoded
messages.  But if this just suddenly started happening to bunches of
people, that doesn't sound likely.

Dennis

>
>(IMHO, most lists should probably restrict themselves to 7-bit since
>otherwise a Charset is needed in the headers to interpret
>the 8-bit characters anyway.)
>
>Cheers,
>Stan
>

ATOM RSS1 RSS2