> Looking on a HOW To create a secondary mercury backup server.  Currently I have one server but wish to create a
> backup server that would take e-mails when the first is unavailable.   I know how to create the DNS entries but
> looking on how mercury needs to be set up so users can get or send e-mails if the main server is unavailable. 
> Best practice suggestions would be appreciated.

Mercury/32 currently does not provide MX services.  David's looking into this for a future enhancement but until that happens here's 3 possible work arounds.   

These are NOT a true MX host function since it does not queue and wait for the receiving system to be online to send the mail.  That said, WSMTPEx will keep retrying if the connection to the server and port cannot be made.  I have not tested how long it will continue retrying.   

1.  First of all is the simplest, you simply re-write the domain in the mercury.ini [Rewrite] section.

[Rewrite]
none-tstephenson.com: [192.168.1.3]

I really was surprised when this one worked since it truly simple and has been there
all along.  You learn something new every day.  The brackets are required when using
an IP address.  This forwards all mail for anyuser@none-stephenson.com to
anyuser@[192.168.1.3] using the normal Mercury/32 send process via port 25. 
Works quite well when using MercuryE, cannot work when using MercuryC unless the
IP address is a routable IP address.  You must re-boot Mercury/32 for each change
since this is only read at startup.  

2.  The second one is the daemon MercFwd and it essentially does the same thing as
the rewrite but this can be done dynamically by changing the domains section.  The
[Domains] entry of  

daemon:c:\mercury\mercfwd.dll;[192.168.1.3]: none-tstephenson.com

does essentially the same thing as the rewrite above.  Again it uses Mercury to deliver
the mail via port 25 and so you cannot use this with MercuryC when using non-
routable IP addresses.  

