Over the weekend of September 17-18, the wall box that connects me to the New Zealand fibre network failed, effectively cutting me off from the world. Because I'm not in a position to pay several thousand dollars a year for a support contract, the network people would not come out to replace the device until Monday (today), although to give them credit, they turned up very promptly on Monday morning.
The wall box (or "ONT" as it is known in the industry) has now been replaced and access should be back to normal. I'm sorry for any inconvenience this might have caused.
For the longest time, web sites hosted in Amazon's S3 service could not use HTTPS. Recently, however, things appear to have changed, and it is now possible to use Amazon's Cloudfront service to apply HTTPS to such servers.
I have now changed the www.pmail.com website over to use this mechanism. If you encounter any problems accessing the site as a result of this change, please let me know so I can check into it.
A helpful person has pointed me at a paragraph in GMail's OAUTH terms and conditions that I had overlooked as I tried to work out what did and didn't apply to me. This paragraph appears to say, fairly unambiguously (which would be a first in this whole process) that because Pegasus Mail uses only local storage (i.e, it only ever stores mail on devices belonging to the user) it should be exempt from the GMail validation process and its associated fees.
I'm looking into this as best I can, given that Google do not provide any contact links of any kind to get authoritative answers from real people... But if it turns out this is correct, I'll restart the publication process and see if we can't get the code approved soon.
At the end of May 2022, GMail (Google Mail) will require all users to switch to an authentication process called OAUTH2.
We have now completed the code and interface required to support OAUTH2 for GMail in Pegasus Mail, and have put it through extensive active testing. The final step in the process was to click the 'Publish App' button in the Google console where I set up the parameters for the Pegasus Mail OAUTH2 code, which submits the application for Google's approval to access live data for all GMail users: I have just done that, and wish I had not.
'Publishing the app' in Google terms requires a quite astonishing number of steps, including even having to prepare a Youtube video showing my code in action. All that would have been manageable, if excessively demanding, but then you come to the final paragraph, which I will quote here verbatim:
"Every app that requests access to restricted scope Google user´s data and has the ability to access data from or through a third party server is required to go through a security assessment from Google empanelled security assessors. This assessment helps keep Google users´ data safe by verifying that all apps that access Google user data demonstrate capability in handling data securely and deleting user data upon user request. In order to maintain access to restricted scopes, the app will need to undergo this security assessment on an annual basis, this process is called the security reassessment, also known as annual recertification. The cost of the assessment typically varies between $10,000 -$75,000 (or more) depending on the size and complexity of the application; smaller applications may see costs at a lower threshold of $4,500. This fee may be required whether or not your app passes the assessment and will be payable by the developer. We expect that fees will include a remediation assessment if needed."
Regrettably, these kinds of fees are far beyond what I can afford, given that I rely on donations from my users to make ends meet: even the $4,500 fee is well beyond what I could find on an annual basis. Google do not mention these fees anywhere else I have seen during the development process - only when you move to the publication stage do they appear — they are a kind of "sting in the tail", as it were.
So, having spent hundreds of frustrating hours developing a working OAUTH2 solution for GMail, I am defeated at the final hurdle. Google's demands mean that I am simply not going to be able to support GMail past May 31st, however much it hurts me to feel that I am letting my users down.
OAUTH2 support for GMail in Pegasus Mail is now very near - the code is complete and in active testing with the beta test team: we aim to submit the code to Google for approval in the next couple of days, and if they are as good as their word about how long that process will take, then we are aiming to release v4.81 with OAUTH and other fixes around the middle of May.
Sorry to cut things this tight - it has been quite a process.
This is possibly old news by now, but I wanted to confirm that there is a problem in v4.80 that will result in the user's spelling checker additions not being saved to disk. We have fixed this problem and a few other minor issues (in particular, a crash when attempting to insert a graphic into a message), and will be bringing out a v4.81 release as soon as we can finish putting it through standard testing procedures.
It's important to note that v4.81 won't have the OAUTH2 support mentioned in previous postings - that will move to v4.82, which will be out as soon as the OAUTH2 module is completed, and well before the GMail deadline of May 30.
Just a short update on the progress of the OAUTH2 module for GMail in Pegasus Mail (and Mercury - it will work there too for those who use MercuryD).
Progress is good - the module is well advanced and should be making its first logins to GMail here in testing either tomorrow or over the weekend.
I'm trying to produce this module in such a way that support for other OAUTH2 providers should be as easy as possible to add, and I've had to develop a number of new technologies to do this.
I am absolutely confident that this module will be finished and publicly available well before the GMail deadline of 30 May to migrate to OAUTH2. I will make further postings here as developments continue.
Just a short note to apologize for the occasional recent outages in availability of the community. My firewall system is crashing from time to time, presumably just as a result of age, and until I can replace it, the best I can do is reboot it whenever I notice the network being unavailable (which I normally do quite quickly, given the amount I use it).
I have a replacement router and have finally been able to find someone who can configure it, so with luck this won't be an issue for much longer.
I guess it wouldn't be a real release without a few issues... A few things have come to light since we released v4.80:
Pegasus Mail may crash if you attempt to disable the IERenderer HTML renderer module.
The program may report that no disk space is available when running from very large drives with hundreds of gigabytes of free space.
The spelling checker will not save any additions you make to the dictionary. Worse, it may lose any you already have. I'm deeply apologetic about this one - I really hate any problem that causes actual data damage.
We're in the process of resolving these issues and will have a v4.81 release out as soon as possible correcting them. As always, it will be announced here when it is available. Sorry for any inconvenience caused to anyone by these problems.
Pegasus Mail v4.80 has now been released publicly. Although the version number step may seem small, this is in fact a quite major release, with significant advances in SSL, HTML rendering, and especially in message editing. For a full list of what's new, check out the program's help, or visit the main site at:
To download the program, visit our downloads page at:
Version 4.9 is an important major release containing numerous significant changes and fixes.
OpenSSL v1.1.1 V4.9 has migrated to the modern OpenSSL 1.1.1 interface and incorporates an up-to-date build of OpenSSL. This is an important improvement that will allow Mercury to provide up-to-date security for quite some time.
Improved alias support V4.9 now supports improved aliasing with support for hundreds of thousands of aliases, dramatic performance improvements, and the ability to edit the alias source file directly while the program is running (no more compilation of alias files using malias.exe is required). The program's Alias editor has also been overhauled, with a new incremental search feature making it far easier to locate aliases.
Forwarding fixes Delivery errors during autoforwarding of mail are now handled much better than in previous versions, and there is no longer the possibility of mail loops resulting from the presence of undeliverable addresses in forward files.
New defenses for password probe attacks A new option in MercuryS ("Enable simplified phishing protection" on the "Compliance" configuration page) allows blacklisting any address that fails a login attempt. This significantly impacts attacks where repetitive attempts are made to guess passwords through consecutive connections.
New ClamWall build V4.90 includes a new build of Lukas Gebauer's ClamWall distributed anti-virus plugin for Mercury. The new build includes maintenance fixes and support for 64-bit versions of the ClamAV anti-virus engine.
Security fix A correction has been put in place for a theoretical exploit of the STARTTLS/STLS commands, CVE-2021-33487.
IMAP reliability improved The reliability of the MercuryI IMAP server has been significantly improved, particularly in regard to the use of iOS devices. A long-standing problem with UIDs "going bad" during a session has been resolved, and folder hierarchy files should experience fewer problems with apparent "corruption". Note that some Thunderbird users may find they need to disable "chunking" to work with this Mercury release - this is a side-effect of the other fixes we have put in place and will be addressed in a future release.
Mailing Lists: improved incremental search A new "inline" incremental search has been added in the "Membership" dialog of the mailing list editor, making it far easier to locate subscribers either by address or by name.
Improved HS.EXE (header search utility) The HS.EXE header search facility has been significantly updated with new options to print significant headers from matched messages, and the option to show only a total match count instead of showing each actual match. Haven't used HS? It's actually really useful - give it a try!
Improved debugging This one is a bit technical, but bear with me: the program is now entirely produced in a single compiler (Microsoft Visual C) where previous versions have been a hybrid of multiple build environments. What I've done is retrofit quite a lot of Mercury v5 internal coding into v4.9 allowing it to be entirely built using the one compiler. This mainly means that it becomes much easier to track down bugs in the program now, and it should be markedly more reliable as a result.
User interface improvements This one is purely cosmetic, but the hideously ugly column title bars used in lists in the Mercury UI have been toned down to something less visually stressful. Admittedly, this won't matter to most people, but it really bugged me.
Extended regex syntax now works The Mercury help describes a regular expression syntax including a number of advanced features, but it turns out that many of those advanced features had not been enabled because of an oversight. In v4.90, all the regular expression syntax elements shown in the Mercury help page will work correctly as described.
Licensing commitment Any license purchased for v4.9 will be automatically upgraded to v5 when it becomes available.
Mercury v4.9 is available from our main site's download page,
<p>Please be patient, there will be disruptions to the community service for a few days, because the server farm is being moved, this week (last week of September 2016)<span style="font-size: 10pt;"> </span></p><p>This week the lease contract where all the servers are, is closing down. JM (landlord) will tear down the house in the new year and build apartments on that area. My company is the last to move out, which has to be before october 1st. I've been putting this up as long as possible, but now there is finally a fixed deadline.</p> <p>Therefore I'm moving the servers this week. There will be disruptions to my services from tomorrow tuesday 27th at 17:00 hours (swedish time). The move of the servers start with some smaller servers, then dns, that I've already begun. But the major jobs I have planned for wednesday afternoon and night our local time.</p><p>Cheers / Peter<span style="font-size: 10pt;"> </span></p>
I've released Mercury/32 v4.80 publicly, but I won't be updating the web site or other public sources other than the community until Sunday (my time). The idea is to give the loyal folk on the community a little head-start in getting the new release. Get the release file at .
As another bonus for the community... Starting with v4.80, I've been forced to increase the price of the entry-level license (1-15 users) from $75 to $95, but if you get in and place your order before I update the web pages on Sunday, you'll still only pay the old price.
Version 4.8 is probably the most heavily-tested build of Mercury we've ever brought out, and has a huge amount of version 5 technology already in place. The next stage will be an initial release of version 5 where the user interface is completely separated from the mail engine, which means you'll be able to run the UI and consoles even on systems where Mercury is running as a service that cannot normally interact with the desktop: because this part of the conversion is already largely complete, you can expect to see this initial v5 release before the end of the year.
In the (I sincerely hope) unlikely event that you encounter a problem in v4.80, please post it in the forums here and I or one of my test team will get onto it as quickly as we can.
All my very best regards to you all,
-- David -- David Harris, Author, Mercury and Pegasus Mail.
Some of you may have read about a recently-discovered vulnerability in a product called OpenSSL that is being called the "Heartbleed bug". A good summary of this problem can be read on Brian Krebs' security blog, here:
Builds of Pegasus Mail earlier than v4.7 did not use OpenSSL and are completely immune to this bug.
Pegasus Mail v4.70 uses an affected version of OpenSSL, but the problem is not serious for client implementations - only servers are seriously affected by this problem. Pegasus Mail users can continue to run the current v4.70 build of Pegasus Mail to connect to their normal e-mail servers without any practical risk of being affected by this vulnerability. That said, I have already prepared a patched version of OpenSSL that is immune to the Heartbleed bug, and will be making it available for download as soon as the test team has finished verifying that everything still works normally with it. Pegasus Mail v4.70 users should install the patched version when it becomes available as a simple matter of prudence. Pegasus Mail v4.71, which will be released in the next few weeks, will include the patched build of OpenSSL as a matter of course.
Current builds of Mercury (anything up to and including v4.70) do not use OpenSSL and are unaffected by this problem. Mercury/32 v4.8, which is in the final stages of development at present, *does* use OpenSSL, but will be released with the patched build of OpenSSL from day one.
So, the long and the short of it is that if you're a current user of Pegasus Mail or Mercury, then the Heartbleed bug is not a matter of significant concern to you.
On September 6th, Thomas Stephenson passed away in his sleep. Many of you will have encountered Thomas over the years - for over 15 years now, he has been a major driving force behind Pegasus Mail and Mercury, particularly in supporting those people who use them. Thomas was capable of handling support loads that to this day I can barely understand: having burned myself out on support years ago, it was always a source of ceaseless amazement to me that he could continue offering his help day after day without apparently ever tiring of doing so. In this role, he will be missed.
Thomas was a vocal supporter and driver of the programs. When I had my "meltdown" in 2007, Thomas was one of the key steadying voices who helped me through the bad times, and his input into the shape and form of the programs for over 15 years simply cannot be measured. In this role, he will be missed.
A few years ago, Thomas, and his wife, Donna, visited me in Dunedin, where I live. I had the privilege of spending most of a day with them, showing them around Dunedin and having lunch with them at a little restaurant by the beach. It is surprising how few of my long-term beta testers and supporters I have ever actually met in person - a fact that makes me quite sad any time I think about it, but at least I was fortunate enough to meet Thomas. In the fifteen years that I knew him, I came to regard Thomas as a real friend, and while that would have been true even if I had never had the opportunity to spend some time with him, the memories will be that much stronger and better for having done so. And it is in this role, as a friend, that he will be most missed of all.
To the friends of Thomas R Stephenson: Tom (my dad) passed away last night from end stage lung cancer. He died peacefully in his sleep at home 2 months after his cancer diagnosis. He was joking up until the end.