This appears to beis a mail encoding problem.
The 'equals' 'hexnumber' notation is referred
to as "quoted-printable".
You can read more about this format here:

<http://www.freesoft.org/CIE/RFC/1521/6.htm>

Either your mail package cannot handle "quoted-printable" or the mail is
being altered by a server/system/spam filter somewhere that is removing the
encoding type tag (or miss-converting it)
You can check this by looking at the message headers of the offending
e-mail.  It should say something along the lines of:

Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

If it is missing the "quoted-printable" part, you need to talk
to your ISP to see what is going on.

I have looked at messages from the list, and I can clearly see
that the "Content-Transfer-Encoding: quoted-printable"
is being delivered intact (on the messages that have been
encoded using this technique).  When I look at messages from
my other ISP, I can see:

X-MIME-Autoconverted: from quoted-printable to 8bit by mail02.syd.optusnet.com.au

Which indicates they are converting the format for me (but
in all cases successfully)

I have seen mail list software that attempts to re-encode
mail depending on the encoded format that the user uses when
they first sign up to the list.  So if I use "quoted-printable" when I subscribe,
I will always get "quoted-printable" on messages from the list - but I doubt this
is the case with the FB list.

As a final test, the following line is a row of 'equal' signs.
If the encoding is failing, then they will appear as a row of 'equals' and '3D',
as I am using 'quoted-printable' as my encoding type for this message.
Note I will send this to you both directly, and via the list - you should
end up with no difference:


=====================


See what you find.

Jamin

 

On Friday, 10 September 2004 11:53 PM, Hayden Coon <hgcoon@...> wrote:
>Hello from Maine!
>    I have been troubled by mucked up code that includes not only the 
>ubiquitous "=20" but other constructs like: "=AC", "=AD" etc.
>Usually these are obvious enough, =20 seems to be line break, =AC, "¬", 
>(see example quotation below). At their worst they occur in groups that 
>are meaningless (can be deleted).  I assume they are ASCII codes that 
>don't get translated; they are annoying, is there anyway to stop them?  
>Have I got my mail prefs wrong? (I'm using Apple "Mail" under OS X 
>10.3.5)  The annoyance seems to have started about the time that the 
>shift to "Associate.com" was initiated, is it a problem with them?
>    Is the problem unique to Maine?  Any ideas how to deal with this 
>"issue"?
>    TIA,  Hayden Coon
>
>    Example from today's list:
>
>toolbox fn CreateStandardAlert( AlertType alertType,=AC
>    CFStringRef err, CFStringRef explanation,=AC
>    const AlertStdCFStringAlertParamRec *param, DialogRef *outAlert ) 
>=3D =
>
>OSStatus
>toolbox fn RunStandardAlert( DialogRef inAlert, Proc filterProc,=AC
>    DialogItemIndex *outItemHit ) =3D OSStatus
>toolbox fn SetDialogTimeout( DialogRef inDialog, SInt16=20
>inButtonToPress,=AC
>     UInt32 inSecondsToWait ) =3D OSStatus
>toolbox fn GetDialogTimeout( DialogRef inDialog, SInt16=20
>*outButtonToPress,=AC
>    UInt32 *outSecondsToWait, UInt32 *outSecondsRemaining ) =3D OSStatus
>toolbox fn StdFilterProc( DialogRef theDialog, EventRecord *event,=AC
>    DialogItemIndex *itemHit ) =3D Boolean
>
>// from ControlDefinitions.h
>_kControlStaticTextCFStringTag =3D _"cfst"
>
>// from CFString.h
>// special case of a variable args routine
>toolbox fn CFStringCreateWithFormat( CFAllocatorRef alloc,=AC
>    CFDictionaryRef formatOptions, CFStringRef format, long firstArg ) =
>=3D=20
>CFStringRef
>
>--
>To unsubscribe, send ANY message to:
>futurebasic-unsubscribe@...
>