Pegasus Mail & Mercury

Mercury with OpenSSL support

David Harris — Tue, 20 Nov 2012 12:35:00 GMT

Just a short update for now - I realize I have been more than usually quiet and remote recently, and for that, I apologize - I have had a significant amount on my plate.

Over the course of this year, I have completely rewritten my TCP/IP code (the part of the program that actually connects to the Internet), to make it more modular, more reliable, and more maintainable. A huge part of this process has involved moving away from the third-party package I previously used to handle SSL/TLS secure connections and instead using the industry-standard OpenSSL suite. With this code complete and tested, I am now well into reworking the various Mercury protocol modules to use it. This has a number of ramifications: firstly, SSL support should be much more reliable, and should work correctly with a much wider range of external clients and servers. Secondly, it will be much easier to keep the SSL components of Mercury up-to-date, and only a single point of change will be necessary at my end to update all the modules, compared with the way it is now, where I have to update each module separately. Thirdly, you will be able to use "real" certificates for SSL, and Mercury will be able to generate the necessary signing requests you can give to certification authorities (CAs). A useful side-effect of the process is also that TCP-based operations in Mercury will be somewhat faster than they have previously been.

Other developments in Mercury are proceeding, most specifically the separation of interface from server process, and the reworking of the help system to use my own help engine: these processes, however, are taking longer than I would like, and it seemed best to bring out a version with the new SSL code as soon as possible. As a result, as soon as the Mercury protocol modules are all converted over to the new TCP/IP libraries, I'll be giving them to my test team for a short round of testing, the aim being to release an interim cut of Mercury (tentatively to be called v4.8), either late in December or early in January. Other developments will follow in due course over the subsequent months. Licensees need not be worried about this update - all existing licenses will continue to work with it without change.

Again, my apologies for the lack of regular updates: I keep saying I'll get better at it, yet I never seem to be... <slightly embarrassed grin>

All my very best to you all.

Cheers!

-- David --

True Confessions

David Harris — Sat, 21 Jul 2012 02:09:00 GMT

Sometimes when you're in a hole, it can seem as if the effort required to climb out of it is just more than you'll ever be able to manage, as though the task is just too hard, with too little reward at the end, and all you want to do is to give up and rest. I found myself in such a hole at the start of 2007.

Put simply, I was completely burned-out. I had been working on Pegasus Mail for 18 years, Mercury for 14, and my fortunes were in head-long decline. Money was in short supply, collections of old source code needed huge amounts of updating, and I had simply answered too much mail.

