Content-Transfer-Encoding: base64 problems
Patricia Hughes
which have "Content-Transfer-Encoding: base64" at or near the beginning
of the email. The message displays the html text mostly with sopmetimes
a reversion to displaying the html later in the mail. Has anyone else
experienced this and if so (more importantly!) does anyone know how to
cure it? I'm using Eudora 7.1.0.9 Paid mode with WinXP + SP3 and all
recommended updates. The emails in question display perfectly in
Thunderbird.
Thanks.
John H Meyers
> For the last couple of months I've been having problems with html emails
> which have "Content-Transfer-Encoding: base64" at or near the beginning
> of the email. The message displays the html text mostly with sometimes
> a reversion to displaying the html later in the mail. Has anyone else
> experienced this and if so (more importantly!) does anyone know how to
> cure it? I'm using Eudora 7.1.0.9 Paid mode with WinXP + SP3 and all
> recommended updates. The emails in question display perfectly in
> Thunderbird.
"Content-Transfer-Encoding: base64" is perfectly normal
(it's even over-used by some spammers to try to sneak past filters),
and Eudora has no problem decoding this,
for all properly constructed messages.
However, I find it unusual to see that header,
after Eudora has downloaded any of my complete messages.
Please check several things and let us know:
In your "Tools," "Options," "Incoming Mail"
is there a check-mark next to
"Skip messages over [NN]K in size"?
If you have several "personalities" defined,
then please look for the above in the "Properties"
of each personality, in the "Incoming Mail" tab of each,
by right-clicking each icon in turn,
in the "Tools," "Personalities" window.
Also, if you open each individual incoming message
(not in "preview pane," but press "Enter" or double-click
and open each message), there is a "Blah Blah" button
near the upper left part of each message window,
which can be depressed to "show all headers."
Do each of your incoming messages contain one header like this:
MIME-Version: 1.0
Also, exactly where does the "Content-Transfer-Encoding: base64" header
occur? (higher than the very first empty line after the first bunch of headers,
or where else?)
Is there just one particular sender (or sending domain)
whose messages seem to exhibit this?
Why we ask some of these things:
o Messages "skipped" because of being over a user-set size
will not have the attachments or embedded parts decoded or stored.
o The "MIME-Version: 1.0" header is required by internet mail standards,
and Eudora will likewise not parse "MIME" attachments or message parts
if the required header is omitted.
--
Patricia Hughes
> On Wed, 07 Jan 2009 15:13:15 -0600, Patricia Hughes wrote:
>
>> For the last couple of months I've been having problems with html emails
>> which have "Content-Transfer-Encoding: base64" at or near the beginning
>> of the email. The message displays the html text mostly with sometimes
>> a reversion to displaying the html later in the mail. Has anyone else
>> experienced this and if so (more importantly!) does anyone know how to
>> cure it? I'm using Eudora 7.1.0.9 Paid mode with WinXP + SP3 and all
>> recommended updates. The emails in question display perfectly in
>> Thunderbird.
>
> "Content-Transfer-Encoding: base64" is perfectly normal
> (it's even over-used by some spammers to try to sneak past filters),
> and Eudora has no problem decoding this,
> for all properly constructed messages.
>
> However, I find it unusual to see that header,
> after Eudora has downloaded any of my complete messages.
I sometimes see different headers in the body of emails, e.g.,
"Content-Transfer-Encoding: 7bit",
"Content-Type: text/html;
charset="iso-8859-2"
X-Mailer: SZAKK Hirlevel v2
X-Bulkmail: 3.12".
But in those cases, the rest of the message seems to display correctly.
>
> Please check several things and let us know:
>
> In your "Tools," "Options," "Incoming Mail"
> is there a check-mark next to
> "Skip messages over [NN]K in size"?
>
> If you have several "personalities" defined,
> then please look for the above in the "Properties"
> of each personality, in the "Incoming Mail" tab of each,
> by right-clicking each icon in turn,
> in the "Tools," "Personalities" window.
I have several "Personalities" but none of them has the "Skip
messages..." box checked, nor does the Tools/Options/Incoming Mail
(which is the same as the Dominant Personality?)
>
> Also, if you open each individual incoming message
> (not in "preview pane," but press "Enter" or double-click
> and open each message), there is a "Blah Blah" button
> near the upper left part of each message window,
> which can be depressed to "show all headers."
>
> Do each of your incoming messages contain one header like this:
>
> MIME-Version: 1.0
Yes they do.
>
> Also, exactly where does the "Content-Transfer-Encoding: base64" header
> occur? (higher than the very first empty line after the first bunch of headers,
> or where else?)
First line after the blank line after the first bunch of headers.
>
> Is there just one particular sender (or sending domain)
> whose messages seem to exhibit this?
There are at least two senders, one is a regular newsletter which used
to be perfectly readable but became unreadable at the beginning of
December (I've also written to them about it). The other was a one-off
from Friends Reunited telling me someone had commented on one of my
photos. Other mails from them (different sender) display correctly.
>
> Why we ask some of these things:
>
> o Messages "skipped" because of being over a user-set size
> will not have the attachments or embedded parts decoded or stored.
>
> o The "MIME-Version: 1.0" header is required by internet mail standards,
> and Eudora will likewise not parse "MIME" attachments or message parts
> if the required header is omitted.
>
Thanks for the extra info, it all adds to my understanding. What should
I look for next? Btw, I have a couple of the "offending" emails both in
Eudora and in TB3 so I can look for differences if that helps.
John H Meyers
JHM:
>> Exactly where does the "Content-Transfer-Encoding: base64" header
>> occur? (higher than the very first empty line
>> after the first bunch of headers, or where else?)
PH:
> First line after the blank line after the first bunch of headers.
This may be significant.
Eudora doesn't actually show the true "original" message,
precisely as it existed on the POP server (more later about this),
but the set of true "headers" of an original message
is terminated at the first empty line; whatever comes next
is in the "body" of the message, and is not parsed as a "header,"
even if it looks exactly like a header -- for example,
if I copy headers of an original message at the very top
of a new (or forwarded) message that I'm composing to you,
the copied headers are just part of my message text,
and are no longer taken as instructions
pertaining to my new outgoing message to you.
I should perhaps also have asked:
Is there a header anything like the following
within the topmost group of true message headers,
before the first empty line:
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_002C_01BFABBF.4A7D6BA0"
If there any such "multipart" header, then the "boundary" string,
with some barely noticeable extra "dashes,"
separates the entire message into "parts";
each "part" in turn then has its own set of headers
(again terminated by an empty line), including
it own individual "Content-Type:" header.
Here's a pretty well written summary of MIME message formats:
http://en.wikipedia.org/wiki/MIME
Here's another story:
http://www.wilsonweb.com/wmt5/html-email-multi.htm
>> Is there just one particular sender (or sending domain)
>> whose messages seem to exhibit this?
> There are at least two senders, one is a regular newsletter which used
> to be perfectly readable but became unreadable at the beginning of
> December (I've also written to them about it). The other was a one-off
> from Friends Reunited telling me someone had commented on one of my
> photos. Other mails from them (different sender) display correctly.
So it's rare, at least, and might, considering the analysis above,
be due to some not quite correct content -- perhaps from
copying one original message into the body of another?
> X-Mailer: SZAKK Hirlevel v2
Is it encoded in UTF-8 for Hungarian?
Eudora doesn't decode UTF-8 (Thunderbird does),
except with UTF8ISO plugin, as you know,
since I believe you installed it this past November, IIRC.
http://www.windharp.de/software/utf8iso.htm
(Thanks for the T.S.Eliot quote, by the way :)
I don't recall whether any headers other than "Subject:"
are permitted to also be encoded in UTF-8,
but I don't think so.
I also don't know whether UTF8ISO acts on message parts
that are sent in base64; I suppose this all depends
both on the capabilities of Eudora's architecture for plugins
and how the plugin author uses whatever capabilities are present
(hopefully Eudora would transparently decode base64 first,
but I'm too lazy to read all the plugin documentation
for developers, which I downloaded but never opened :)
> I have a couple of the "offending" emails both in Eudora
> and in TB3 so I can look for differences if that helps.
TB3? In the form of "Eudora 8," I presume?
At any rate, Thunderbird has a "View," "Source" function for messages,
which should, IIRC, be the true exact original message from the POP server,
before parsing by Thunderbird.
Some "webmail" (peek into POP server) applications
such as http://mail2web.com
also have a "source" viewer.
Any message received at (or pulled into) Gmail
also has "Show original"
in drop-down actions just to right of "Reply"
One could replace some chunks of message body parts (however macabre that sounds :)
with "[...]" for brevity, but keeping at least all the headers of all parts,
and perhaps a bit of whatever "body" doesn't look right, and post it,
for further inspection.
Or, email me the entire "source" of some message
(from TB, not from Eudora) as an attached text file,
replacing "nomail.invalid" in my email address with hotpop dotcom
(hotpop, rather than hotmail) -- I could then "inject" this
into my own Eudora, and see exactly what it does with it.
Best wishes.
--
John H Meyers
Original (HTML) message was sent correctly.
UTF8ISO plugin mangled it during initial receipt,
only when both "Process HTML Messages"
and "Decode MIME64 Encoding" options
(of the plugin itself) were turned on.
Possible work-around:
Process using UTF8ISO only after message arrives in mailbox,
via "pencil button" then "Edit" | "Message Plug-ins" | "UTF8->ISO"
--
richar...@gmail.com
The email was sent by Lotus Notes Release 7.0.2 September 26, 2006.
The email header has "Content-Transfer-Encoding: base64" and "Content-
type:text/plain; charset=UTF-8".
My Eudora version is 7.1.0.9
Try the plug-in as well. It doesn't work for me. Can anyone help?
John H Meyers
What is the "same problem"?
What plugin? (and what is said plugin's actual function?)
What does "work" mean? What do you expect to happen?
The previous person was invited to send me an original message,
exactly as found on their POP server, and was shown a means to do that;
nothing was sent, so no analysis has been made, and can not be,
until a real sample is submitted.
Every single binary attachment
(e.g. images, Office documents, "zip" files, PDFs)
is always sent in "base64" encoding, and if you find
that Eudora never fails to decode and store those properly,
you can conclude that decoding of standard "base64" encoding
isn't the actual issue, but without a sample message to inspect,
it's hard to find out what else is.
All that I can suggest to you, with no actual sample to look at,
is to try other email clients (Thunderbird, Outlook Express, Outlook);
if they do what you want, then that's the solution, and if they don't,
then surely there must be something wrong with what's being sent.
--
John H Meyers
to which my previous remarks were addressed.
If you have the "same" problem as the OP in this thread,
which in fact was due to the UTF8ISO plugin itself,
perhaps the same solution may help:
http://groups.google.com/group/comp.mail.eudora.ms-windows/msg/df5c464f79b31793
Eudora does not by itself handle UTF-8, and needs help from a plugin,
except when there are actually no "extended" characters in the message,
in which case no decoding is needed anyway.
--
nardu...@gmail.com
Hello.
I'm experiencing since a month or so a problem that looks similar to the ones discussed in this thread.
Since years I receive from Science an e-mail alert of new contents. I never had trouble reading them. Recently, however, mails look as follows:
X-Persona: <omitted@omitted>
Received-SPF: pass (Last token {include:_netblocks.eloqua.com} (res=PASS)) client-ip=204.92.22.145; envelope-from=<in...@aaas-science.org>; x-ip-name=mail03.aaas-science.org;
Received: from mail03.aaas-science.org (unverified [204.92.22.145])
by mater.unimib.it (SurgeMail 3.9c) with ESMTP id 3884368-1943733
for <myaddress@mydomain>; Fri, 09 Mar 2012 00:28:26 +0100
Return-Path: <in...@aaas-science.org>
X-Verify-SMTP: Host 204.92.22.145 sending to us was not listening
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
d=aaas-science.org; i=ale...@aaas-science.org;
q=dns/txt; s=dk; t=1331249304; x=1362785304;
h=from:sender:reply-to:subject:date:message-id:to:cc:
mime-version:content-transfer-encoding:content-id:
content-description:resent-date:resent-from:resent-sender:
resent-to:resent-cc:resent-message-id:in-reply-to:
references:list-id:list-help:list-unsubscribe:
list-subscribe:list-post:list-owner:list-archive;
z=From:=20"Science=20Express=20Notification"=0D=0A=20<aler
t...@aaas-science.org>|Reply-To:=20"Science=20Express=20Not
ification"=0D=0A=20<ale...@aaas-science.org>|Subject:=20
=3D?utf-8?B?U2NpZW5jZSBTY2llbmNlZXhwcmVzcyBOb3RpZmljYXRpb
24gZm9yIDA4IE1hciAyMDEyCg0=3D?=3D|Date:=208=20Mar=202012
=2018:28:11=20-0500|Message-ID:=20<bf665cde0947427ea763e5
afde8590c2@1906>|To:=20myaddress@mydomain
|MIME-Version:=201.0;
bh=SRwM6vnX+qFn27xRftQOiDpMqxVPV3ZHF6EMBNJBp4I=;
b=k8iQIaKyrhNGTNKolFqIyGmQKKCBPBPROxwyJ5I8RXpvHqHuaVQDfWA2
NY0icpbV3qZvbsNIJNeTRCUXvJ5fSg==;
Message-ID: <bf665cde0947427ea763e5afde8590c2@1906>
MIME-Version: 1.0
From: "Science Express Notification"
<ale...@aaas-science.org>
To: myaddress@mydomain
Reply-To: "Science Express Notification"
<ale...@aaas-science.org>
Date: 8 Mar 2012 18:28:11 -0500
Subject: Science Scienceexpress Notification for 08 Mar 2012
----boundary_1149778_5a509e89-076c-46c7-813e-96b40b0d01ed
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
VG8gdmlldyBvbiBhIG1vYmlsZSBwaG9uZSBvciB0byB2aWV3IGFzIGEgd2ViIHBh
Z2UsIHBsZWFzZSBjdXQgYW5kIHBhc3RlIHRoZSBmb2xsb3dpbmcgbGluayBpbnRv
IGEgYnJvd3Nlci4NCltodHRwOi8vYXBwLmFhYXMtc2NpZW5jZS5vcmcvZS9lcy5h
c3B4P3M9MTkwNiZlPTE2NzYwJmVscT1iZjY2NWNkZTA5NDc0MjdlYTc2M2U1YWZk
ZTg1OTBjMl0NCg0KDQoNClNjaWVuY2UgU2NpZW5jZWV4cHJlc3MgTm90aWZpY2F0
aW9uICANCg0KTmV3IFNjaWVuY2UvQUFBUyBXZWJpbmFyDQpOZXcgQXBwcm9hY2hl
etc.
If I cut and paste the text it gets translated into ASCII by online programs such as http://www.base64decode.org/ but this is truly unpractical. Is there anything I can do to convince Eudora 7.1.0.9 to convert the attachment the proper way?
Thank you
Dario
vid...@gmail.com
Envelope-to: m...@mydomain.com
Date: Fri, 15 Jun 2012 16:16:15 -0400
Subject: Re: Shoe laces
From: John <fri...@gmail.com>
To: m...@mydomain.com
MIME-Version: 1.0
X-Antivirus: avast! (VPS 120615-0, 06/15/2012), Inbound message
X-Antivirus-Status: Clean
Content-Transfer-Encoding: base64<html XY ÆÖWF ‡GG ÖW V—cÒ$6öçFVçBÕG— R" 6öçFVçCÒ'FW‡@/html; charset=UTF-8"></head><body>And that's just the one you found....<br><br><br KKKKKKKH ÜšYÚ[˜[ Y\ÜØYÙH KKK@----<br>Subject: Shoe laces <br>From: m...@mydomain.com <br>To: "Me" <m...@mydomain.com> <br>CC: <br><br><br ›˜œÜ ÕÚ È ÛÝ[ ]™H ÝYÚ ‹‹ œ ‚ H ™Y H€http://www.fieggen.com/shoelace/index.htm" eudora="autourl" š ‹ËÝÝÝË™šYYÙÙ[‹˜ÛÛKÜÚ Ù[ XÙKÚ[™ ^ š O œ ‚ ØCÇ‚Ðsigsep><p>
---<br ‘[ X] œ œ ‚‰›˜œÜ È[ÝH Ø[‰Ý [ Ø^\Èget what you<font color="#0000FF">
</font Ø[ œ€¢fæ'7; but if you try sometime, you just might
find<font color="#0000FF">,<br>
</font>you'll get what you<font color="#FF0000" Ù›Û ›™YY ˆ œ€¢fæ'7 ²fæ'7 ²fæ'7 ²fæ'7;
--- Jagger /Richards
John H Meyers
> I am having the same problem with mail sent from a mobile phone...
> charset=UTF-8
"base64" is not the problem -- UTF-8 is the problem
(Eudora does not handle UTF-8,
except with a UTF8ISO plugin, which is itself a bit flawed).
<http://en.wikipedia.org/wiki/UTF-8>
--
