Could be a hardware issue or a network connection issue, but is more likely to have something to do with the IMAP client. I regularly access big IMAP folders (>10000 messages) on Mercury using Eudora, and even though it will take a minute or two to get everything synchronized there are no huge delays. Try it with some other client software to find out if the result will be different.

It might be a good idea to make sure there is no real-time antivirus software active on the Mercury mailbox folders as well.

/Rolf

There's more than way to access mail remotely, and others may have additional suggestions.  You can use a webmail application such as Squirrel Mail, installed on the Mercury server machine and then access mail through a web GUI.  Alternatively, you could set up an encrypted VPN, such as OpenVPN.  The latter allows users to appear as part of the LAN where Mercury resides.  I routinely use both of these options.  You can, of course, also set up Mercury to provide POP3 or IMAP4 service to your users directly.  I personally prefer going the encrypted VPN route, particularly for use from hotel and other public access points.

So far as keeping a copy of all mail, the easiest way to do this, centrally, is to set up the IMAP server in Mercury and have users access their mail via IMAP rather than POP.  That way all mail can reside on the server and you can just back up the server machine (or just the Mercury directory tree) and you don't need to worry about laptop failure (or theft .... not keeping mail on the laptop is a plus in this respect .... unless you want to synchronize the laptops with the server for off-line use).

Gordon

> Since  yesterday I have actually (for whatever reason) managed to
> turn it off when I restarted the server once again. Nonetheless, I
> still have a problem. When I turn session logging on (because I need
> more information than I can find in the normal logs), the session
> log file immediately has some 40 MB and starts in May 2009. Do you
> know the reason for that?

Huh?  Are  you saying there is a 40 MByte *.MS created immediately when this is checked without anything going through MercuryS??

 Was the directory empty before you started session logging.

Nobody seemed to have an answer for me to my question, so I have done some tests and found out what happens.  It seems that wild-cards (*) will work generally using the /MATCH function in distribution lists, not just in the domain part of the address as implied by the Help file.  Thus all of the following will match /MATCH j*h*smith@*:

johanne_smith@address.com

joshsmith@joshmail.com

I was interested in this to provide a partial solution to avoiding SPAM blocking when wanted correspondents change ISPs and very often retain their username (local-part).  Not a 100% solution, but still useful.

Gordon

I created a new user in Mercury, logged into the new mailbox using

Pmail and sending a test mail. The Mail file is created in the Mercury

queue folder, but the sender adress is not complete. Only the Mercury

user name is used and the initial letter of the first name is missing.

All other users can send mail with the initial letter, only the new one can not.

The e-mail address of the user is "personal Name" <username@domain> unless you are using synonyms.  Personally though I use the "~o" <~r> in the MERCURY User Defined Gateway to create a e-mail address using "Personal Name" <Reply to: address> so the user can specify the e-mail address to be used.

[quote user="khk"]temp is empty and scratch contains only old files...[/quote]

From the Help section on configuring the queue:

[quote]Configuring Mercury's mail queues

Mercury stores mail messages it is processing in directories called Queues. All Mercury systems must have at least one queue, called the Primary Queue
, which is where jobs reside as they transit the system. The primary queue should always be located on a drive local to the machine where Mercury is running if at all possible. If you place the primary queue on a remote system, and the connection to the remote system becomes unavailable, mail may be lost or damaged.
[/quote]

MercuryD won't deliver duplicates of the same message to a mailbox because of extra headers in the message. You may have some filtering or forwarding rules on your server that causes it, though. Try having a look at the log files, it's really the best way to find out exactly what is happening.

/Rolf  

Hi Rolf,

Thanks for your input !

I've tried shortening "program files" to "progra~1" which works fine in other sections of Mercury.
I did also try putting the path between " " and eventually just placing it in the root, e.g. D:\MyTemplate.MER

//Magnus

Hi

Not sure if this will be of interest to any one  [:S]

