Re: tbird AND javamail both broken
On Sun 20 Nov 2022, at 07:08, Tom Dial <tddial@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 <donotspam@fastmail.fm> wrote:
>>>>>
>>>>>
>>>>>> On 19 Nov 2022, at 04:08, gene heskett <gheskett@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: <cs06@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 <cs06@omc-stepperonline.com>)
>>> id 1owPSF-0002kY-Pd
>>> for gheskett@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=cs06@omc-stepperonline.com;NM=1;PH=DS;RN=1;RT=1;SR=0;TI=SMTPD_---.QBl8rV7_1668870493;
>>> Received: from iZuf677iw3xihpZ(mailfrom:cs06@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: cs06@omc-stepperonline.com
>>> To: gene heskett <gheskett@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: cs06@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 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.
Best wishes,
Gareth
Reply to: