Sometimes someone answers my e-mail with an emoji, e.g. a Like, but the IErenderer produces an error instead: "Error 415 - unsupported media type":

Is there a setting to prevent the error and show the emoji?

You can prevent this from showing by updating your versions of Pegasus Mail and IERenderer to the latest available version, respectively: For Pegasus Mail goto https://www.pmail.com/v48x.htm, for IER see the link in my signature down below.

If this doesn't work please forward a sample message to <beta-reports [at] pmail.gen.nz>.

Sorry, Pmail is v4.8 and IERenderer 2.7.1.2. Additionally I updated IERenderer to 2.7.2.2 which was not advertised automatically.

I cannot reproduce the error myself (android, ios, outlook). Because of privacy I will not forward you the email that gave the problem. I copied a few lines from Raw view:

Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

[https://outlook-1.cdn.office.net/assets/reaction/like.png]     Ev* *** *** **** reacted to your message:

On updating IERenderer to 2.7.2.2 a message window says: "... Image downloads as of Version 2.7: Due to Microsoft's end of support for IE and missing support of the TLS 1.3 security protocol by its WinInet connection library it became necessary to additionally use a different Windows library (WinHttp) which unfortunately only became available in a suitable version with Windows 10 20H2 (along with the Chromium based MS Edge browser version). In previous Windows versions you’ll may now occasionally see an error message offering a non-secured download in such cases. Unfortunately this issue can currently only be worked around by opening such a message in a suitable browser (i.e. not IE) by using the respective command in Pegasus Mail's reader's right click menu (clicking outside of an image placeholder). NB: It is not required to (re)install or use the Edge browser!" Is the problem related to this? I have W10 22H2.

You will need PM's public beta of v4.81 (check the link I sent) which provides an updated library for dealing with the latest image formats, v4.80 does not. It's more stable than v4.80 and fixes some issue of the latter even though it's formally "just a beta". it's already used by lots of other people without issues - unless you're running PM with new mail box and home mail box being located in separate locations. For figuring this out open Help > About Pegasus Mail > Info Button from its main menu which will show both these location paths.

Did you ever try to open such an email in your browser (or only the image itself by using the right click context menu on the error frame displayed): Here's the result of clicking the link you provided:

This is from Firefox, and since it's a PNG there shouldn't be any issue with displaying it, but obviously even Firefox only displays garbage instead of a picture.

Surprisingly in this reply it does get displayed which I can't explain especially since it doesn't do so in your reply above.

Without investigating the original message within Pegasus Mail I cannot figure out what's going wrong, I'm sorry. How about asking the sender to just send a message only containing this emoticon?

Yes, I found Firefox displaying garbage, Edge showing the correct png. There is discussion about this Firefox problem. Firefox shows the file as text. This error is caused by the server that sends the png. The server that sends the .png should send it as mine type image/png. So I tested https://outlook-1.cdn.office.net/assets/reaction/like.png in HTTPie. The server responds with the mime type: text/plain in the header!
I conclude Edge and other programs are tolerant to this error and recognize the ‰PNG fingerprint of a png and Firefox and IERenderer aren't.

A typical Internet issue: WTF are rules for if they (mainly MS and Ggl) make there own rules just due to being such powerful companies ...

I should add here that I've alread dealt with a similar situation where images are sent as application/octet-stream which is commonly used for binary (executable) attachments which are blocked by default for preventing attacks against the recipient. So it looks like I need to assume another exceptional case for being dealt with here.

I've now checked and tested my code against the sample link you provided: It would have been able to deal with the improper MIME type sent by the server - and it actually works in my compatibility code for Windows versions below 10 20H2, but not with the recent code for later versions using WinHTTP instead of WinInet for supporting current TLS algorithms. Unfortunately the latter provides download data where the PNG is starting with "#$1F'‹'#8#0#0#0#0#0#0#0#1'…'#3'zü‰PNG'#$D#$A#$1A#$A" instead of the correct sequence "‰PNG'#$D#$A#$1A#$A" (readable transcoding from the binary sources). Im sorry to say, but I won't work around this by parsing and correcting the code beyond its current state because this opens another door for carelessly breaking the rules and possibly causing safety issues, see https://en.wikipedia.org/wiki/Content_sniffing. Someone should get the providers to fix their sources (BTW: IE displays the same garbage as Firefox does if submitting the URL via address line, and IER is based on IE's renderer as you can tell by its name).