As of today, messages from two different sources that until recently have been displaying normally give me:

> [ Empty or malformed message. Use "H" to see raw text. ]

On displaying raw text, I see a header:

> Content-Transfer-Encoding: base64

followed by gibberish.

What do I need to do to display this properly?

Other email sources are still readable. But the fact that this has happened with two different sources at once makes me wonder if there has been some event unconnected with the senders alone, such as an event on my operating system.

I am on Ubuntu 20.04.4 LTS, running Alpine 2.25. According to `/var/log/apt/term.log`, the last update to the system was two days ago, and involved rsync, man-db and systemd.

- dpb

I should add that it's possible for Alpine's "select based on text" function to find messages using text content. It's just not possible for the program (as configured) to display the text. It's also possible to display the attachment-form of message using w3c.

- dpb

On Sat, 20 Aug 2022, d...@brannerchinese.com wrote:

> As of today, messages from two different sources that until recently have been displaying normally give me:
>
>> [ Empty or malformed message. Use "H" to see raw text. ]

It looks like this is a malformed message, but without seeing an example
this is just conjecture. Is there any way that one of your sources can
send you a "test" message that shows the problem and that you can share
with me so that I can analyze it?

Thank you.

--
Eduardo
https://alpineapp.email (web)
http://repo.or.cz/alpine.git (Git)

On Sun, 21 Aug 2022, Eduardo Chappa wrote:

> On Sat, 20 Aug 2022, d...@brannerchinese.com wrote:
>
>> As of today, messages from two different sources that until recently have
>> been displaying normally give me:
>>
>>> [ Empty or malformed message. Use "H" to see raw text. ]
>
> It looks like this is a malformed message, but without seeing an example this
> is just conjecture. Is there any way that one of your sources can send you a
> "test" message that shows the problem and that you can share with me so that
> I can analyze it?

It turns out that this was a message with two alternative parts, one
text/plain and another text/html, where the text/plain part is empty but
the text/html part is binary encoded. The "A" command allows users to
switch the view of the message between the two alternative versions and in
this case this means changing between the empty plain/text part and the
encoded text/html part.

I hope this clarifies this situation.

--
Eduardo
https://alpineapp.email (web)
http://repo.or.cz/alpine.git (Git)

On Sun, 21 Aug 2022 21:25:52 -0600, Eduardo Chappa wrote:
> On Sun, 21 Aug 2022, Eduardo Chappa wrote:
>> On Sat, 20 Aug 2022, d...@brannerchinese.com wrote:
>>
>>> As of today, messages from two different sources that until recently have
>>> been displaying normally give me:
>>>
>>>> [ Empty or malformed message. Use "H" to see raw text. ]
>>
>> It looks like this is a malformed message, but without seeing an example this
>> is just conjecture. Is there any way that one of your sources can send you a
>> "test" message that shows the problem and that you can share with me so that
>> I can analyze it?
>
> It turns out that this was a message with two alternative parts, one
> text/plain and another text/html, where the text/plain part is empty but
> the text/html part is binary encoded. The "A" command allows users to
> switch the view of the message between the two alternative versions and in
> this case this means changing between the empty plain/text part and the
> encoded text/html part.
>
> I hope this clarifies this situation.

And would not <Right Arrow> list all parts?
-- with clues as to the sizes of each part?

Jonesy
pine/alpine since back in the last century...
--
Marvin L Jones | Marvin | W3DHJ.net | linux
38.238N 104.547W | @ jonz.net | Jonesy | FreeBSD
* Killfiling google & XXXXbanter.com: jonz.net/ng.htm

Eduardo Chappa wrote:

> I hope this clarifies this situation.

It's clear, yes — thanks, and for your timely reply.
Here is what I'm thinking. The help text for "Prefer Plain Text" reads:

> Alpine will normally display the most-preferred version that it knows how to display. This is most often encountered where the two alternate versions are a plain text version and an HTML version, with the HTML version listed last as the most preferred.

But it seems to me that if the most-preferred version is *empty*, as in this case, then by default Alpine should still show the less-preferred version.. The most-preferred version being empty is a different situation from it being hard to read for some reason. If it doesn't exist, then surely whatever version does exist should be displayed.

Doesn't that make more sense than defaulting to a note about possibly a malformed message?

- dpb