I probably need to explain what I mean by "answered too much mail". From the earliest days of Pegasus Mail (1989 was when it sent its first ever message), I've always kept an open mailbox: unlike the lead developers at large corporate software firms, I don't have a carefully-guarded e-mail address - the same address that people could use to mail me in 1994 (the only time I've ever updated it) can still be used today, and I make no attempt to hide it. The price of this has been a veritable deluge of mail over the years, with everything that accompanies that - there has been praise, there has been hate, I've made friends and occasionally lost them, but above all, there have been bug reports.

Now, for a software developer, bug reports are like accusations of failure: when you're as involved in your work as I am, each report is sharp and painful like a paper cut - it's very hard to pull back emotionally and see them as the positive things they actually are (because they allow you to make your work better). Each one knocks you back a little, and after 17 years of dealing with them, I had reached a point where I was almost phobic about them. At the start of 2007, I was in a mental and emotional place where I actually *dreaded* opening my new mail folder. For someone who has always regarded communication as being the gift I most wanted to give people, this was an ironic and unnatural position to be in.

January 2007, then, was when I faced a kind of "mini crisis" in my life - not quite a breakdown, but it was a very, very unhappy time. Somehow, though, with help from my friends, my very dedicated beta test teams and from a hardcore group of committed users in the Pegasus Mail and Mercury communities, I clawed my way out of the pit. But to do so, I had to make some changes, and to accept that there were things I just couldn't do any more: in particular, I simply couldn't handle the same volume of mail that I had up until then.

So this, then, is my apology if you have found me unresponsive in the last few years. I am deeply conscious that I do not communicate with my community as well as I either should, or would wish to. Cutting down the amount of mail I handle has been an essential part of the process of easing myself back into a working state, but however unavoidable it might have been, it's still an adjustment I don't like. Increasingly, I am relying on my beta test team and supporters to ensure that things I really need to know get escalated to me through channels I can sustain. That's one reason why this community site is such a god-send for me - even if I don't participate here as much as I might wish to, people I trust implicitly *are* participating all the time, and they regularly refer issues to me, thereby reducing my communication burden, for which I am enormously grateful.

Five years on, and the start of 2007 now seems mercifully distant. After a long period of time where I didn't, I am now actually enjoying doing the work again. The dismal process of updating and modernizing old, clunky code is now mostly done, and new, more interesting projects give me something to look forward to each day. No matter how quiet I may seem to be, rest assured that I am anything but idle: good things are happening in Dunedin - indeed, it's hard for me to tell you how frustrating it is that the time required to bring them to completion seems so great. I guess this is just the inevitable evolution of software: user expectations are now so much higher than they were ten years ago, and the environments richer, more complex and more difficult: doing even very small, seemingly simple tasks can now take a depressingly long time. I am, however, very excited by the things I'm producing at present, and can't wait until they're ready for me to be able to show them to you.

The only real problem I haven't resolved from the dark days of 2007 is that of funding. Initiatives like the Pegasus Mail Thousand have basically failed because of my personality - I simply don't like asking for help, because I don't like the idea of being a nag or a nuisance, and because a core part of the New Zealand psyche is the idea of not being pushy, not promoting yourself. I am, in a sense, my own worst enemy.

I've never been very good at the whole "let's make money out of this" aspect of software - it's not the primary reason I do any of this: my clear preference would be not to have to ask for anything - to make Pegasus Mail and Mercury into the pure gifts I would like them to be. But I have to eat, as well, and that's getting harder and harder. In spite of my own inertia and poor fund-raising skills, though, there are still quite a few people who, even without prompting or reminders, still send donations for Pegasus Mail: I see every donation, and the morale boost they provide is as valuable as the money they provide: my heart-felt thanks go out to you all. I still live in the quaint, naive hope that some day a corporation or foundation might offer some kind of sponsorship - after all, the amounts required are actually pretty tiny - but I guess this is fantasy in 2012. I'm clearly going to have to do something, but at this stage, I don't know what it is.

So, there it is, straight from the heart. I live for the day when I can again offer something exciting and of real value to my community - after all, they're - no, "you're" the number one reason I keep doing this.

All my very best to you,

-- David --

How to make a developer feel wanted

David Harris — Fri, 03 Feb 2012 01:55:00 GMT

I received this message today, completely unsolicited, from Keith Harris, a long-time user of Pegasus Mail.

-------------------- cut here --------------------

Your program fails sadly now big time.

I add an email to a distribution list and also to the safe sender list but it still comes up as junk mail.

This is no longer a program anyone wants on their system.

I have tried to stay true to you but if this crap keeps on gettiing worse, as it is, I will move away and no longer recommend you.

David, the recommendations I personally made to you were never implemented.

V 6.43 includes NONE of my recommendations.

Get it right sunshine or get lost.

Keith [Harris]

-------------------- cut here --------------------

I am very old-school, and it shocks me to think that *anyone* could send a message like this - it was like a physical blow.

Nonetheless, it brings home to me forcefully the fact that I may be simply flogging a dead horse. The last four years have been terribly difficult for me, doing dreary code modermization and surviving on almost no income, purely because I believed there were still users out there who valued my work and for whom it continued to provide benefits. But maybe I'm simply wasting everyone's time continuing work on Pegasus Mail? There are days when I really feel like I'm living in a total vacuum, and it's now nearly impossible for me to tell whether or not I'm actually doing anyone any good any more.

If you feel the time has come when I no longer serve a useful purpose, when my work no longer has enough worth to continue labouring on it, now is certainly the time to tell me - if I'm just prolonging everyone's misery, for Heaven's sake, let me know.

-- David --

Mercury development

David Harris — Wed, 15 Jun 2011 03:29:00 GMT

With the release of Mercury v4.73, it became clear that it was time to start work on major developments within Mercury that are long overdue. The most obvious and immediately necessary of these is the complete separation of the user interface from the working processes at the core of the program. Under Windows 7, Windows Server 2008 and, we presume, upcoming versions of Windows, service processes can no longer have user interfaces that interact with the desktop, which makes configuring Mercury in these environments a bit fiddly. What is needed is a user interface that can run anywhere, connecting to the working processes to configure them: this would allow you to configure the copy of Mercury running on the server in your machine room from the comfort of your own desktop PC, or from home if there was an after-hours problem. Allied with this is the need to manage mailing lists remotely as well - I am building the new remote facilities in such a way that there will be a simple application allowing list moderators to manage just the lists for which they are responsible from anywhere on the Internet. For unlicensed copies of Mercury, the program will continue to run as an application with the full user interface built-in - and indeed, if you have a license, you can run the program as an application with its full UI *and* still configure it remotely. This ability to have the UI or not as you please is quite powerful and took quite a bit of effort.

After quite a bit of development over the last few months, Mercury is now in a state where the separation of UI and working core is complete. It is now possible to run Mercury as a service with no user interface, and configure it using the full user interface running as a separate process on the same machine: from this, it is a fairly short step to allow the configuration to be fully remote as well. After that, it's just making the consoles for the various processes available remotely and the job will be effectively done. One of the things that makes the process more time-consuming is the need to ensure that very high levels of security apply to the process, so everything is getting bullet-proofed and double-checked to that end.

In other areas, Mercury, like Pegasus Mail, will be migrating to use the industry-standard OpenSSL library for its secure communications, which should improve interoperability and will bring the new ability to use "real" SSL certificates (i.e, ones issued by CAs such as Verisign). As I remarked in a recent Pegasus Mail blog posting, the development of the new common message store for both programs is proceeding well and should finally come to fruition this year. A side-effect of the new message store will be that it will be possible for me to rework large parts of the MercuryI IMAP server that are currently limited by the old message store. The aim is to produce faster, more reliable IMAP service with support for a number of the more important modern IMAP extensions, such as SORT and IDLE.

Well that's it for now - time to get back to working on any of the thousands of things I seem to have piled up on my desktop. All my very best to you all!

Cheers!

-- David --

WinPMail v4.62 and beyond

David Harris — Wed, 15 Jun 2011 03:07:00 GMT

Pegasus Mail v4.62 is now in the late stages of preparation for release: it primarily works around some issued introduced by Microsoft with the roll-out of Internet Explorer 9, but has a range of small bug fixes as well. It should be out within a couple of weeks of this posting.

In the longer term, the main focus in Pegasus Mail is now moving onto new functionality, in particular the new Pegasus Mail contact manager, which is an ultra-powerful replacement for the now antique Pegasus Mail addressbook system. This code has been developing over the last few months and, like so many things these days, has ended up being quite a bit more work than I anticipated, mostly because once it became clear how capable it was going to be, it also became necessary to start devising a user interface that would make the most of it. I've ended up writing a lot of new UI code, including some stuff that is actually pure out-and-out fun... I probably need to explain that. As software projects get larger, you spend more and more of your time fixing bugs, modernizing code, and generally doing background tasks that end users will seldom even be aware is there; in all honesty, this process is humdrum and quite soul-destroying, but it's unavoidable if the program is to remain viable. The real pleasure in developing an application like Pegasus Mail is in the addition of new features that offer direct, visible benefits to my community - that's when working on it is fun again. The new contact manager definitely falls into the "fun" category - in one mad orgy of development, the program is going to go from having an antiquated addressbook that is barely usable in the modern world to having a contact manager that many sites may be able to use as a full-blown CRM system.

The other major forthcoming change to the program, the new backing message store, has been on hold for a little while as I fought fires in other places, but development is now proceeding on it again: I'm now working extensively on the IMAP portion of the message store. IMAP users should find the new message store much faster at most tasks, because it will be able to take advantage of IMAP extensions and features that were not previously possible, and it will also be possible to use Pegasus Mail as an IMAP-only mail program if you wish. This will be accompanied by new SSL code using the industry-standard OpenSSL libraries, for greater stability and compatibility over secured connections. I feel like I've been talking about this message store forever, but when I look at it and realize that I've written over 100,000 lines of highly-organized code already, I realize that in its own right, it is already a considerably larger project than many full-blown software packages out there. It's frustrating putting in so much effort without feeling like I have much to show you yet, but the work will be worthwhile in the end.

On a slightly gloomier note, looming over all of this is the shadow of considerable financial difficulty... *sigh*. I cannot deny that the last couple of years have been financially disastrous in almost every way, and it's a constant struggle to find ways of making ends meet. I'll be sending out a plea to the Pegasus Mail Thousand soon and hope that as many as people as possible will be able to respond so I can carry on doing what I've now been doing for over 21 years.

It's Winter in New Zealand now, and cccccooooolllldddd.... To all of my antipodean colleagues, wrap up and keep warm, and to those of you lucky enough to be basking in the warmth of northern climes, have fun in the sun!

Cheers to you all!

-- David --

Significant changes looming for Mercury interfaces

David Harris — Wed, 09 Jun 2010 00:27:00 GMT

In response to considerable user demand, I have begun work on a significant change to the way Mercury manages domain names. In all versions of Mercury up to and including the current ones, it has been possible to have multiple domain names serviced by a single Mercury instance, but all such domains shared a single user database (so, if you had a user called "john", then that user would appear in all the domains serviced by Mercury). Over time, it has become desirable to allow different domains to have their own users and mailing lists, separate from other domains on the server. There has also been growing demand for specialized types of domain, such as "MX Domains", where a Mercury instance can act as a secondary mail server for a domain that is not otherwise local (i.e, has no local users on the Mercury system). Finally, with a move to truly separate domains, it makes sense to allow domains to have their own specific filters, content and spam controls, whitelists and other mail processing controls, something not possible in the current implementation.

Providing these and other new capabilities will require considerable internal restructuring of the way Mercury works, and as an unavoidable consequence, certain internal Mercury API calls (the special functions made available to developers of third party expansion and plugin modules) are going to be affected. It is my aim to keep the disruption to the interfaces as small as possible, but there is inevitably going to be the possibility that some some existing third-party Mercury Daemons might require some adjustments. If you are a developer of Mercury Daemons, I would like to invite you to join the Mercury beta testing process so you can be kept informed of the changes well before the new code sees public release - please mail me directly, using my David.Harris@pmail.gen.nz address if you would like to take part.

Twenty years and counting...

David Harris — Thu, 11 Feb 2010 00:44:00 GMT

The very earliest mail message I still have that was sent by Pegasus Mail is dated February 13th 1990: it is from me, to me, has the subject line "A little test", and a body that simply says "what are you doing for dinner tonight?". I know there were earlier messages than this, but because I had no sense of posterity, I never made any attempt to keep them - I really didn't think Pegasus Mail would be around for more than a couple of years, just like any other piece of software.

So, a bit like a puppy whose actual birthday is not known for sure, I have always celebrated Pegasus Mail's birthday on February 13th, except on years when that was a Friday (because I'm a little superstitious). Most years, the celebration consists of nothing much more than me thinking "Gosh, have I REALLY been doing this for xx years?!?", but this year seems worthy of a slightly more public observation - this year, Pegasus Mail turns 20. Scary though it seems, I have users of my program who were not yet born when it sent its first message. Even scarier is the thought that when I started doing this I was 28, and now I'm 48: I've spent not far off half my life working on Pegasus Mail and its constellation of related programs, documents, interfaces and technologies.

