UPDATE - 30 July 2008: Top marks to Ironport - they got onto me very rapidly and have been extremely helpful. It now appears that this problem is a combination of an ISP who is blacklisting his own netblocks (doh!), and a slightly ambiguously-worded error response from the Ironport appliance involved. It appears at this stage that the problem is an isolated occurrence, and that there is no cause for concern. But I want to reiterate how wonderful it is to encounter a large vendor this responsive - excellent work, Ironport.

----------------------------- Original posting below -------------------------------------

It's been brought to my attention that a large company that develops anti-spam mail server appliances, Ironport (http://www.ironport.com), may have begun rejecting mail sent by Pegasus Mail because it erroneously believes Pegasus Mail is a spam generation program. [:(] [8o|]

We're still investigating this and will keep you informed, but for now, if you find at any stage that you get a mail message returned to you with a 554 diagnostic that talks about your message not being accepted because of the "poor reputation of the MTA" you're using, please let us know on the forums.

If anyone here knows how to get in touch with Ironport Systems (their web site is essentially purely a marketing site and has no technical value), we'd also be very grateful if you could let us know.


-- David --

A new kit for the development of Mercury/32 Daemons (or plugin processes) is now available for public release from our web site. This kit allows programmers to create Daemons that integrate tightly into the Mercury environment, extending its capabilities. As examples, the SpamHalter, GrayWall and ClamWall plugins shipped with Mercury are all Daemons.

For more information on the Mercury/32 Daemon Development Kit, please visit our web site at .

Cheers!

-- David --

Mercury/32 V4.62 is now available for public release.

V4.62 fixes a problem in v4.61 where sites who had not turned on the new "DST-Proof UID" feature in the MercuryP POP3 server could get duplicate message downloads under certain circumstances. It also includes some adjustments to the installer program during upgrades, and has some minor internal changes to the Daemon interface for future development.

Mercury/32 v4.62 can be downloaded from our official download pages, at .

Cheers!

-- David --

Mercury/32 v4.61 has now been released for public consumption - please visit for more information and downloads.

I apologize for the rather delayed release - we've had a very frustrating sequence of last-minute problems come up, all of them fairly small, but significant enough to justify holding the release while they were fixed.

The new feature list for this release appears at the end of this message.

Cheers to all!

-- David --

V4.61 includes a large number of minor fixes (over 300

by our count), and some notable new features:

• Notifications and alerts

   If you purchase (or have already purchased) a

  license for Mercury, you can now enable automatic checks

  for new releases and updates, security bulletins and

  general information about the program. To take advantage

  of this feature, see the new Alerts and notifications

  option on the Mercury Configuration menu..

• Lingering Mailboxes  This

  is a new performance option for the MercuryI IMAP server,

  especially aimed at people using "stateless"

  IMAP clients such as webmail packages. When it is turned

  on, Mercury defers breaking down the memory image of

  the mailbox when an IMAP connection terminates; if a

  new connection for the mailbox arrives before the standdown

  period has elapsed, it can be reused at once, hugely

  reducing the startup time for IMAP connections. Enable

  this option in the "Files" page of the "Core

  module" configuration dialog.

• IMAP INBOX now cached

   The Mercury IMAP server now caches the IMAP inbox,

  meaning that connecting to it will be significantly

  faster than in previous versions.

• IMAP Server performace

  improved

   Server performance, particularly

  when opening large folders, has been dramatically improved.

• DST-proof POP3 UIDs

   Because of a long-standing bug in Windows, the

  MercuryP POP3 server in the past reported different

  UIDs for messages after a change in Daylight Savings

  Time, resulting in clients re-downloading messages they

  had already seen. This problem has been fixed in v4.61,

  but the fix is disabled by default, because enabling

  it will cause one last re-download. You can turn it

  on whenever you're ready in the MercuryP configuration

  dialog.