3.  The third one is the program WSMTPEx.exe (SMTPEX.NLM for Netware)  and this a a
separate program that takes mail for a email account and forwards it to any port and
any hostname/IP address.  I use this with my domains to forward the mail to a Linux
system (must use high ports as non-root) and to a second instance of Mercury/32
running on my system (can't share port 25)  Here's a sample of the ini file I use for
forwarding all mail to Mercury/32 running on Ubuntu v8.10 and Wine.  

 #  You can rename this tool, but name of following section must remain [WSMTPEx]
[WSMTPEx]
Version=0.10
#  TCP port, on which SMTP server listens
Port=8025
#  Number of seconds to delay between searches for emails
LoopDelay=30
#  Folder, under which is most of user's mailboxes
UserFolder=
Domains=1
# Users mail address domain part
Domain1=linux-tstephenson.com
LogName=c:\Mercury\WSMTPEx.log
SMTPServer=192.168.1.4
MailBoxes=1
Badmails=c:\pmail\mail\BadMail

[linux-tstephenson.com]
# When user name start with "DM:", WSMTPEx will try to find SMTP envelope address in mail file
Mb1addr=dm:ubunto
Mb1dir=c:\pmail\mail\ubunto


This takes all the mail in the domain account "UBUNTU"  and sends it to port 8025 on
192.168.1.4 to be received by MercuryS.  The directory BADMAIL I have specified
must exist.  You can run multiple instances of this tool and and it can be run as a
service.  If run as a service and running multiple instances the name of the program
should be changed.  I use WSE-UBUNTU to rename the program and ini file for this
one.  

Many thanks to Petr Jaklin for the development of these tools.  You can get these
tools at the community download areas or directly from Petr Jaklin's site
http://www.3net.cz/software/softe.htm  

[quote user="Rolf Lindby"]

If Mercury is running in program mode and my command daemon is loaded the daemon simply posts a WM_CLOSE to the window returned by get_variable(GV_FRAMEWINDOW).

/Rolf[/quote]

OK, Thanks.  That doesn't work if Mercury is "Hard to exit"; in that it just minimizes itself.  That's why my previous tests failed.  But that's OK.  I wouldn't use "Hard to exit" if Mercury were running on desktop 0.

Profimail connects to Mercury, checks for mail and disconnects - if there's nothing new, it's only visible in the Mercury window for about 5 seconds. I think this is configurable in Profimail. As regards cost, you can download a time-limited demo without charge - I think you get 30 days to try it.

Thunderbird logs in as soon it starts up and appears to stay logged in so long as it's running. I don't think checking for mail and logging in are the same thing - for example, you would need to log in to read existing mail, unless it was synchronised and stored on the client.

Chris

[quote user="ubecker"]
[Domains]
10.203.63.3: ourdomain.com
[/quote]

That definitely looks wrong to me, in a similar way to the error I made. See page 12 of the 4.73 manual - I think (guessing a bit as you've scrambled your domain name) yours should probably look like

[Domains]

ourdomain:  ourdomain

ourdomain:  ourdomain.com

ourdomain:  [10.203.63.3]

I'm not sure about the colons - they are there in my mercury.ini but the current manual doesn't seem to show any?

Chris

thank you! problem solved

Both of these are client issues, Mercury can only write what it is told by Outlook.

I haven't used Outlook since 2000, so can't offer any further suggestions sorry.

You might have more luck on an Outlook board.

Since there doesn't seem to be any changes I'll ask another question:

DAEMONEXPORT short daemon (void *job, M_INTERFACE *mi, char *address)

{
        void *blank;
        mi->logstring (20100, LOG_NORMAL, "TEST DAEMON: Daemon function called");
        blank = mi->ji_create_job(JT_GENERAL, "u.d@o.com", NULL);
        mi->ji_add_element(blank, "Joshua.Arner@ATIMetals.com");
        mi->ji_add_data(blank, "Subject:This is it");
        mi->ji_close_job(blank);
        mi->ji_close_job(job);
        return 0;

}

When

I run this as part of the code for daemon1.dll in the DDK the message

triggers the daemon and create the message just fine.  However, the

triggering message is marked with a retry flag and repeats the entire

process on the next poll cycle.  Am I doing something wrong or is there a

way to reset this flag?

My only solution is to try to copy the message and have the daemon return 1 to delete the message, I'd rather not do that.

This was the log just before Pegasus generated an error. It had been frozen for maybe 5-10 minutes before this.

None of the referenced files seem to exist.

 Duncan

Worked. Thank you very much.

Filippo

It was recently brought up in this thread, actually:  

No option for that other than creating a daemon to do it, though.

/Rolf 

Thomas,

I will test this out.  Thanks very much.

MP 

I am currently running Mercury on a system where it is installed on the C drive, but Popfile appears to be installed on a Raid drive that is in a critical state, on the same machine. I need to install Popfile onto the C drive of the machine and am not sure how to do this. (I am moving all data off this raid drive as it is not worth keeping it any longer.)

I seem to have originally had Popfile installed on the C drive as old Popfile directory resides there now, but obviously predates the existing setup.

The version of Popfile that I am running is probably quite old, but I have been very wary of changing anything that was not broken. V 0.22.4

Among other things I have a neat link in my Pegasus Mail message where I can access my Popfile data for particular messages and correct any Popfile mistakes. Currently it looks like this:

X-POPFile-Link:    http://computername:8080/jump_to_message?view=xxxxxxxxx

Can anyone give me instructions on getting this working in Mercury from a different installation directory for Popfile, please?

Many thanks,

Ellie

[quote user="Thomas R. Stephenson"]> RFCs aside, it is just common sense: If the client sent a command (Delete Mail X) and the server confirmed the execution of the command
> ("OK"), then the server is responsible to retain this information.
> There must be a very specific reason for "forgetting" such a command long after the fact, and in this case, I cannot see such a reason.

The most common reason is that it is better to not delete mail from the server until you know that this was what was desired by the user properly closing the session.  The same reasoning is used for POP3 as well, all delete flags are removed if the session is not properly closed.

[/quote]

I heartily disagree: While this behavior made sense with POP3, where a session has a very specific, predetermined purpose (get list of mails, download certain mails, delete other mails, close session). If during all those steps an error happens, the client can start from the beginning.

The usage of IMAP4 is completely different: The session is left open for hours, or even days. The user does many different "transactions" during this session (reading a mail, moving another, going back to the first to delete it etc.). All this is interactive. Every single step must be considered as final, since after hours (or days!) in this open connection, you do not want your actions from way back to suddenly be reversed. Also, it's not like Mercury magically reverts your mailbox to the state before the connection was opened: Only the deleted flag vanishes. Copied mails stay copied, Replied to mails retain that tag etc.

IMAP4 is used hugely differently from POP3. The mailserver has to treat it that way.

Also, one of the new features of 4.73 was, that the index files are now written immediately. I think everyone took this to mean, that all relevant information is saved immediately. Change of a flag, especially "Deleted" is relevant information.

Greetings

Markus Borst

Also, and this is not small problem: Mercury crashes from time to time, mostly on corrupt mailboxes. In this case, the server has no chance to retroactively save the Deleted flag, it is simply lost without any user error at all. 

Maybe the _INBOX_.PNM file got corrupted: We noticed that if this file somehow becomes empty (0-Byte file), Mercury can never recover from it and listing the contents of the inbox gets inconsistent results.

If _INBOX_.PNM is empty, just delete the file, it should be re-created next time you connect to imap.

Same goes for other PNM files for mailfolders. Be careful though to not confuse these with the PMM files: PMMs contain the mails in the mailfolder proper. The PNM only contains a unique identifier for all e-mails in the folder and a flag whether the mails is deleted or not.

Greetings

Markus

You can check the path to the alias file used by Mercury in Core configuration / Files / Alias database file. The standard value is C:\MERCURY\Mercury\ALIAS.MER. This is a structured file that shouldn't be edited manually.

After changing an alias in the Aliases dialog in the program just click Save, no restart is required.

/Rolf 

True, messages sent to the external address will be distributed to all local recipients even if sent by one of the local users. Mercury could probably catch the message and reroute it to the local forwarding mailbox instead of first sending it to the external server, though. Other than that some header with the intended local recipient would be needed to avoid sending to all. 

/Rolf 

I found the postmater whitelist app for aol if anyone else needs it:

http://postmaster.aol.com/cgi-bin/whitelist/whitelist_guides.pl

thanks for all of your help.

I knew that I had the wrong mercury protocol, but forgot to change it before submitting, and with it having to be approved, there was no way to edit before having to leave...sorry for any confusion.

There is no setting to change that, but as daemons can change the SMTP envelope it would be possible to do it with a daemon. It's not advisable, though. RFC 2821 clearly suggests to use a blank MAIL FROM for non-delivery notifications:

This notification message must be from the SMTP server at the relay host or the host that first determines that delivery cannot be accomplished. Of course, SMTP servers MUST NOT send notification messages about problems transporting notification messages. One way to prevent loops in error reporting is to specify a null reverse-path in the MAIL command of a notification message. When such a message is transmitted the reverse-path MUST be set to null (see

4.5.5 for additional discussion). A MAIL command with a null

reverse-path appears as follows:

MAIL FROM:<>

/Rolf

Exactly what I needed, thank you!

Has a solution been found to this problem? I am a long time mercury user and the last version I used was 4.72 and I never experienced this problem.  Just about a week or so ago, I decided to update to 4.73, and I immediately noticed this problem from hotmail. I've tested from two different hotmail accounts and all long messages have this problem.  Is there a fix coming out soon, or should I revert to ver. 4.72.

 Thanks in advance for your reply.

Justin