It's amazing to me, sitting here in my sunny little office in Dunedin, New Zealand, to think of everything that has happened in those 20 years - the people who have been involved, some who have stayed and some who have moved on; the lows and highs (and there have been plenty of both); the changes, both to the programs and to the world they live in... In fact, it's those changes that always astound me most, I think: when I started, the Internet was barely known: in New Zealand, "The Internet" had just recently moved from being a single 9600bps (that's "bits per second") leased line serving the entire country to an incredible 64Kbps ("kilobits per second") line - still serving the whole country... E-mail was the most exciting new thing I'd ever seen, the World Wide Web didn't exist at all, there was no such thing as a "URL", and the idea of "spam" was a kind of silly joke that nobody thought would amount to anything more than a mild, passing nuisance... In 1990, I was still occasionally using a modem to access BIX (the Byte Information Exchange), which was a "bulletin board" - an idea now totally lost in history. These things seem unreal now - distant and almost incomprehensible: indeed, there are days when I feel like Methuselah, impossibly old.

How different the world is now. E-mail is like bread - we consume it without even thinking about it any more, the World-Wide-Web has become the largest corporate battleground in history and most of the Western World spends a sizable portion of each day immersed in it; URLs are now more commonly-seen than phone numbers, spam constitutes more than 90% of all the mail circulating the world, and nobody under 30 would probably have even the faintest idea what a "modem" or a "bulletin board" were.

In almost any other field of human endeavour, 20 years is not a long time - it's not even a single human generation... But in the Internet, 20 years is near to eternity, and for 20 years, Pegasus Mail has been out there riding the clouds, pulling me along with it like a slightly bewildered Bellerophon. The program has always seemed to have something of a personal existence all of its own - there are times when I have really felt as though I was just along for the ride (probably more frequently as the program has become older). I rather like that, though - the sense that it's not just an outgrowth of me, but something that reflects the nature of a community of users - there's something personal about that, and I've always felt that many of those who have used Pegasus Mail for a long time feel it too.

So now we're about to enter the third decade of Pegasus Mail. Will it make it to 30? Who knows, but I really hope so: I still enjoy working on it, and even though the Pegasus Mail Thousand hasn't had entirely the response I might have hoped for, I'll keep working on Pegasus Mail and Mercury for as long as I can. I hope you'll join me for the ride, so we can watch together how the world will change again, but for now, if you are of a drinking disposition, think about raising a glass to Pegasus Mail on February 13th, as it celebrates this major milestone in its life: I certainly will be.

All my very best wishes to you all,

-- David Harris --
February 11th 2010.

The best of the festive season

David Harris — Thu, 24 Dec 2009 10:58:00 GMT

Just a short post to wish everyone a wonderful festive season - have a Happy Christmas, and let's look forward to a prosperous New Year - in fact, "New Decade"! (Scary, isn't it).

Pegasus Mail v4.52. with fixes for Windows 7, is now ready, and will be out between Christmas and New Year. In the New Year itself, January is likely to be quiet on the public front, but things should start heating up in February.

To everyone who has supported me this year, especially my beta test team and all those who have signed up for the Pegasus Mail Thousand (about 500 so far), my thanks for all your help and backing: please accept my warmest wishes and have a wondeful break.

Cheers!

-- David --

The next generation of Mail Store

David Harris — Tue, 20 Oct 2009 12:00:00 GMT