• MB_MLSS heavily improved

   MB_MLSS, the MercuryB module that allows web-based

  management of mailing list subscriber settings, has

  been heavily overhauled. It now has options allowing

  subscribers to retrieve their passwords if they have

  forgotten them, and to change settings for all lists

  to which they are subscribed. As well, users can now

  select lists from drop-down controls instead of typing

  in their names (if you have 50 or fewer lists), and

  the service manipulates mailing lists directly, rather

  than going through the Maiser mail server interface.

• Mailing list password auto-assignment

   Mercury's mailing list manager can now be instructed

  to auto-assign passwords for new subscribers to mailing

  lists. This, combined with the new capabilities of the

  MB_MLSS module (see above) makes mailing list management

  easier and more secure.

• SMTP server enforces size

  restrictions

   In previous versions of

  Mercury, the SMTP server could be told to refuse incoming

  messages larger than a particular size, but only if

  the connected client used the ESMTP SIZE declaration.

  In v4.61, MercuryS now refuses *any* message larger

  than the size you specify, whether or not there is a

  SIZE declaration. This change *might* confuse some older

  SMTP client programs (we expect this to be a very rare

  occurrence if at all), but has become increasingly important

  in the age of spam and mail-borne viruses.

• POP3 Server completely

  overhauled

   The MercuryP POP3 server

  has been totally overhauled, and is now substantially

  faster than in previous versions.

• POP3 login-time listing

  constraints

   This powerful new feature

  allows users to control the messages the Mercury POP3

  server will show them by adding a simple command to

  their POP3 username... For example, if you only want

  to see urgent messages from the "pmail.com"

  domain, you would login to your POP3 mailbox as username

  (urgent, from=@pmail.com). The constraints that are

  available are described in more detail in the Mercury

  manual and online help. We anticipate this feature

  being especially useful for people who use cellphones

  or other low-grade connectivity devices to check their

  mail.

• MSendTo commandline mailer

   This new utility allows you to send mail from

  the commandline. It is quite sophisticated, and can

  generate a wide range of message types, including digests

  and unlimited numbers of MIME attachments. MSendTo can

  be used in scripts or called from programs to send mail

  via Mercury.

• Threading in the core module

   In the past, the Mercury core module has been

  single-threaded (meaning that it can only ever be doing

  one thing at a time). With increasing processing of

  mail via external processes such as Mercury policies,

  SpamHalter, Content Control, filtering rules and so

  on, the time it takes to process a message in the queue

  has been getting longer and longer. As of v4.61, the

  Mercury core module now supports limited threading (it

  runs up to seven worker threads), which significantly

  improves queue throughput on heavily-loaded systems.

• Many, many fixes,

  including problems with IMAP UIDs being lost or duplicated

  after crashes, problems with the loader queue quarantine

  message being delivered multiple times and others.

As well, a comprehensive new developer guide and sample

code for people interested in developing their own Mercury

Daemons is nearing completion and will be made available

in the next few weeks: an announcement will be made here

when it is released.

Rolf Lindbys HttpServer for Mercury is now availiable for download:

 As is another community add-on for Mercury, the Mercury Access Control Editor: http://community.pmail.com/files/folders/community_add-ons_for_mercury/entry4929.aspx

 Njoy

You probably miss the snow that some of us have up north at this time of year ;-)

Commercial-use licenses for Mercury/32 v4.52 and later can now be purchased and downloaded online, here:

  

Licenses can be purchased by PayPal, credit card, or on invoice.

Thank you in advance for your support.

Cheers!

-- David --

Hello!

Fortunately, it seems that the routing problems have been solved. can now be reached again.

In recent days we see a lot of attempts to utilize the issue that the above patches mend.

If you notice within Loader.Log (found in your server directory) that recently states multiple rows of "Restarted Mercury after apparent abnormal termination" you should suspect that you have been hit by attempts of exploit. Within MercuryS.Logs (depends on how you have set logging) you may find parallel log entries (same date and time as Loader.Log entries) stating multiple AUTH CRAM-MD5 - then you know you are hit - and should as soon as possible mend your system.

