Some email contents not correctly displayed

some emails seem not correctly displayed, as in the attached, all are ???

mail-headers:
Content-type: text/html; charset=utf-8
MIME-Version: 1.0

have no idea what causes the problem…

Can you provide the entire message source including headers? Please redact it as necessary to not contain sensitive data. Ideally using a hex editor to avoid having an editor perform some character set detection and/or conversion.

do you have an email, so that i send the message to you? it does have personal sensitive information

Just click on his name and then on Message.

You can forward the message as attachment to debugging@cketti.de. Please don’t use the regular “forward” action. That won’t include the information necessary to investigate the issue.

The message contains two Content-Type header fields.

Content-Type: text/html
Content-type: text/html; charset=utf-8

K-9 Mail will only use the first one and assume US-ASCII because no charset argument was specified.

You should contact the sender and get them to fix the software that was used to generate the message.

I wonder if K-9 could maybe be less strict with the standard here. Given that utf-8 is a superset of US-ASCII, K-9 could always use the former. This also works around other issues where some mail tools encode utf-8 but still send only the US-ASCII header (got a few of those emails recently).

I know it feels bad to not follow the standard just to work around others not following the standard but it would save you support work and would make non-technical users happy. AntennaPod also no longer follows the standard and does a lot of guesswork because some publishers regularly mess up their IDs. This sometimes even breaks valid feeds but the number of feeds that now look better is larger than before. In the case of the charset in K-9, it should not break valid emails, so I think it could be acceptable to do.

1 Like

This comes up quite a bit. I guess I need to sit down and write a blog post about it. The short version is: Apps that silently accept broken data will make the internet a worse place.

If enough viewer apps display data that doesn’t conform to the written standard in a certain way, this new data format becomes an undocumented standard. People who write software that generates data will assume their data is fine because the most popular viewer apps will display it as expected.

However, people who write new viewer software will have to discover the entire “undocumented standard” either by reading the source code of the popular viewer apps (if available) or via bug reports from their users. This situation isn’t great for developers or users.

Of course K-9 Mail’s current behavior of not displaying a message as expected isn’t helpful either. Users don’t have any idea what’s wrong. So ideally we’d detect these situations and tell the user the message is broken and they should try to get the sender to fix the software they’re using.

If we display an annoying “this message is broken” banner or something similar, I’m fine with adding workarounds to still display the message as the sender expected it to be displayed. But the banner needs to be annoying enough so there’s an incentive to at least try to get the broken software fixed.

2 Likes

you are certainly right. standard is always good, but sometimes being less strict with standard could be even useful, because >95% users are non-technical.
in many cases, many senders, e.g., >95%?, are also non-technical, and they only use some non-standard software to send the message – they have no idea how to work with that but only simply do their work by sending message.

The idea is not too bad. However, adhering to standards all the time is not possible.

E.g., in Germany there exists the DIN responsible for all sorts of standards. If you follow their standards for electrical wiring, network cables, etc., all doors to a room with electrical and network outlets need to be over 2.46 metres in width! Nobody builds a house like that.

E.g., there are several RFCs (for all those nitpicks out there: yes, I am aware that these aren’t standards), which were released on 1 April. However, they are not clearly marked as jokes, so technically they apply. Some (non-1-April) RFCs also contradict eachother.

W.r.t. ITU and ISO standards it is useless to try to educate the users. Thus, just displaying the broken message as such, i.e. broken, is technically correct, but addresses the wrong person. I would add an enormous fixed banner at the top stating that the message is broken and K-9 is trying it’s best at compatibility. The banner could include a button allowing the user to send a “bug report” with all details on the conflicting data directly to the sender. This way, no information gets “lost in translation.” (just imagine how one would react if someone writes to you that your email is broken without further details)

As we are already moving away from the original topic and have an idea how this could be handled (not being too strict with standards if it helps users of K9) maybe a similar approach could be found for this topic where K9 users also run in issues as others (HostGator) is not following the standards: