Several news about this version for Pegasus Mail 4.8, so here's the most important stuff:

• Further enhancements of the copy/paste support which allow insertion of documents including pictures as far as supported by the source and converter systems which means: There are several "black boxes" involved which IER can't control since Pegasus Mail's TER editor is Rich Text based which only office applications and IE itself provide native RTF contents for on the clipboard. In all other cases TER's HTS module (with some of my tweaks) attempts to convert the HTML which works more or less successful and sometimes completely fails. So be prepared for inconsistent outcomes - but you may also be surprised about the final result even when the preview looks pretty ugly. Samples can be provided on request!

• Then there've been two feature requests:

  1. One of them was for ways to add browser's to IER's dropdown menu without having do edit the system's Registry for testing purposes. I've done two things to achieve this, the first, simple one was to use Pegasus Mail's Tools => Options => Hyperlinks => Web browser commandline option: If you enter an additional browser there which isn't registered but can be located on a connected drive it will be listed in the menu as well as the other browsers, you just don't have any options with regard to shortcuts and its display name. If not connected it'll simply be ignored, of course (don't know about side effects in BearHtml and plain text mode, though).Safe with regard to the latter is the second option using an INI file named BrowserList.ini located in the user's new mail directory: A copy containing instructions will by installed therein when launching Pegasus Mail for the first time after the update. It will just sit there and do nothing until someone actually adds command lines to it.

  2. The second request was for a permanent exception list to permit downloads from certain domains which continuously redirect remote image URLs. The respective INI file named BlockList.ini is installed the same way as the aforementioned one, and adding domains is simply done by ticking the respective check box in the warning dialog popping up on redirection attempts by default if redirections aren't disabled at all in IER's options dialog. The INI file option will override this global setting for the respective domain, and for now there's no way other than editing the file to reverse it. Suggestions are welcome!

• Like always there've been several fixes of issues reported by users and found by me while working on these new features and trying to enhance my code for better maintenance, you may or may not notice. Two issues I remember are a background color issue resulting in unreadable replies and image download errors caused by user agent rejections - unfortunately increasingly being seen and not always avoidable even though I'm already "borrowing" the Edge user agent on systems where it's actually installed.

IER's "hompage": https://www.pmpgp.de/renderer/History.htm

Download URL: https://www.pmpgp.de/renderer/IERenderer.zip

Very nice work on the options to manually add browsers to IER's browser submenu. Utilizing a configured hyperlink commandline is brilliant. Taking it a step further with the BrowserList.ini file is consistent with the power and flexibility of Pegasus Mail. It allows for the addition of multiple browsers and control over how those browser names appears in the submenu. Very well thought-out and nicely done. Thank you!

I don't do much with formatted copy/paste so will leave the testing and comments on those enhancements to others.

Thanks for the update.
Just installed it and my feeling is that the new version loading mails faster.

Just one thing, is it possible to add an automatic notification for new versions?
I think most people do not make regularly manual update-check for IER, so most people not even know that new versions with bug corrections or improvements exists.
The check can be done perhaps by default once a week but with an option to deactivate the check.

Thanks Michael. Appreciated.

I do "install" new IER versions at our Mercury/Pmail server installation only by replacing the existing dll (or other newer files in your collection) after unpacking the setup with innounp.
Do I have to copy the new blocklist.ini and browserlist.ini into each user mail directory of my 20 users? Or is IER creating these ini files by itself as soon as an user is using the new functions?

You only need to copy these files into the IERenderer subdirectory (i.e. the one hosting IERenderer.dll). IERenderer is then supposed to copy them from there into each user's New Mail directory the first time they launch their instance of Pegasus Mail after doing so. I couldn't implement it any other way since the installer doesn't "know" about user specific directories on installation, especially not on network setups like yours.

I didn't think of what happens if it doesn't find the files, though, I should certainly add some kind of error handling with regard to this and add some info to the respective section on IER's history page, so thanks for asking with regard to this as well. Currently it'll most probably create the BlockList on first user interaction anyway, but definitely without the comments in there, and the BrowerList is for advanced users only, so it wouldn't do no harm other than being useless ...

I'll think about it and need to discuss it with David Harris since it's something that clearly has an impact on Pegasus Mail which I cannot decide without asking for his permission and ideas. One of the issues with notifications is that people either don't notice anything at all even if it's going on right in front of them or quickly get pretty annoyed, so finding a proper way between these extremes isn't quite easy ...

How about like a small overlay icon on IER's toolbar button (which lots of people certainly never notice let alone try to click for figuring out IER's options)?

Great. This is less work for admins.
I will update as soon as my last user has left the office and the file overwriting is not longer be locked due to open sessions. Then I could reply how it works.