Lastly, within the MercuryS console window, you may see a connection as the attached image, hanging for a long time, - then you know you have been hit by people trying to exploit your un-updated Mercury.

So - Regard the updates as highly critical since it forces your server to restart if you are using the loader utility.

I personally thank David for his expediate attendance to this issue.

A patch for MercuryP v4.51 is now available at .

The patch addresses the UIDL response to issue a NUL list instead of issuing an error when a maildrop is empty.
The RFC regarding this response is vague, however the previous error response from Mercury when the maildrop is empty causes some PDA POP3 implementations to fail.

Mercury/32 v4.51 is now publicly available.

Although on the surface v4.5 will not appear markedly different from v4.01, "under the hood" it's quite a different story. The code has been heavily reworked in almost every area, focusing heavily on robustness, reliability and performance.

A download link and list of new features in v4.5 is available at

    http://www.pmail.com/m32_451.htm

Starting with this release of Mercury, the licensing model for the program has changed. Mercury remains completely free for non-commercial use, but commercial users will need to purchase a license if they wish to continue using it after a 60-day evaluation period. We have attempted to produce a licensing program that is both very inexpensive, and completely non-intrusive. Details and pricing can be found here:

   http://community.pmail.com/pmail/MercuryPricing.aspx

Please note that if you have a current support subscription at any level under the old Pegasus Mail Support Consortium arrangement, you are automatically entitled to a Mercury site license at no charge - please contact me directly to arrange this.

A personal note: I'm acutely conscious that it has taken an abnormally long time to get this release done. One of the lessons I have learned from the problems in getting v4.5 complete is that I need to open up the beta testing process so that more people have greater access to betas and patches more often. I will be developing a strategy for this over the next couple of weeks.

Any problems or issues arising from this release can be raised either on the public mailing list at bama.ua.edu, or in the Community forums at our community web site, http://community.pmail.com.

Cheers!

-- David --

I apologize in advance for what might seem like shameless panhandling, but I could use some assistance...

Is there anyone out there with a Novell NetWare 6.5 Server+10 user license (or larger) that they no longer use and might like to donate to a good home?  The declining use of NetWare means that the costs of sustaining my subscription to Novell's developer forums is becoming unjustifiable, but if I cancel my subscription I'll need a formal license I can install to allow for ongoing support and any further development that might be required.

Alternatively, if there is an organization out there that feels generous enough to donate the cost of a license, I'd be most grateful for the support.

If you can assist in either way, please .

And now, back to normal service...

Cheers!

-- David --

As part of the restructuring of the way Pegasus Mail and Mercury are distributed and funded, the manual sets are now being made available free of charge to all users who would like them.

Current manuals for both  and Pegasus Mail can now be retrieved from the download.

At the end of January 2007, Microsoft will be introducing their next release of Windows, Windows Vista. Vista is a major revision of Windows, and it is likely that it is going to break or affect the vast majority of existing third-party Windows software (presumably by design). This page identifies known issues with Pegasus Mail, Mercury and Windows Vista as of January 3rd 2007. Note that none of the issues identified below is major, and we are actively working on fixes for them.