d...@brannerchinese.com <dpb@brannerchinese.com> wrote:
> [...]
> Here is what I'm thinking. The help text for "Prefer Plain Text" reads:
>
>> Alpine will normally display the most-preferred version that it knows
>> how to display. This is most often encountered where the two alternate
>> versions are a plain text version and an HTML version, with the HTML
>> version listed last as the most preferred.
>
> But it seems to me that if the most-preferred version is *empty*, as in
> this case, then by default Alpine should still show the less-preferred
> version. The most-preferred version being empty is a different situation
> from it being hard to read for some reason. If it doesn't exist, then
> surely whatever version does exist should be displayed.
>
> Doesn't that make more sense than defaulting to a note about possibly a
> malformed message?

Hi unknown stranger,

what you are suggesting is a more or possibly less sense full - in my
opinion "less"! - would-be solution for a püroblem which lies somewhere
else.

The actual problem is on the side of the software which assembles the
mail: either it only wants to supply a HTML part then its no problem at
all and totally legit to send a mail with only an HTML part with
eventually included additional parts like graphics (as
"multipart/related") or it really wants to send information in two
different representations and then it should (also) generate a valid
"text/plain" part.

This is the problem! Not alpines behaviour!

So please leave the church in its village place and don't ask for
solutions which aren't solutions.

Sorry for being so touched by this subject but a lot of problem are
nowadays solved where they never can be solved.

Regards
Henning
--
In theory there is no difference between theory and practise.
In practise there is.
Yogi Beer

On 2022-08-23 02:02, d...@brannerchinese.com wrote:
> Eduardo Chappa wrote:
>
>> I hope this clarifies this situation.
>
> It's clear, yes — thanks, and for your timely reply.
>
> Here is what I'm thinking. The help text for "Prefer Plain Text" reads:
>
>> Alpine will normally display the most-preferred version that it knows how to display. This is most often encountered where the two alternate versions are a plain text version and an HTML version, with the HTML version listed last as the most preferred.
>
> But it seems to me that if the most-preferred version is *empty*, as in this case, then by default Alpine should still show the less-preferred version. The most-preferred version being empty is a different situation from it being hard to read for some reason. If it doesn't exist, then surely whatever version does exist should be displayed.

It is empty, but it does exist. Alpine has to try to display it. It gets
confused and says "Empty or malformed message".

The fault is of the software that wrote the email, which should not have
created an empty part. Either create it properly or not create it at
all. Some software write a terse message saying that you really have to
read the html text.

--
Cheers, Carlos.

Carlos E.R. wrote: "Either create [the email] properly or not create it at all."

Henning Hucke wrote: "The actual problem is on the side of the software which assembles the
mail …"

I do not have the ability to affect how the sender constructs the message. I do (or I may) have the ability to control how it is processed at my end.

- dpb

d...@brannerchinese.com <dpb@brannerchinese.com> wrote:
> Carlos E.R. wrote: "Either create [the email] properly or not create it
> at all."
>
> Henning Hucke wrote: "The actual problem is on the side of the software
> which assembles the mail …"
>
> I do not have the ability to affect how the sender constructs the message.
> I do (or I may) have the ability to control how it is processed at my end.

I do not have the ability to affect whether or not the person with which
I speak uses the right words - "car" for a table, "table" for a house or
the like" - but I do (or I may) have the ability to control (!) how it
is processed by me and my family so I can write a translation table
after I've worked out the hundreds of words the other person uses in
another way and this way I and my family can understand the other person
instead of trying to teach him/her the right use of words (and others
still can't understand the person!).

You get the picture?

This (!) stuff is clearly a missimplementation of the generation of
mails which are supposed to follow the MIME standard so notify the
sending organisation about this fact and make clear that they are
violating standards - in contrast to "asking" them to adapt to your
"needs" which is definitly not the issue here!.
They might tell you that they also only use a method class or a software
of a software provider. In this case point them to the relevant RFCs and
especially to the relevant sections to pass these to the author of the
method class and/or the provider of the software.

Believe me: It's much harder to adapt all and every mail reader software
on the world to the diverse missimplementations of MIME mail generating
sofware than to do it the right way around. And this way the world also
becomes a little bit better instead of a little bit more patchy.

Hugh! I've spoken.

Regards
Henning
--
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)