I must admit, I also keep forgetting that an IER symbol exists with a nice sub menu.
And without the email notification from forum thread about IER-update, I do not know if I recognized the update within this month.

Just installed (copied) the update. Works fine with me. As soon as I activate the new checkbox for permanent saving, IERenderer is placing the INI into user's mailbox directory.

Only one minor thing noticed, sometimes I have to tick the checkbox for the same sender domain twice (or three times), means in two different or three different mails of the same sender, until IER is remembering and don't asking again. Maybe there is a little writing delay for the ini file.

This is weird since the list is always stored in memory even if it's not immediately written to disk so it should work even though. And it's certainly not read from file each time a new download is attempted since this would cause noticable delays.
There might be some IE cache settings involved although I'm trying to reset them, and I certainly have absolutely no knowledge about the effects of network delays. Another point is that this all happens during a running download session and there's some kind of weird pseudo-threading going on which is unfortunately out of my control, it's the way IE's browser control works which forces me to prevent user input except for on very rare occasions, this being one of them.

Maybe I should try with some of the Heise newsletters whether I can duplicate this.

Did it and figured out the reason: The Heise newsletter contains remote image URLs redirected from different domains: One called heise.de and a second one called heiseshop.de. If it was shop.heise.de it would be just a single entry in the list, but this requires two entries and you're not getting prompted a second time after closing the first dialog. For now I would add the domain name to the check box text, but I need some opinions about how to further deal with it:

• There will certainly be spam and commercial mails containing myriads of redirected image urls which would prompt users on each download attempt if I allow them to do so for each domain not yet encountered during a download for a single message - and there's no chance to tell in advance unless slowing down the whole message processing by a significant amount of time.

• Leave it like it is so you need to trigger another image download manually if still getting redirection errors from other domains (I'll certainly be able to provide some more details in the error message without too many efforts).

Any other ideas?

In my case the affected mails are wanted newsletters or product recommendations, like e.g. Heise newsletter, Zyxel newsletter (because we own different security appliances from Zyxel), Dangerous Good newsletter (Vogel Verlag), something like this ...
From my point of view and to keep it simple, all "image loading domains" which are included in such a mail could be permanently allowed, means, when e.g. receiving a mail from sender ...@heise.de the "image domains": heise.de, heiseshop.de, shop.heise.de, whatever else included, could be added to your list because I trust Heise in general.

But indeed, on next time the newsletter could contain a new image loading domain which causes the popup warning again. That's why you could also register only the sender address (of the newsletter) which doesn't change so often, which means that mails from this trusted sender domain should always load all image without additionally asking the user for single or new image loading domains.

You could also think about adding a small information header text line above the mail, informing the user that remote images have been automatically loaded in case the sender domain has been added to the "allow" list.

Merry Christmas

This is a bad idea for several reasons:

1. The sender address is part of the least protected section of all in email messages: Email headers are still not safe against fraud of all kinds. Doing something like this would require to establish a safe mechanism for verifying digital header signatures and AFAIK there's still no standard being applied everywhere and Pegasus Mail hasn't implemented any either so far. For details see https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail, e.g..

2. Doing what you suggest would require to prescan the whole message for collecting all outgoing URLs which will definitely slow down message processing significantly especially given the fact that processing messages with pictures are loading slower anyway (no matter how hard I try).

3. Like in the case of the Heise newsletter you may especially not want to download those pictures which it doesn't allow on first run: The heiseshop.de images are the ones pointing to app downloads for Android and IPhone Apps. I've got another sample from emails I'm getting from the German Ärzteblatt directing to a host called "stats-eu1.crsend.com", you can guess its purpose, I assume ... And fortunately these ones only come up at the bottom of these messages.

4. But maybe I'm just different: I really don't understand what for people need all those commercial pictures at all, to me they are just slowing down my computer work and interrupting my music streaming. Videos being even worse: I'm pretty faster in understanding what I read than what I watch (which makes me fall to sleep) ...

I forgot to add two more issues here:

1. The newsletter domain doesn't necessarily match the image download domain. Job-related newsletters, e.g., may be managed by PR companies instead of the professional organisations.

2. I don't have access to the "From" address without asking David Harris for an extension of the current HTML viewer interface - well, that's not quite true, I could extract it from the print headers ...

And just one remark with regard to this: Even they aren't always safe and maybe getting compromised: Remember the successful Emotet attack against Heise in 2019? Here's a yt video about it: https://www.youtube.com/watch?v=o4CyX-y42YA

Moin Michael,
Thank you for your extensive explanations and that you do not give up trying to explain the background to us.
If it becomes simply too extensive from here, then I can also live well with this version.