Well! It's been a while since I've written here - in fact, I admit I'm a little shocked how long... Oops: and I had promised myself I wouldn't have these long absences any more.

In my defense, I should say that I have been far from idle. Since the release of Pegasus Mail v4.51 and Mercury/32 v4.72, I've begun work on what is probably the single biggest change in the core innards of the programs since they were introduced: I am rewriting the Mail Store. Let me clarify that: the move from my old Borland C compiler to Visual C was a huge effort, but it was mostly about porting and tidying the existing code: what I am doing now is rewriting the deepest core of the program from the ground up.

The "Mail Store" is that part of the program that manages folders, messages, attachments - in fact, anything low-level to do with any mail message you can read in your copy of Pegasus Mail. The Mail Store currently in use in Pegasus Mail is very old - much of it has not changed markedly since the Windows version of the program was originally released in 1993. While it works quite well, it has become increasingly difficult to maintain, and nearly impossible to expand: it also does not lend itself to being made available to third-party developers (such as extensions writers). More pertinently, though, the Pegasus Mail code was not an entirely happy port to Mercury - many of the lingering performance issues associated with the MercuryI IMAP server can be directly attributed to the age of the Mail Store code.

The aim of the Mail Store rewrite is to have one common library used by both programs, and to apply the lessons I have learned in nearly 20 years of writing this type of program to producing something that will have industrial strength and high performance. This development is the basis for all the good things I have planned for both programs - a high-speed webmail interface for Mercury, new secure and encrypted folder formats for both programs, and much faster, more robust IMAP support that can take advantage of IMAP extensions when they are available (something the current code cannot easily do). The new Mail Store will also be directly available to extension and Daemon developers - for the first time, they will have access to the Mail Store that is exactly equal to that enjoyed by Pegasus Mail and Mercury themselves.

The process is going excellently, and is now well advanced. The target I had originally set myself was to have the new Mail Store essentially finished and ready to bolt into Pegasus Mail by the end of this year: past experience told me that I was probably being optimistic (it's symptomatic of how difficult the industry has become that I can't remember the last time I was able to hit a deadline I set myself) - but to my surprise, it's actually looking as though I may be on schedule this time. Last week, the new code initialized itself, then scanned and read a new mail folder for the first time: this week, it has successfully performed a comprehensive MIME parse on a new mail message... Each day brings new achievements, and a sense of satisfaction that things are finally being done in a modern, future-proof way.

Well, that will do for now: as soon as I can, I'll write another post here about The Pegasus Mail Thousand and what it's going to mean to the sustainability of the programs, and I'll make it my goal to post much more regular progress updates on what's happening behind the scenes.

All my best to you all!

Cheers!

-- David --

Browser performance

Peter Strömblad — Tue, 11 Aug 2009 09:44:00 GMT

Today a user called and complained, that their WebMail is so slow and they want another solution.
That's a normal reaction.
There's always something better isn't there? - or - the analogy - my computer is weird, let's re-install !

NO - as a sysop, technician, programmer and curious one too - I always want to look under the hood. As a teenager I did take things apart, frequently too, resulting in a number of loose screws when trying to reassemble an old car, my bike, the lawnmover, chainsaw, another lawnmover - and so on.

SO - what to respond to the end-user with the slow webmail. They do experience a problem, and of course there is a solution, or multiple - but first what is the cause or causes? Without knowing the cause, why take action.

EXAMINE - is what I did. The inbox contained 650MB and thousands of e-mails - over IMAP - now that's slow no matter what server/client solution we'd choose. Other reasons, massive amounts of folders.

CURE - Organize!, throw out the old - do a traditional cleaning. No one likes to live in a mess, with years of old stuff - that's why we clean our homes regularly. So keep the inbox clean, only with the messages that you need to work with/reply to. Catalog the rest, off the server in the client imap. If you worry about backup - you can always synchronize a local client IMAP folder with the server folder at any time.

BROWSERS matter too - and in this case, as well as with this community site - webmail today depends heavily on javascript. So I did a quick search, and remembered a company name/brand (dunno) futuremark that we used way back to benchmark. And they showed up with this do-it-yourself test at http://service.futuremark.com/peacekeeper/ which I couldn't resist in testing. The traditional overall results rank the browsers like this:

but is that really interesting to me? -

NO - what I use is not javascript graphics to any extent, but data and text. So the community index is much more interesting (besides compatibility of-course) and then the results are quite different. So here comes my rank:

Rank	Browser	CommunitySpeed	text parse	data	average	FutureMark Total
1	Safari v4.0.2	1732	2557	2880	2390	2129
2	Chrome v3.0.195.6	1662	2455	2455	2191	1789
3	Opera v10.0	1591	969	489	1016	1138
4	Opera v9.64	1490	476	503	823	836
5	Firefox v3.5.2	1302	895	1663	1287	1196
6	Explorer v8.0	504	561	424	496	480

FINALLY - does the javascript perfomance mean all? - no of course not - many more aspects of your favourite browser is of importance, and they're not all that compatible with standards, and thus behaves differently. But the test shows one very interesting aspect - different browsers do different things with differing speed and quality, and since we have the possibility to choose, why not choose the tool in each circumstance that does the job best, especially since they do not cost you a thing.

Network efficiency and spam fighting

Peter Strömblad — Fri, 29 May 2009 21:53:00 GMT

We have Symantec SMSSMTP, as our mx hosts - charge nothing for the service, and it has filtered a total of 96% spam, straight down the waste bin. Does it do it's job? Sure does! - Should I complain? - yeah, because I expect more from such a costly product.

There hasn't been one false positive, still I'm bugged when my users get anything from 1 to 10 emails a day, from themselves, or the dreaded UPS tracking numbers - we seldom use UPS here, or when I get 30 spam messages in Swedish, that wasn't tagged because the reputation engine is tweaked for English words ... Our users are bugged to, but especially buggered am I when I need to administer the darned thing - it draws an enormous amount of resources. Even with 2GB of RAM, I still can't configure the thing without turning every processing module off.

I'll also be very honest, I haven't tested Lukas bayes filters, nor graywall or Clam. I bet they work ok, but as I understand - and this may be wrong - we host so many domains that it is impossible to work with domains manually, and SpamHalter needs domain administration manually and has no reputation service, and you need to combine it with some form of free dnsbl, and all lack dns spoofing controls, or reverse lookups, or spf configurability, - also Mercury lacks native support to relay domain based e-mails inbound/outbound - and again, there exists a daemon for this that made the light recently, but I feel I need something that I can operate easier, and also integrate with our back-end administration. - So in this area, for critical inbound e-mail traffic/filtering there is no cost effective solution in doing the labor manually each day - my users would definitely leave...