Pegasus Mail: For reasons not adequately explained, Windows Vista does not include a functional help system (WinHelp has been removed, and HTMLHelp has been crippled). This means that you will not be able to use the Pegasus Mail help system unless you download WinHelp from the official Microsoft site (we are forbidden to distribute or make it available ourselves). We are working on developing our own help system to work around this problem. Vista also places new restrictions on applications wishing to perform default system functions (in Pegasus Mail's case, acting as the default mail program). You will probably not be able to use Pegasus Mail as your default mail program for mailto: URLs under Vista until we produce registration code that complies with the new Vista rules. Finally, Windows now pops up a spurious and annoying warning any time you run an application that does not have a Microsoft Authenticode digital signature from a shared volume. Unfortunately, getting an Authenticode signature is an expensive and arduous process, but we will do so as soon as we can (note that this last issue is not specific to Vista - it will also occur on any Windows XP system where Internet Explorer 7 has been installed).

Mercury/32:  Mercury/32 suffers from the same Microsoft-induced help problems under Vista as Pegasus Mail, but as noted above, we are working on a replacement help system to fix this. Aside from that, we are not currently aware of any other specific problems under Vista, unless you have chosen to install Mercury into the Windows "Program Files" directory tree (not the default for the installer). Testing is continuing on Mercury, however, and we will update you here with anything more we find.

David Harris,
January 3rd, 2007.

Pegasus Mail v4.41 is now available for public distribution in four languages (English, German, French and Italian). Originally I had not intended there to be any further releases in the v4.4 family, moving instead to development of V5, but some compelling new capabilities have persuaded me to bring out this release, which may prove to be one of the more significant in quite some time. Please click here for more information on v4.41.

Cheers / David Harris

For Mercury/32 PH Server (MercuryH) and PopPass Server (MercuryW). We have recently been informed of "script-kiddie" exploits circulating in the wild that target these Mercury/32 modules, and although we have only been able to confirm the MercuryH exploit, we have prepared precautionary patches for both modules - all Mercury/32 sites that use either of these modules under Mercury/32 v4.01a, Mercury/32 v4.01b or any Mercury/32 v4.10 beta should consider it mandatory to download and install the appropriate patch on their systems.

As discontent with Microsoft's "business practices" grows, we have seen unprecedented interest in alternative solutions for operating systems and applications. As a natural consequence of this, I have received numerous, or maybe even innumerable requests for a Linux version of Pegasus Mail. As a corollary to these requests, I have had a lot of people suggest that I also move to an Open Source basis for maintaining the Pegasus Mail and Mercury source code.

In the past, I have taken a cautious "wait-and-see" approach to the idea of Open Source. I am now willing to accept that it is a valid model, and that it is producing some genuinely excellent packages (such as FireFox, of which I am inordinately fond). Ideologically, I believe that Open Source and I are a good match, and I would like to consider going that way.

There are still some major problems with the idea of going Open Source though: the most important is "How do I survive in an Open Source environment"? While Pegasus Mail and Mercury do not require a huge amount of money to develop and support, the fact remains that they *do* require a level of funding, and I am not entirely sure how this would work within an Open Source model. I feel it is significant that the majority of Open Source initiatives are either funded externally (Mozilla), or basically not funded at all (OpenLDAP, OpenSSL): it seems to me that while Open Source is an excellent technical solution to the problem of large-scale development using widely-spread teams, the area of Open Source business modeling is one that still has not been completely resolved.

The other major issue with Pegasus Mail is that it uses a proprietary third-party product as its core editor, and I would not be able to take that product with me into an Open Source environment. The same problems do not exist with Mercury, because I have written every line of the package myself, but with Pegasus Mail, the problem is significant.

So, there you have it: I am now favourably disposed to the idea of moving towards Open Source, but have to overcome some important issues before I go down that track. I am actively considering the issues and hope I can find workable solutions (such as a large, friendly, wealthy sponsor) in the not-too-distant future.

Hopefully this update to my position will reduce the amount of hate-mail I have received in the last three years from Open-Source zealots. While I understand the passion and admire the zeal of these people, I would suggest that a positive approach is always going to work better than trying to rip out my liver and feed it to the dogs. After all, this *is* my baby - I have been working on these programs and providing them free of charge for over fifteen years now, and I don't believe it's too much to ask if I expect a little basic human courtesy.

If you have suggestions and are willing to present them to me in a positive, encouraging manner, I will be happy to receive them.

David Harris
Owner/Author, Pegasus Mail and Mercury Systems,
April 20th 2005.

A v4.01b patch is now available for Mercury/32. This patch fixes some buffer overflow vulnerabilities and memory leaks in the MercuryI IMAP server, and extends the transaction level filtering capabilities of the MercuryS SMTP server. All sites running v4.01a should consider this a mandatory upgrade.

In their annual "World Class" awards, the major United States computing magazine PCWorld has chosen Pegasus Mail v4.01 as their best e-mail package for 2002. to view their award list.