On 11/21/22 00:16, Gareth Evans wrote:
On Sun 20 Nov 2022, at 07:08, Tom Dial <tdd...@comcast.net> wrote:
On 11/19/22 10:09, gene heskett wrote:
On 11/19/22 11:45, gene heskett wrote:
On 11/19/22 06:45, Gareth Evans wrote:
On 19 Nov 2022, at 10:17, Gareth Evans <donots...@fastmail.fm> wrote:
On 19 Nov 2022, at 04:08, gene heskett <ghesk...@shentel.net> wrote:
On 11/18/22 19:05, Gareth Evans wrote:
[...]
iirc, headers (that is, the lot of them) are supposed to be terminated by a
blank line (double line break) before message content/multipart
boundaries/blocks begin
[...]
You're right of coarse, and yes, that was a straight copy paste from a geany
session on the saved message [...]
If you view the message source in Thunderbird, are the individual headers still
separated by blank lines? Saving the message and examining the output
introduces the possibility of CRLF line endings, which Geany may not convert.
I think David Wright is correct that Tb is showing the (empty) plain text
section. I didn't notice this at first as I was struck by the blank lines and
didn't look any further.
If there were blank lines between headers in the raw message, I think Tb would
be displaying the contents of the raw message after the first blank line, in
plaintext, because the chain of headers had been broken at that point, and
multipart boundaries etc not interpreted.
So I think the blank lines in headers are probably a red herring, however they
got there.
The base64-encoded string in the text/html part (which begins "PEhUT...")
converts to HTML:
https://devpal.co/base64-decode/?data=PEhUTUw%2BPEJPRFk%2BPHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwMDA7Ij48c3BhbiBzdHlsZT0iZm9u%0A%0AdC1mYW1pbHk6QXJpYWwsSG
=_Part_164_535344686.1668739861264
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: base64
PEhUT...
What happens if you try (in Tb)
View > Message Body As > Original HTML
?
And I'll repeat one more time, then I'm done, there is NO html content in the
messages, not even a mimetype boundary for it.
Here is a verbatum copy/paste of the most recent msg of several I have received
from this online seller:
==================================================================
Return-Path: <c...@omc-stepperonline.com>
Received: from 216.163.176.191 unverified ([216.163.176.191]) by
mwweb09oc.mail2world.com with Mail2World SMTP Server;
Sat, 19 Nov 2022 07:08:13 -0800
Received: from [47.90.198.27] (port=48703 helo=out198-27.us.a.mail.aliyun.com)
by prd-mail2world-inbound-ash1-008.ash1.cynet with esmtps (TLS1.2) tls
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.94.2)
(envelope-from <c...@omc-stepperonline.com>)
id 1owPSF-0002kY-Pd
for ghesk...@shentel.net; Sat, 19 Nov 2022 15:08:28 +0000
X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R191e2;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018047206;MF=c...@omc-stepperonline.com;NM=1;PH=DS;RN=1;RT=1;SR=0;TI=SMTPD_---.QBl8rV7_1668870493;
Received: from iZuf677iw3xihpZ(mailfrom:c...@omc-stepperonline.com
fp:SMTPD_---.QBl8rV7_1668870493)
by smtp.aliyun-inc.com;
Sat, 19 Nov 2022 23:08:13 +0800
Date: Sat, 19 Nov 2022 23:08:13 +0800 (CST)
From: c...@omc-stepperonline.com
To: gene heskett <ghesk...@shentel.net>
Message-ID: <457669489.89.1668870493425@iZuf677iw3xihpZ>
Subject: Re:We found the problem as to why I cannot "see" your emails.
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_88_360748977.1668870493425"
X-mailer: javamail@rebee
X-CTCH-Spam: Unknown
X-CTCH-VOD: Unknown
x-ctasd: uncategorized
x-ctasd-vod: uncategorized
X-CTCH-Flags: 0
X-CTCH-RefID:
str=0001.0A742F15.6378F16C.000F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
X-CTASD-IP: 47.90.198.27
X-CTASD-Sender: c...@omc-stepperonline.com
X-OpenTrafficX: clean
X-OpenTrafficX-type: clean
X-OpenTrafficX-ID: 155810::1668870508-ABFD6BA6-19F98021/0/0
------=_Part_88_360748977.1668870493425
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: base64
------=_Part_88_360748977.1668870493425
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: base64
PEhUTUw+PEJPRFk+PHNwYW4gaWQ9ImNrLW1haWwtY29udGVudCIgc3R5bGU9ImZvbnQtZmFtaWx5
OkFyaWFsO2ZvbnQtc2l6ZToxNHB4O2NvbG9yOiMwMDAwMDA7Ij5EZWFyIEdlbmUsPGJyIC8+Cjxi
ciAvPgpUaGFuayB5b3UgZm9yIGxldHRpbmcgbWUga25vdy4gQ2FuIHlvdSBzZWUgbXkgZW1haWwg
bm93PyZuYnNwOzwvc3Bhbj4KPGRpdj4mbmJzcDs8L2Rpdj4KCjxkaXYgbmFtZT0icmItc2lnbmF0
dXJlLWRpdiI+CjxwIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWw7IGZvbnQtc2l6ZTogMTRweDsg
Y29sb3I6ICMwMDAwMDA7IHBhZGRpbmctbGVmdDogMDsgbWFyZ2luLWxlZnQ6IDA7Ij5CZXN0IFJl
Z2FyZHM8YnIgLz4KWW9sYW5kYTxiciAvPgombmJzcDs8YnIgLz4KPHN0cm9uZyBzdHlsZT0iZm9u
dC1zaXplOiAyMnB4OyBmb250LWZhbWlseTogQXJpYWw7Ij48c3BhbiBzdHlsZT0iY29sb3I6ICMw
MDdjYzM7Ij5TVEVQUDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6ICMwMDA7Ij5FPC9zcGFuPjxz
cGFuIHN0eWxlPSJjb2xvcjogIzAwN2NjMzsiPlJPTkxJTjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s
b3I6ICMwMDA7Ij5FPC9zcGFuPjwvc3Ryb25nPjxiciAvPgpUZWw6ICs4Ni0yNS04NzE1NjU3OCB4
MDU5PGJyIC8+CjxhIGhyZWY9Im1haWx0bzpjczA2QG9tYy1zdGVwcGVyb25saW5lLmNvbSIgc3R5
bGU9ImNvbG9yOiAjMDAwMDAwOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij5jczA2QG9tYy1zdGVw
cGVyb25saW5lLmNvbTwvYT48YnIgLz4KPGEgaHJlZj0iaHR0cDovL3d3dy5vbWMtc3RlcHBlcm9u
bGluZS5jb20iIHN0eWxlPSJjb2xvcjogIzAwMDAwMDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+
d3d3Lm9tYy1zdGVwcGVyb25saW5lLmNvbTwvYT48L3A+CjwvZGl2PgoKPGRpdj4mbmJzcDs8L2Rp
dj4KLS0tLS0tLS0tLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0tLS0tLS0tLTxiciAvPgpGcm9t
77yaZ2hlc2tldHRAc2hlbnRlbC5uZXQ8YnIgLz4KVG/vvJpjczA2QG9tYy1zdGVwcGVyb25saW5l
LmNvbTxiciAvPgpTdWJqZWN077yaV2UgZm91bmQgdGhlIHByb2JsZW0gYXMgdG8gd2h5IEkgY2Fu
bm90ICZxdW90O3NlZSZxdW90OyB5b3VyIGVtYWlscy48YnIgLz4KRGF0Ze+8mjIwMjItMTEtMTkg
MTM6Mjg6NDg8YnIgLz4KPGJyIC8+CkdyZWV0aW5nczs8YnIgLz4KPGJyIC8+ClBsZWFzZSBnZXQg
YW5vdGhlciBlbWFpbCBhZ2VudCwgamF2YW1haWwgaXMgYnJva2VuIGFuZCBzZW5kaW5nIHN1cnBs
dXM8YnIgLz4KYW5kIGJvZ3VzIG1pbWUtYm91bmRhcnkgbWVzc2FnZXMuPGJyIC8+CjxiciAvPgpU
aGlzIHdhcyBzdGFuZGFyZGl6ZWQgaW4gMTk5MiwgYW5kIHRoZXJlIGlzIG5vIHJlYXNvbiBvdGhl
ciB0aGFuIGxvY2tpbmc8YnIgLz4KaW4gdGhlIHVzZXIgdG8gdXNpbmcgTSQgY3JhcCB0aGF0IHZp
b2xhdGVzIHRob3NlIHJmYyYjMzk7cyB0aGF0IGdvdmVybiBob3c8YnIgLz4KdGhpcyBlbWFpbCB0
aGluZyB3b3Jrcy4gR2V0IGFuIGVtYWlsIGFnZW50IHRoYXQgY29uZm9ybXMgdG8gdGhlIHJmYyYj
Mzk7czxiciAvPgphcHBsaWNhYmxlLjxiciAvPgo8YnIgLz4KQ2hlZXJzLCBHZW5lIEhlc2tldHQu
PGJyIC8+Ci0tPGJyIC8+CiZxdW90O1RoZXJlIGFyZSBmb3VyIGJveGVzIHRvIGJlIHVzZWQgaW4g
ZGVmZW5zZSBvZiBsaWJlcnR5OjxiciAvPgpzb2FwLCBiYWxsb3QsIGp1cnksIGFuZCBhbW1vLiBQ
bGVhc2UgdXNlIGluIHRoYXQgb3JkZXIuJnF1b3Q7PGJyIC8+Ci1FZCBIb3dkZXJzaGVsdCAoQXV0
aG9yLCAxOTQwKTxiciAvPgpJZiB3ZSBkZXNpcmUgcmVzcGVjdCBmb3IgdGhlIGxhdywgd2UgbXVz
dCBmaXJzdCBtYWtlIHRoZSBsYXcgcmVzcGVjdGFibGUuPGJyIC8+Ci0gTG91aXMgRC4gQnJhbmRl
aXM8YnIgLz4KR2VuZXMgV2ViIHBhZ2UgJmx0OzxhIGhyZWY9Imh0dHA6Ly9nZW5lc2xpbnV4Ym94
Lm5ldDo2MzA5LyZndDsiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZ2VuZXNsaW51eGJveC5uZXQ6
NjMwOS8mZ3Q7PC9hPjxpbWcgc3R5bGU9ImRpc3BsYXk6bm9uZTsiIHNyYz0iaHR0cDovLzEzOS4x
OTYuMjcuMTQvL21haWxUcmFjaz90cmFja0NvZGU9aHM2N1o5NjEtMjAyMjExMzIzMjMwNjQ0NTc1
IiAvPjwvQk9EWT48L0hUTUw+
------=_Part_88_360748977.1668870493425--
=================================================.
That is the whole thing as highlighted and pasted directly from the view source
screen.
I have striped off the mime headers, leaving only the base64'd content, and I
just updated the system which included firefox-esr and thunderbird, it still
will not display the content of this message.
What I'm trying to do is build a couple of faster BIG 3d printers, my ender5+
is now 77 hours into a 9 day build, about 35% done making a piece for a product
6 up at a time. I have stuff on a oxcart someplace in china to quadruple this
printers currently running speed which is around 300mm a second. The motor I'm
trying to buy is part of that plan.
I've just installed some stuff uudecode related, maybe I can see these replies
the hard way.
From the above, and the mime rfc's, can anyone tell me which is broken, their
javamail, or my thunderbird? IMO the extra blank line should have caused t-bird
to advance to the next boundary statement and properly decode that base64'd
content. It is supposed to be re-entrant. I was around when mime was being
developed, and even helped make the e-mailer I was using for os9 (not mac, but
a unix like os for the trs-80 Color Computer) in about 1990. From my now 30+ yo
memory, its t-bird that's broken as it is NOT responding to the extra blank
line between those boundary statements above. In the interim, I will hand
decode that base64 with xdview or similar.
Thank you all. Take care and stay well now.
Cheers, Gene Heskett.
And this is crazy beyond belief. javamail is base64'ing all of the html
composed reply to my query. But because t-bird is broken and not re-entrant as
it should be, I'm not seeing it. Or, is there some option I can set that will
enable its display. FTR, I hate html in an email.
In the meantime I'll find a way to burn up the existing motor and get the job
done, I've stuff on hand to double its voltage to 48 volts. To be done when the
rest of the kit gets here. Estimated at another 3 weeks. My last post in this
thread. They can fix it so I see their replies, or do without my business, it
really is that simple.
Cheers, Gene Heskett.
The included text above displays perfectly well in my Thunderbird
(102.5.0) on Debian Bullseye (copied and pasted to a file with a .eml
extension). I seem to recall your version may not be especially
current; if so that might have something to do with the problem at hand.
I take no position, though, on the question of whether the message is
well-formed. That is beyond my knowledge level.
Regards,
Tom Dial
Attachments:
* msg.eml
Hello all,
I was wondering why some people were able to view the HTML version immediately
in the file they had made of Gene's email, whereas I was not.
The setting in
View > Message Body As
seems to be the default view setting I was looking for elsewhere - it sticks
between restarts and is applied to other messages.
Gene, what is your setting there?
On what may now be a minor point, in the plaintext view of Gene's email (saved
as a file) I definitely get two blank lines, which I can copy and paste.
"------=_Part_88_360748977.1668870493425
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: base64
------=_Part_88_360748977.1668870493425
Content-Type: text/html;charset=UTF-8
Content-Transfer-Encoding: base64"
$ apt policy thunderbird
thunderbird:
Installed: 1:102.5.0-1~deb11u1
Thunderbird seems to interpret this as content, which might prevent an
automatic switch to HTML view (if plaintext view is the default) if that's
what's supposed to happen, as Gene suggested.
The example in RFC2049 seems to imply blank lines surrounding part boundaries
(and their fields), but it doesn't seem to mandate this explicitly:
https://www.rfc-editor.org/rfc/rfc2049.html#page-15
But afaics, RFC1521 (which 2049 eventually superseded) requires only a blank
line following part header fields.
"7.2 ... Each part
starts with an encapsulation boundary, and then contains a body part
consisting of header area, a blank line, and a body area.
...
NO header fields are actually required in
body parts. A body part that starts with a blank line, therefore, is
allowed and is a body part for which all default values are to be
assumed. In such a case, the absence of a Content-Type header field
implies that the corresponding body is plain US-ASCII text."
https://www.rfc-editor.org/rfc/rfc1521
Thunderbird seems to be forgiving of missing blank lines preceding part
boundaries.
There is a difference in how the first specifier of the part boundary
specifier code in the headers, no blank line is needed either side of
that header statement, but after that first blank line that separates
the header from the msg content, every blank line encountered after that
first one should trigger the mime handling code. This was part of the
original proposal back in the late '80's.
There are quite a few RFCs which supersede 1521, and I haven't trawled
through them all. There may be some ambiguity here, but it seems to me
there should be at most one blank line in the plaintext content, which
is still enough to throw a spanner in the works if the "re-entrant"
behaviour Gene expects is indeed to be expected.
Unless the rfc has been changed, it is a blank line that signals the
mime handling stuff to take over, so there must be a blank line before
the mime-boundary statement containing that OTP code. So theoretically,
it should process the mime-boundary, process the next line as whatever
the statement said it was. So the blank line should just loop back read
the next statement until such time as it finds, after decoding the next
line as base64, should treat the bas64 output as html. I do not want to
send html email, so the prefs here are set to send plain text.
However I did change that setting momentarily, making no difference, I
was still looking at a blank screen .
If I strip it down to just the base64 block, and feed that to xdeview, I
get what looks like html, enough I can understand the message.
Those prefs in t-bird, should NOT effect how it treats incoming email,
only what I compose as a reply, incoming, which we have little or no
control over and t-bird should handle it all, so yes, t-bird IMO, has a bug.
So obviously does this vendors javamail but what its miss-doing should
not be a showstopper. Repeated requests for plain text reply's have all
come back with the echo of my msg encoded as html, then base64'd. No
plain text.
My midden heap had enough motors that this is down to one motor I still
need, but I'll be whupped if I'll pay an extra $33 each for Chinese
freight, for a motor I can buy for $12.00 on amazon in single shaft
version. I do have nema 24 motors I could adapt but it would largely
defeat the purpose to add the flying weight that would add to the power
chain in doing that adapting. So I'll take advantage of the existing
motors temperature rating and bang it harder electrically. That I CAN do.
Best wishes,
Gareth
Back at ya Gareth, take care & stay well.
.
Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/>