This leaves me to choose a box or virtual server product from Cisco, Symantec or others that I do not know much about yet.

So I was invited to a seminar in Malmo for a Swedish product, marketed all over the world, that on the surface looks like just the thing. In my world we've historically said, ok can test, or - ok looks good but we'll wait, and then at last ok - now it looks like it is usable. Meaning, it takes a darned long time to make something not just work, but also be usable - anyone remember Windows 98? - or maybe I should call it Sindows 98, because when Windows 98 SE came, that was something else - then Windows 98 was actually better than Windows 95.

So the products I'm talking about is the spam prevention gateway from HalonSecurity.Com. On the surface all looks good, but I'll cut straight down to the core - when they start talking teckie-limbo, I follow - and this is where I either leave a seminar or stay. In this case I understand the potential fully, as I totally understand and appreciate the technology they have invented behind the scenes. The Halon programmers have implemented their long time standing firewall technology into the spam prevention box, combining the two worlds into one. This is the same as a total integration of GrayWall and connection control into one single layer. Now if you think that's something, then I'd say that wasn't what blew my chimney - it was the fact that they rotate the connection pool, come again? - ! -- They rotate the connection pool, meaning they implement token ring ideals at the connection level - and this makes it impossible to DDOS the appliance. And, if that doesn't blow your chimney, then the entire configuration and management is reachable via SOAP - and that I know I can integrate - just like the Borg, assimilated it will be.

So in respect to any server based product, like Mercury, you can compare the connection control mechanisms in place in Halon - that exist uniquely for each module in any "normal" Mail server product, that you combine them all into one, with one single point of administration, rule set and monitoring. It is one base layer that has one sole purpose, to receive traffic - or reject it based on rules, static or cached, - and send the prompt response. As all of you know, the prompt response can be delayed, and this is where the second layer comes into play, that determines if the packet content is valid - be it obscure packet data, or wrong authentication, then send the prompt response.

As a side note; I'm very seldom blown or impressed today with software innovations, but this spam prevention gateway product is defenitely worth a test run.For all you who know about cultural differences, Swedes in general are not a competitive people, and this applies here as well. I promise it's worth a look.

I can't wait to get my hands on it for a full scale test as front for our Mercury installations, our Symantec licens expires soon...

Cheers / Peter

Mercury/32 v4.71 imminent

David Harris — Wed, 20 May 2009 13:34:00 GMT

Just a short note to let you know that Mercury/32 v4.71 is ready for release. We're currently trying to get a problem sorted out with Symantec - their SEP product is incorrectly identifying the help files in the Mercury archive as viral, which results in failed installations. Why is it always Symantec who mess us around, I wonder? This is the third time in three years, yet no other vendor of A/V products has incorrectly tagged us in that time. Oh well...

Once the problem with Symantec is sorted, the release archive will be made publicly available. The big new feature in v4.71 is the ability to run as a native Windows Service, which is a major step forward for usability in server-based environments.

Release announcements will be made here and in the forums as soon as the archive is available. A formal release of Pegasus Mail v4.5 (with some cool new capabilities) should be out very soon as well.

Cheers!

-- David --

Software Development - this is how it works!

Peter Strömblad — Fri, 27 Mar 2009 19:54:00 GMT

Suddenly it's just there, the latest creation of software with an incomprehensible help file and all possible legal statements about on your own risk as the result of a completely quality proven product. What you actually get, is the result of the following:

The developer creates what he thinks is bug free code.
The program is tested, and 20 bugs are found
The developer corrects 10 bugs and declares that the remaining 10 are actually not bugs.
The testers realizes that five of the fixes does not work, and finds another 15 bugs.
Back to item 3...
Back to item 4...
Back to item 5..
Back to item 6..
Back to item 7..
Back to item 8.
Marketing department now demands release based on their much too early press-release, so the package is delivered.
Early adopters identify 137 bugs....
The developer has already gotten paid, and has left the building.
A temporary development team co-operates and resolves nearly all bugs, but in the process they create 456 new ones.
The testers get a postcard from Bali - from the developer. All testers resign.
The business is sold to a company who made their profit from their latest creation, with 789 bugs....
The board hires a new CEO, who hires a developer ready to develop from scratch.
The developer creates what he thinks is bug free code...

CeBIT Fair - Quick Review

Peter Strömblad — Mon, 09 Mar 2009 08:13:00 GMT

I'm just back from the CeBIT fair in Hannover, Germany.

The CeBIT fair is good as motivator - sometimes you find something extremely interesting, but most of the times you look at who/what is progressing, what companies are flashy/healthy and what the upcoming trends are.

This years trends are very visible, despite the loss of 25% exhibitors and 20% visitors, the exhibitors still complain about all the youngsters demanding chocolate, but the trends show - environmental awareness is growing, internet services are more and more important, still young and vibrant, and the third major area is security.