Using Alkit VNC (http://w2.alkit.se/avnc/) it's possible to share just the Mercury32 Window via VNC.

This allows you to view and interact with the GUI via a VNC Viewer (I've tried Linux & Win) or a Web Browser.

Seems to work well, with a couple of little issues.
1: Mercury32 must be running full screen on the remote PC

2: The Mercury top tool bar is missing from the remote viewer.
(but you can still click at the top and get the drop down menus. !!)

3: Via the Web Browser the mouse seems slightly out..  You have to click a little lower that you would normally.

Not to sure if anyone will try this but though I'd post it anyway !!

Anyone have a better solution that will work on Win & Linux, please post details.

Regards

Hi all !

Following the criticism of Konrad Hammerer about Pegasus being so old fashioned that some users do not even want to try it, I think that making it skinable could reverse this trend. I have made this suggestion elsewhere, and I think some people here said it was a good idea. I hope David will take that into account in the rewriting of the MailStore engine. On top of that, it could give the community a more participative role.

Cheers !

Whiskyfizz.

Well, that's what I was trying to say: I don't think it's my PHP code because it used to work on a newer version of Mercury and now, when I downgraded, it doesn't anymore.

However, when I think about it, I also downgraded PHP, so I will have to see exactly what causes the problem. Although now I tend to think it's PHP who formats the addresses incorrectly.

Will test this tomorrow and let you know.

Thanks again for your help

Dear gurus

I've followed for uploading emails I have stored on my computer to my Gmail account. But I can't get it to work, even when I've carefully done exactly what the guide says I should do.

All my emails reside in Thunderbird (latest version). I've installed Mercury 4.7. I have verified (by looking in Mercury's subfolder Mail in Windows Explorer) that my Thunderbird messages have been "copied" into Mercury.

Following Ben's example, I created five "year" accounts (in both Thunderbird and Mercury) so that Gmail can POP3 in parallel from these accounts. I've made five corresponding POP3 connections in Gmail's settings and each such connection verifies when I create it. I have forwarded port 110 on my router to my local computer that Mercury is running on. When I do a send and receive from Thunderbird, it asks for the password for the relevant Mercury user. When I type it in, the password is accepted. However, I am unable to send any emails from my five Thunderbird accounts. Also, I cannot send messages from my ordinary Gmail account to any of the five Thunderbird accounts.

In Mercury's POP3 Server, I can see that Gmail is connecting regularly from the five POP3 connections because the relevant connection with the Gmail IP address blinks for a second in the POP3 Server window. But the Server window as well as the Gmail Settings page both say that no messages are fetched. I did manage on one occasion to upload 19 messages from one of the accounts but why no other messages were uploaded, I don't know. At this time, the other four connections were also active and verified.

In the posts on Ben's guide, it said that one could try using 127.0.0.1 instead of localhost but that didn't have any effect.

Mercury has so many settings that I'm a little bit lost. But I've left everything as default upon installation. I installed all of the, I think they're called, modules. I'm using MercuryC instead of MercuryE and that appears to work because, as noted above, Gmail's connection attempts blink in the window. I've checked the logs but they only provide the same information that the POP3 Server window says, that is that a user X from IP so and so connected on date/time but that 0 messages were sent.

Thunderbird has been running when I've tried to fetch the mail. Not sure if that's a requirement since the mail is also in Mercury's folder but just in case I left Thunderbird on.

Has anybody tried to do this and could assist me?

Thank you

Philip

I did forget to create the user. Now, I don't get the error message anymore. Thanks.

I have defined groups in server2003 Active Directory users and Groups and made members.

Mercury/32 by default does not recognize groups other than Netware in the Netware mode.   There is a beta (alpha?) from Frank Fesevur <omega@fesevur.com> that does integrate Mercury to Windows AD but it's not been released to the public, you might ask him for a copy.  I have been testing testing this for some time and it does appear work with a windows workstation and groups.

In addition, Dameon Wagner, of the the Pegasus Mail and Mercury/32 beta testers, has created a daemon that can send to NT groups.

*   NTGroups is another tool that I wrote because of mailing list pleadings (see, writing to mailing lists does work ;-). It's a custom
    daemon for Mercury/32 that allows you to send mail to OS groups like those found in the various Windows OS's based on NT. Now supports
    receiving mail from external addresses.

http://myweb.absa.co.za/d.wagner/
 

Thomas, I finally found the error. 

All of the mails from Mercury/32 were regarded as Spam within googlemail. 

Why i do not fully understand. 

But at least Mercury worked ok. 

Thanks you again for your help. 

> Thomas - I am receiving the mail with Mercury D.  I am not sure that I understand your question with regard to delivery.  Typically what
> happens in the filtering process is that various rules are applied and eventually the mail is moved to a specified user, unless it is
> recognized as possible SPAM, in which case, after exiting the filtering rules, several Policies are applied.  Maybe that is what you
> refer to as "Filter that takes it out of the normal delivery process".

The "MOVE" functions takes it out of the normal deliver process and essentially deletes all the header adds.  Use a an alias to get the mail delivered to the proper user by core and the header add will work.

Only way I know is to munge the address of the delivery template.  Eother cange the path or the filname to something that doesn't exist, and it won't be sent.  I do it all the time - delivery receipts are no good.

Thanks for replying, Rolf

I sorted this out. When I checked the list of folders using Windows Explorer no folder existed named MPRG. However, if I tried to create a new folder and name it MPRG Windows Explorer displayed a notification that the folder already existed.

When I scanned through the list of files in the pmail directory, I saw a file named mprg. It had the 'unknown' standard icon (because there was no extension). When I opened this 'file' in notepad, I saw that it was in fact an email/Pegasus Mail folder dating from 2002! The subject of the email was mprgnewsletter. After renaming it to mprg.old I was able to create the folder from within Mercury.

The initial information at the top of the message was not the usual Pegasus Mail format but that used by Outlook (I think):

IPM.Microsoft Mail.Note

I have no idea how it got there. I have tested Outlook with the Pegasus Mail folders, but I tested it against my own account, and I did that last year. 

Still, I'm happy now :) 

Sending to non-local users is controlled by the settings in Configuration / Mercury SMTP Server / Connection control / Relaying control. The help text explains the different options quite clearly. It's of course important that the Local domains section in Core configuration has been filled in correctly as well, so please have a look at the help text for that too.

/Rolf