Author Topic: Problem #1: A Common Email Base  (Read 6200 times)

0 Members and 1 Guest are viewing this topic.

Offline Donald Darden

  • Sr. Member
  • ****
  • Posts: 363
  • User-Rate: +3/-13
Problem #1: A Common Email Base
« on: March 02, 2008, 11:33:00 PM »
Playing with Linux Distros is one thing, but sticking with Linux and giving up Windows is proving problematic.  The biggest hurdle I've encountered so far is the divisive world of email.  All my email archives and address book are bound to a cleint program that only runs under Windows, and the effort to duplicate everything and to access everything there going forward is a real toe stumper.

I'm not ashamed to admit that I use IncrediMail, and for a user, it is reallly great.  I would not hesitate to recommend it to people who want to enjoy email, but at the same time it is decidedly not a suitable application for a secure environment, and web masters hate it because it involves a lot of overhead with all the graphics that can be employed in messages.

There are a couple of other flaws in IncrediMail, one that I was able to take advantage of, and another that is still irksome.  The 1st flaw is that IncrediMail makes extensive use of the Registry to keep keys, such as where it is installed, where to find the Lex, and the name and location of user email accounts.  It;s a flaw, because it exposes user information to Registry probes.  By exporting the keys created during the first install of IncrediMail, I was able to force other installs to recognize the same accounts and locations by simply importing same keys back in again.  So now, no matter which install of Windows I use, or which IncrediMail client I start, I always have access to the same set of email archives and the address book.

The irksome flaw is that IncrediMail does not give you any decent way to export email messages and addresses for inclusion in another email program, and it does not provide a version for IncrediMail for non-windows OSes.  Now obviously the people behind IncrediMail are making it virtually impossible to leave IncrediMail once you commit to it, and would rather that you upgraded to the paid for version.  But if there is a sure-lock for keeping anyone from moving to another OS, it has got to be to take away any of their most treasured capabilities, and email access and use is probably the highest ranked in this area for the average user.

So let's state this as a dual nature problem.  The more general form is, what can people do to migrate their email painlessly to an alternate email client that only works under a different OS, and the more specific form, which is what can be done for IncrediMail users that want similar features AND to have their existing email under Linux?

That defines Problem #1.

Offline Donald Darden

  • Sr. Member
  • ****
  • Posts: 363
  • User-Rate: +3/-13
Re: Problem #1: A Common Email Base
« Reply #1 on: March 08, 2008, 05:18:48 AM »
My approach to having a common email base is to adapt IncrediMail to use the same path and file structures in all implementations on the same PC, whether installed on separate partitions, or even if installed in a Virtual Machine environment,

This might be something that can be done with other email clients, but i have not checked this out.  I've done it with IncrediMail by taking advantage of its dependencies that can be found in the Registry, and by making use of certain design features found with the way that Incredimail behaves.

The article I wrote on how to do this is rather long, and rather than cut-and-paste it into this post, I am going to archive it and attach it at the bottom.of this post.

While IncrediMail would not be the choice for everyone, I've decided that its meritx far outwiegh its shortcomings.  In fact, what some would consider further reasons for avoiding IncrediMail may actually have made it the best candidate for the job.

Offline Donald Darden

  • Sr. Member
  • ****
  • Posts: 363
  • User-Rate: +3/-13
Re: Problem #1: A Common Email Base
« Reply #2 on: March 08, 2008, 06:21:18 PM »
I doubt that the above post is going to suddenly cause a mass migration to IncrediMail.  In fact, my exposure of how simple it is to convert IncrediMail to use a common path for the message store for all implementations will probably be seen as further evidence that it is unsuited to a business or secure environment.

But maybe that is all relative.  Here's the thing:  As I showed with my VM example, IncrediMail can be made to share a networked drive or folder for its message store.  This means you could set up an email store server for all accounts, and that would be a common storage point for all originating and received emails.  Now since IncrediMail treats all accounts in common, all employees directed to the same folder would show up together.  So if you set up a folder for Group A, and put all the employees in Group A there, then any PC in group A would have access to that group's emails, but each employee would presumably have direct access to only their account.  That makes for some interesting possibilities, such as simultaneously backing up or duplicating an entire organizations message store in one operation.