The fun thing about this, is that both Pegasus Mail and Mercury MTA appeals, to all three areas - which is something we should piggyback ride on. Mercury is extremely lean on resources, it's very secure, we can use wordings like "intelligent". The only area where Mercury needs to be smarter, is SPAM treatment. Lukas modules are all fine, but soon it is time they are interwoven per default and adapts to collective learning. We're fighting against appliance with this, and the appliance is a black box - self adaptive etc, and Mercury can be that too - it would in the next year be *the killer combination* if SpamHalter+GrayWall+ClamWall+Mercury became one product, f.ex. with NOD32, who had the most interesting sessions (Symantec wasn't even there...)

Current status of Mercury/32 v4.6

David Harris — Mon, 02 Feb 2009 02:13:00 GMT

Just a short posting to let you know that there should be a minor update release of Mercury/32 v4.6, probably with the version number v4.7, late in February.

The changes will not be gigantic - mostly bug fixes and small incremental improvements, such as allowing IMAP connections via direct-connect SSL.

We have begun a significant redevelopment process on some of the core innards of Mercury - most specifically the folder management layer and the user database subsystem: these changes, along with increased Windows integration, native service support, and increased web management capabilities will be the focus of our work this year (although I do have one "surprise" feature coming up in the next few months that I believe many sites will find extremely useful).

While I hate putting in shameless plugs, times are very hard, and all license purchases for Mercury are gratefully received at the moment. Furthermore, if you know of people you think might benefit from Mercury, please introduce them to it - the more the word gets around, the more likely it is that the program can continue to thrive.

Cheers!

-- David --

Current status of Pegasus Mail v4.5

David Harris — Mon, 02 Feb 2009 02:10:00 GMT

Just a short note to let you know that after a complicated December/January period, we're now reviewing bug reports in the Pegasus Mail v4.51 public beta with the aim of getting a formal release out in the next few weeks.

My thanks to everyone who has taken time to report issues, and to Michael in der Wiesche for acting as the report overseer during this period.

When we're ready for a formal release, announcements will be made prominently here.

Cheers!

-- David --

Live every day - as it's an important day!

Peter Strömblad — Tue, 07 Oct 2008 11:04:00 GMT

Early this morning I got the message that a very close friend got hit by a car on her bike road to work yesterday morning. She sustained such severe trauma to the head that she died. She leaves husband and small children. The driver was temporary blinded by the rising sun, driving his two kids to pre-school.

Life is fragile, but we tend to think we are all immortal until something really painful comes too close. This accident came too close, and my thoughts wander astray to the driver, his wife and family, their innocent children, and Margaretha - her family, father, mother, brother and of course husband Jonas and their innocent children.

So - be friendly and nice to your next and do the things you love to do - because life is fragile.

/Peter

http://sydsvenskan.se/lund/article375811/Cyklist-ihjalkord-i-Lund.html

Repetitive work in SQL

Peter Strömblad — Thu, 04 Sep 2008 18:14:00 GMT

Just wanted to share the two SQL scripts I produced last week. They are stored procedures that create standard looking CreateUpdate and Get procedures for any given table in SQL-Server. I've published the scripts at sqlservercentral.com and they are free to use and tweak.

Stored procedure mkProc_CreateUpdate

Stored procedure mkProc_Get

Here is a brief description for both of the procedures

mkProc_CreateUpdate v1.0 (c) Petena AB 1993-2008, http://www.petena.se/, http://www.praktit.se/

Creates stored procedure of given table name for the purpose of adding or updating a record
Primary keys are to be set to null to trigger the insert, and the key is returned.
Signals null/not null and default values.

Input Params:
@_tableName - the table you want to script
@prefix - add string here if you want your stored procedure name prefixed, like 'sp_'
@AddParams - add additional parameters to the stored procedure call
@DoCreate - true/false : when true the stored procedure is created
@Debug - true/false : true only works when @DoCreate is false, presents all internal tables

Example: Exec mkProc_CreateUpdate 'Orders', 'crm_', '@userID int,' false, true

Pegasus Mail v4.5 public beta available

David Harris — Wed, 03 Sep 2008 11:31:00 GMT

A public beta of Pegasus Mail v4.5 is now available for anyone who wishes to do so to try out. The beta is very complete and stable, but is provided without formal technical support - you should almost certainly apply due diligence testing to it before using it in a production environment.

You can download the public beta from http://download-us.pmail.com/w32-450-pb1.exe, or a full German version of the beta from http://download-us.pmail.com/w32-451-de-pb1.exe (and yes, we realize they appear to have different version numbers).

Peter Stromblad will post an announcement telling you about new beta-related forums that will be made available in the community in the near future - using these forums, you can discuss the beta and provide feedback if you wish.

Please read the "What's new" notes in the beta installer or help file for information on the v4.5 release.

Cheers to all!

-- David --

C# Null, DBNull and Entities

Peter Strömblad — Mon, 25 Aug 2008 08:59:00 GMT

I've been working like mad to get my 3-tier construction to work. As I'm not all that great in C# yet, I delightedly discovered that C# supports nullable types. Now finally I can match my database constructions with a proper entity in code, and as well build the business layer so that it deals with the values as it should.

Some of you know that a relational database is perfect when it comes to relating a drop down with a key value, then fetching the meaning of the key value from the related table. But if the drop down hasn't been selected, you should not store an arbitrary value - you store NULL = unknown.

Now I came across a tool with source from Rick Strahls weblog, called DataRowGenerator. I've managed to alter this so that it now suits my needs by creating one entity file for each datatable. Below is a sample of the code that the program now generates automatically for all my 54 tables.

Here are some reference links that you may find useful.

http://blogs.msdn.com/thottams/archive/2008/06/30/dbnull-and-nullable-types.aspx
http://sab39.netreach.com/Blog/Blog/12/vobId__172/pm__18/
http://www.codeproject.com/KB/architecture/three_tier_architecture.aspx
http://west-wind.com/weblog/posts/147.aspx

/* ArtikelGrp.cs (c) Petena AB 1994-2008, http://www.petena.se, http://www.praktit.se


DEVELOPMENT HISTORY: ******************************************************************************
v0.01
  20080825 PiS -> Start

BUGS & NOTES: *********** ( !=Warning, +=Additions to be made, -=Comment ) ************************
  - 
 */

using System;
using System.Collections;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;

namespace PraktIT.CRM.Data {

	[Serializable]
	public partial class ArtikelGrp {
				
    #region Private Members
		  private Int32? _ID = null;   //  
		  private Guid? _UID = null;   //  
		  private Int32? _ArtikelGrp_ID_Parent = null;   //  
		  private Int32? _Nr = null;   //  
		  private String _Kod = null;   //  
		  private String _Namn = null;   //  
		  private String _Titel = null;   //  
		  private Boolean? _Aktiv = null;   //  
		  private Guid? _Firma_UID_Owner = null;   //  

    #endregion

    #region Public Properties
        public Int32? ID
        {   get { return _ID; }
            set { _ID = value; }  }

        public Guid? UID
        {   get { return _UID; }
            set { _UID = value; }  }

        public Int32? ArtikelGrp_ID_Parent
        {   get { return _ArtikelGrp_ID_Parent; }
            set { _ArtikelGrp_ID_Parent = value; }   }

        public Int32? Nr
        {   get { return _Nr; }
            set { _Nr = value; }  }

        public String Kod
        {   get { return _Kod; }
            set { _Kod = value; }  }

        public String Namn
        {   get { return _Namn; }
            set { _Namn = value; }    }

        public String Titel
        {   get { return _Titel; }
            set { _Titel = value; }   }

        public Boolean? Aktiv
        {   get { return _Aktiv; }
            set { _Aktiv = value; }  }

        public Guid? Firma_UID_Owner
        {   get { return _Firma_UID_Owner; }
            set { _Firma_UID_Owner = value; }  }


    #endregion

    #region Populate
      public static ArtikelGrp Populate(IDataReader dr) 
      {
        ArtikelGrp _ArtikelGrp = new ArtikelGrp();
        Populate(dr, ref _ArtikelGrp);
        return _ArtikelGrp;
      }

      public static void Populate(IDataReader dr, ref ArtikelGrp _ArtikelGrp)
      {
        _ArtikelGrp.ID = dr["ID"] as Int32?;
        _ArtikelGrp.UID = dr["UID"] as Guid?;
        _ArtikelGrp.ArtikelGrp_ID_Parent = dr["ArtikelGrp_ID_Parent"] as Int32?;
        _ArtikelGrp.Nr = dr["Nr"] as Int32?;
        _ArtikelGrp.Kod = dr["Kod"] as String;
        _ArtikelGrp.Namn = dr["Namn"] as String;
        _ArtikelGrp.Titel = dr["Titel"] as String;
        _ArtikelGrp.Aktiv = dr["Aktiv"] as Boolean?;
        _ArtikelGrp.Firma_UID_Owner = dr["Firma_UID_Owner"] as Guid?;
        }
    #endregion

	}

	public class ArtikelGrpDataProvider : DataProvider {

  #region Get using Select
    public ArtikelGrp GetArtikelGrp(Int32 ArtikelGrp_ID)
    {
      SqlConnection conn = new SqlConnection(ConnectionString);
      string _SqlCmdTxt = "Select * FROM ArtikelGrp WHERE ID = @pk";
      SqlCommand cmd = new SqlCommand(_SqlCmdTxt, conn);
      cmd.Parameters.AddWithValue("@pk", ArtikelGrp_ID);
      conn.Open();
      SqlDataReader dr = cmd.ExecuteReader(CommandBehavior.CloseConnection);
      if (!dr.Read())
      {
        dr.Close();
        conn.Close();
        throw new Exception("ArtikelGrp not found!\r\nID = " + ArtikelGrp_ID);
      }
      else
      {
        ArtikelGrp _ArtikelGrp = ArtikelGrp.Populate(dr);
        dr.Close();
        conn.Close();
        return _ArtikelGrp;
      }
    }
  #endregion

  #region Get using Stored Procedure
    public ArtikelGrp GetArtikelGrp(Int32 ArtikelGrp_ID, Guid Person_UID)
    {
      SqlConnection conn = new SqlConnection(ConnectionString);
      SqlCommand cmd = new SqlCommand("sp_ArtikelGrp_Get", conn);
      cmd.CommandType = CommandType.StoredProcedure;
      cmd.Parameters.AddWithValue("@ID", ArtikelGrp_ID);
      cmd.Parameters.AddWithValue("@Person_UID", Person_UID);
      conn.Open();
      SqlDataReader dr = cmd.ExecuteReader(CommandBehavior.CloseConnection);
      if (!dr.Read())
      {
        dr.Close();
        conn.Close();
        throw new Exception("ArtikelGrp not found!\r\nID = " + ArtikelGrp_ID + "\r\nPerson_UID = " + Person_UID);
      }
      else
      {
        ArtikelGrp _ArtikelGrp = ArtikelGrp.Populate(dr);
        dr.Close();
        conn.Close();
        return _ArtikelGrp;
      }
    }
  #endregion
	}

}

Codename: Madmin

Peter Strömblad — Tue, 19 Aug 2008 13:48:00 GMT

The time has come to start a long awaited project!

Madmin is my codename, until someone has a better name for it.

Madmin is short of Mailserver Administrator.

All the way back from 2000 we've administered our Mercury installations through a web interface, with a SQL-database and a separate program called MercurySynch.

Madmin's objective is to replace MercurySynch.

As such, it will be:
1. a webservice
2. utilizing IIS
3. directly manipulate one or more Mercury/32 Mailservers.

Our old MercurySynch polls the database at 20 minute intervals, but a webservice with direct access will do its work directly when called upon.

A webservice has the benefit that it is a stand alone application, and can just as Rolfs HTTPServer start, stop, pause, reload any instance via Windows Messaging. Designing a webservice also has the benefit that it is fairly easy to create administrational modules for that can be integrated into larger packages, or created as a stand-alone Mail Administrator web-site.

How do we begin?

Well, the only way to start is to iron out the relational data model. I have a few requisites:
1. Multiple Mercury installations has to be supported
2. Multiple domains
3. Local users, tied to organizational entity
4. Domains, tied to organizational entity
5. Alias handling
6. Relay
7. Autoresponders

Anything missed?

If you feel you want to be part of this, or if you have expectations or valuable input - now is the time to put that forth in the notes to this post.

Tool and reporting.

As I go along, I'll post my thoughts here - and I'll also update this space regularly as I make progress. When there is something to test I'll share it in the downloads section here at the community. I know we will later get into design issues, as well as PDA support for a proper and sleek Mail Server Administration web site. The tool I use is Visual Studio 2008 and the language will be C#.

You know Windows Update is flawed - don't you?

Peter Strömblad — Sun, 17 Aug 2008 08:13:00 GMT

Automatic updates of software are good - aren't they? Well I'd answer yes in normal cases, but anything that is automatic can behave in ways the creators never imagined. So it is with fire alarms, burglar alarms, and of course with computing. This patch tuesday from Microsoft contains quite a number of fixes. Some that are very important to servers, regarding name resolution. However smart we are, automatic updates are not enabled on our servers - we consider them too dangerous - since in the past some driver updates have caused machines never to start again.

And so it happens - again. And now, with virtual servers running on top of the base server - when updates fail, you render three-four five or even eight machines stranded.

What happened then, why doesn't the server start as it should? - well it does, but just barely. I've never seen windows so inoperable that not even a task monitor is accessible, not even in safe mode. A small clue exists on sys\windows in the file WindowsUpdate.log - that is accessible over the network. It states

2008-08-17 10:19:44:472 4328 1594 AUClnt WARNING: Shell_NotifyIcon failed (dwMessage=0x0, uFlags=0x3, hr=0x80070002)
2008-08-17 10:19:44:472 4328 1594 CltUI FATAL: Failed to show client UI, directive=5, hr=80070002

Aha, something in the windows shell isn't starting as it should. And with the debate of removing Media Player from windows, since explorer is so tightly integrated, led me to investigate - what changes were made to explorer this time. Within KB953838-IE7.log I found it. It says:

6.937: DoInstallation:AnalyzeDiskUsage failed

Aha - so the sys volume ran out of disk space during the install - and let's not bother with the why or how at the moment. The reason I state that Windows Update is flawed, is that it requires a re-boot for some operations. This Patch Tuesday's pack of files required a re-start, and between the update and the restart, that continues the installation - disk space ran out. Sure, yes it probably did - but when updating really cruical files, shouldn't this be checked before? In fact it does, but the limit of free space is too tight - and there you have the result - a server heavily depended upon - needs to be re-installed.

Well, then, why wasn't 16 GB of system space enough? Because of all darned copies that Windows generates. In the Windows directory there are hidden KB directories. Besides these you have another directory called ServicePackFiles and another directory with files. Only the Windows directory contains more than 8 GB of files today, on a server that was installed december 2006. That is insane. To the downfall, we support many systems, older than some of my boys. When they we're installed with RAID controllers and high speed SCSI drives disk space was quite expensive and a total 32GB server system was considered more than enough. Some of the directories are safe to delete, some are not - and I haven't found any official information from Microsoft on how to conserve system volume space. If anyone has, please let me know.

So for the time being, take this advice if you run cruical machines:
Make sure you have plenty of free space on you system volume before running Windows Update aka Microsoft Update.

....

and now on to the task of backing up all drives (just about a terabyte of data.... - sigh)

arrrrgh web apps

Peter Strömblad — Tue, 12 Aug 2008 21:29:00 GMT

Writing apps for the webb is a challenging task. What takes a normal hour when creating "normal" apps takes four times when working a three tier webb-app. There are simply so many pits you can fall in.

In any case I thought I'd share some very interesting read-up.

First of all, creating forms: Read up on Rick Strahl's excellent piece at msdn: http://msdn.microsoft.com/sv-se/magazine/cc163505(en-us).aspx

Then dwelve down into his weblog and you'll find an absolute excellent tool on how to create the windows classes directly from your database: http://www.west-wind.com/WebLog/posts/147.aspx.

So, after that we're on to Ajax. The resource for that is naturally http://asp.net.

There's a lot more. One needs to familiarize one self with css (zen-garden is excellent), sql calls, stored procedures, java-script, cookies, performance issues and not to forget loose binding. A web-app is always in a "new" state - there is very little you can do to compensate for the round-trips to the server side.

In the future I hope to share code when I get to hacking a Mercury web-service.

cheers for now / Peter

WinPMail v4.5 public beta imminent

David Harris — Mon, 11 Aug 2008 00:42:00 GMT

Just a short update on the status of WinPMail v4.5.

I had hoped to have the program released by now, but we've run into a late problem that I feel we have to resolve before a release can take place.

It is currently my intention to release a v4.5 public beta to this community as soon as the code is next in a stable state - hopefully before the end of this week. Once the public beta has had a chance to circulate a little and we're sure there are no remaining serious issues standing in the way of a full release, v4.5 will be made available on an unrestricted public basis.

Cheers!

-- David --

Every day something new...

David Harris — Mon, 21 Jul 2008 03:15:00 GMT

I've had a number of people ask me if I could put together a blog posting describing what I'm doing at the moment, and what plans there are for Pegasus Mail and Mercury in the short-to-medium term.

Well, the first thing I'll tell you is that my current priority is to get Pegasus Mail v4.5 out the door. On the face of it, it won't look like much has happened, and I suspect many people will be rather disappointed by v4.5, but in reality, more than 50% of the entire codebase of the program has been modified in some way during the shift from Borland C++ to Visual C++; it's been a huge, largely unrewarding job that simply had to be done. In the process, though, we've caught and fixed literally hundreds of small and medium-sized bugs that have been present in the program for periods ranging from recent history to more than a decade.

A huge amount of effort this year has gone into releasing Mercury/32 v4.6 - once again, there was a lot of code modernization going on that doesn't yield obvious visible benefits, but which simply had to be done.

But not everything is porting code and fixing bugs. I've also been spending a lot of time familiarizing myself with new technologies that will have significant bearing on both Mercury and Pegasus Mail:

For Mercury, I've been spending a lot of time learning about CSS and XHTML, because the future of Mercury is clearly heavily web-oriented.
I've been spending a lot of time learning about SQL and particularly SQLite, because it's clear that both Pegasus Mail and Mercury are going to need robust database facilities in future.
I've developed my own object programming interface for both programs: this is a key technology that will have a huge bearing on future development by making it easier to extend the programs' capabilities without side-effects.
I'm well into developing a complete replacement for the fundamental message store used by both Pegasus Mail and Mercury. This new component, called MailStore, is easily the single most important development in either product in more than a decade, and should be in a working state towards the end of this year.
I've spent a lot of time this year working on documentation - the bane of all programmers... The Mercury/32 Daemon Developer Kit in particular was a huge amount of work that was vastly overdue, and I do hope to start seeing new Mercury Daemons appearing before much longer.
Finally, I've spent a lot of time developing tools - either because I was forced to do so (as in the case of the new help system, which I was forced to do by Microsoft), or because I believe they'll be important in upcoming releases of either program.

I realize I'm not being quite as specific as I'm sure many of you would like: I'm not saying that "X feature will be working by August", or that "Y feature is now operational": I promise that as I get to a position where I can make reasonable statements about new developments I will do so, but in truth, the last two years have been a gigantic, painful, tedious process of modernization and tooling up for new capabilities, rather than actually working on those capabilities per se.

I also realize that I've been somewhat of a stranger to the forums this year: I apologize for that, and will say honestly that my absence has largely been a result of tech-support burnout... Doing technical support is a very soul-destroying process, because you're typically seeing people at their worst and most stressed, and nobody really likes spending all of their time dealing with the bad aspects of their work. As a result, spending too long doing technical support is a recipe for depression and loss of motivation, and I've been doing technical support at some level for nearly two decades now. It's my aim to become a more regular participant in the forums, although I will be consciously and actively trying to resist the self-destructive urge to solve every problem I see posted. I'd like to get back into the forums so I can enjoy interacting with the people who use my work without always burning myself out trying to fix all their problems.

So, there you have it - a slightly longer, and maybe slightly more candid posting than I intended, but I hope it serves to give you a little insight into where I am at the moment.

Cheers to you all!

-- David --