Using PMail 4.41 (yes, I know it's old)

Maybe for the last month or so, when viewing mail in the New Mail folder, I have been receiving emails where the From field and/or the Subject field are blank.

When I examine a regular email using the Raw View, I see that those fields are plain text (appropriate email addresses or subject text). When I examine an email where the From field or Subject field are blank, I see something like this:

From: =?UTF-8?B?4oCq4oCq4oCq4oCq4oCqTmV1cm9wYXRoeVRyZWF0bWVudEdyb3Vw4oCq4oCq4oCq4oCq4oCq?= <deleted for privacy>

Subject: =?UTF-8?B?4oCq4oCqU+KAquKAqnXigKpmZuKAqmVy4oCq4oCqIEbigKpy4oCqb23igKrigKogTuKAquKAquKAquKAqmVyduKAquKAquKAquKAquKAquKAquKAqmUg4oCq4oCq4oCq4oCq4oCq4oCqUGFpbj/igKo=?=

To: <my email address>

Can anyone tell me why this is happening? What email system (host or transport) is creating these messed up fields?

Fortunately, most of these are spam, but still ..

Thanks in advance!

Malcolm

This is a known issue. Here is what we know:

Two issues have been identified that can result in a blank subject line in a folder window.

One occurs only in the New Mail folder window. It is a result of an emoji in a UTF-8 encoded subject line. The outdated code of the current version of Pegasus Mail is unable to handle the encoded emoji resulting in a blank line.

The other occurs in a non-New Mail folder window. It is a result of truncated UTF-8 subject content in the folder index. This folder index used to display the message list of a folder. It has a fixed size limit for the subject content. The subject line will be truncated as necessary for it to fit in the available space. Prior to UTF-8 encoding, a subject line was transmitted in plain text so the worst ramification of this truncation might be a subject line that is incomprehensible. The introduction of UTF-8 encoded subject lines has changed that. With a UTF-8 encoded subject line, the message subject may be made up of a single or multiple UTF-8 "encoded words". Each can only be decoded as a whole. The index truncation done by Pegasus Mail can break that "whole" resulting in content that is indecipherable by Pegasus Mail so can not be displayed in a folder window. If the subject was made up of a single UTF-8 "encoded word" then the subject content will appear blank. If the subject was made up of more than one UTF-8 "encoded words" then only the truncated content will not be displayed. The actual subject content remains intact so it will appear in full in all message reader and reply windows. This issue can not be fixed in the current version of Pegasus Mail but should be fixed in a 5.x version.

Being lucky enough UTF-8 support had just been introduced in Pegasus Mail v4.31, i.e. six months before v4.41 was released ...

Brian, thank you for the complete explanation of what is happening, and why.

So, what is causing the increasing number of emails with this type of encoding? What email client, or transport, is creating these?

By the way, I'm 'old school', and think that emails are supposed to be plain text. Anything else is an attachment. I curse the day Micro$oft decided that emails should be HTML!

And emoji's in a From or Subject field? GASP!

Malcolm

I'm old school too, and, like you, despise HTML formatted email. Unfortunately I don't know enough about the source or the increase in volume of the messages you posted about other than the ongoing effort to make email pretty. I feel like email has become more of a marketing tool than a communication tool. Even when a message should be solely communicative there seems to always be a marketing component when it originates from a commercial entity. Of course spam is another thing, it's all designed to be attention grabbing and what is more attention grabbing that an emoji in the Subject field? Multiple emoji's.

I can confirm such mails, too. Since few weeks I'm receiving a long-term subscibed newsletter with an empty FROM: field as long as the mail stays in new mail folder.
But as soon as my automatic filter has moved the read message to another mail folder, the FROM field will be shown correctly on next Pmail startup.

In raw format the "FROM:" field reads:

From: =?UTF-8?Q?GefahrgutOnline=5BSpringer_Fachmedien_M=C3=BCnchen=5D?=
gefahrgut@springer.com

But irrespective whether emojies should be used or not in email headers, other mail clients like Thunderbird can handle this without any problems. And this is the reason that more and more users leave Pmail and change its mail client. I see it in our company. Only the old-school users (like me) are still using Pmail while all younger colleagues prefer Thunderbird which is connected via IMAP to our Mercury I. At the moment we are at about 50% Pmail to Thunderbird users.

We can discuss the sense and nonsense of emojis and other weird stuff as much as we want. The Internet is just too fast for David and his support team to keep up to date and to implement all that weird stuff comes out every day. Unfortunately, we have to face this truth.
We ourselves, as computer nerds, can handle it and could live with. But the majority wants to have html mails, emojis, etc..

My own opinion: Unfortunately we are a dying user community. But fortunately Mercury works great and we are happy that David has launched v4.9 recently which will be tested soon. At the end it doesn't matter with us which user is using which mail client.

Please take a step back when it comes to the encoding of headers meant to be displayed to users, guys, no matter how "old school" you are: You should keep in mind that English is the only language that can be displayed using pure (US-)ASCII letters (the US- prefix isn't by accident), any other lange from the overwhelming rest of the world uses characters which aren't covered by US-ASCII and need some kind of encoding invariably indroducing the kind of (relatively minor) troubles this thread is about. Luckily all languages can be handled using UTF-8 now so there's no need to transcode one charset into another anymore these days but as I already wrote above it's not too long ago that this capability was introduced in Pegasus Mail. It's not all "bells and whistles" only ...