But here is where it could get unpleasant.  The account password is stored in the Registry as well, along with the password for accessing the account via the email service.  You could replace the stored account access password with your own, and then have access to the contents of that user's emails.  Now in the case of a disgrunted employee, this could be a good thing, because employees have no right to privacy when it comes to using compnay equipment and services, so you could dig through and find out exactly what that employee has been up to.  But on the other hand, someone could sneakily get into the boss's email and find out about things that they are not permitted to know.

And you do not actually need to get on a Group A machine to do it.  All you need is a PC with IncrediMail installed, access to the email store server, and you could modify the AppplicationPath to point to Group A's folder, then set the GUID to the same value as the Boss's account, store your own access password, and you are in.  Just like any other tool, there is good and bad applications when you have a bit of knowledge to work from.

Of course the stored passwords are encoded so that you cannot easily determine what they are, but if you have access to your own account, you can merely set the encoded password for a different account to the same code, then use your own password at the user level to get in.  Or you can reflag the account so that no password is required to get into it.

At the same time, suppose you had that disgrunted employee, and you want to immediately curtail their access to the accounts.  You can remove the account from IncrediMail, but that is just a Registry flag.  You are already aware that the actual account still remains.  But now you know how to eliminate it completely.
Do other email clients tend to keep the same accounts lying around, or does the act of removing them mean that they are erased?  It's not a question that you can take for granted.

So there are issues to consider when deciding whether to employ IncrediMail or not, and personally, for a personal PC, it is a very attractive choice.  But I would be seriously troubled were I to find it used in a business environment, where security becomes a real concern.

I'm not knocking IncrediMail's design objectives in the use of the Registry.  It's approach allows for the easy removal, reinstall, repair, and upgrade of the IncrediMail program, without sacrificing existing email accounts or contents.  And we are able to use it here to extend that concept even further, so that you can do many things, like have a common email store, even keep that store on a centralized PC or networked drive.  And let's face it, Registry tweaks are not something everybody is prepared to do, so it takes a fair amount of daring to make the attempt, or to figure out what to do.  But nothing is beyond the capabilities of the people who frequent these forums.



 

Offline Donald Darden

  • Sr. Member
  • ****
  • Posts: 363
  • User-Rate: +3/-13
Re: Problem #1: A Common Email Base
« Reply #3 on: March 08, 2008, 10:15:37 PM »
I imagine that someone is going to want to know if it might be possible to create a common store approach with either Microsoft Outlook or Microsoft Outlook Express.  These are usually the email clients that people find on the PCs that they use, and likely the basis of their email involvement.

I suppose it might be possible, and the techniques used in unraveling how IncrediMail can be modified might work as well.  I don't have access to Outlook Express anymore, but I do have Microsoft Outlook 2000 installed, so I took a quick gander at it.  As I did with IncrediMail, I first set up a dummy email account to initialize it and give me something to search for in the Registry.

Reading about Outlook online, I determined that it uses the file outlook.pst for a user's emails.  I searched for outlook.pst, and found it located in the  \Documents and Settings\[current user]\Local Settings\Application Data\Microsoft\Outlook folder on my system drive.  Then I took part of that path and looked for where it might be defined in the Registry, searching for "Application Data\Microsoft\Outlook".  I got a match on two log files, another in recent files, and I also found it in [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Microsoft Outlook Internet Settings\59df78a401b50f449ff9c2294b135d03].

But I would not be comfortable at this point with trying to modify this key.  True, it does include the word "Profile", but there are several other GUIDs in this section that are clearly not user accounts, so it is hard to anticipate what a change would represent.  If I were interested in trying to make Microsoft Outlook my principle email client, then it might be worth adding additional dummy accounts and track them all in the Registry and on the hard drive, just to make sure any changes made have the desired effect.  And I suppose that Outlook Express could be approached in the same manner.

Of course there is another way to go.  How about a mutli-platform email client that solves the problem of giving you access to your email from either a Mac, Linux, or Windows environment?  If it could then be used to create and access an email base from all those environments, that would be truly universal.

Well,there is an email client available that will work on all those platforms.  It is called Mulberry, and you can read about it here:  http://www.savetz.com/articles/newsforge_mulberry.php?sort=publication

But whether it can be set up to work with a common email store is uncertain.

This should be enough to get some people started in looking for alternatives that offer a range of configurations that go beyond basic email services.