And just another crash of Mercury during transmitting of a 17 MB attachment by MercuryC which cause to a 24 MB .MC file (single client session file). But this time I had additionally activated the session.log which is showing for this e-mail:

T 20141210 120120 230 Begin processing job MO0001A4 from user@domain.com
E 20141210 120407 230 TCP/IP error.

There are no any special settings in our MercuryC configuration:

- Connection port: 587 - SSL encryption via STARTTLS command

- TCP/IP timeout 180 seconds

- Poll the queue every 60 seconds

- Use extended SMTP features where available > checked

Even if there are any TCP/IP problems with our internet connection - Mercury should not immediately crash in such case, isn't it?

I will test Brians idea to change-over to MercuryE during the next time although I would prefer sending all outgoing mails via our ISP mail server.

Cheers

joerg

I suppose you could ask your Internet provider to allow port 25 traffic for you, but unless it's a business line it might not be easy to convince them to do so. The only way to get around the block would be some type of relaying as mail servers need port 25 to communicate with each other. The standard solution is of course to use the MercuryC module and relay through Verizon's SMTP server.

Hi Konrad,

we have a similar setup, Thunderbird and IMAP. Some users have the habit of having Thunderbird open the whole day. Thunderbird has the habit to keep one connection open for each IMAP account.

I am not sure if I shut down Mercury while IMAP connections were open but I think I did several times. I never experienced problems regarding the HIRARCH.PM files.

The only problem I see sometimes is a message "IMAP folder is blocked by another user". The number of simultaneous IMAP connections should not be limited.

 Regards, Bernward

Hi Gus

Just thought i would join this discussion, I am also a long time mercury user (even paid for a license), we are also facing exactly the same problem. Getting loads of earache from the boss on is folders getting corrupt. Don't want to have to move to an exchange server but it's looking increasing likely. A beta version would be good to try or maybe a date when the new version would be available.

thanks

If you are only going to use the server for sending messages originating from your own computer using MercuryC you can probably leave the domain settings as they are. (You obviously don't own the domains listed there, but as the server won't be connected directly to recipients it won't make any difference.) Restricting access to  network interface 127.0.0.1 for MercuryS (the SMTP server module) is maybe OK, depending on if the program that creates the messages is set to use that interface. To be able to relay (send messages to non-local recipients) you should set MercuryS to allow relaying (Configuration/MercuryS SMTP Sever/Connection control).

I'm not sure if you actually found the PDF manual for Mercury? It's named man-473.pdf and should be located in the main Mercury folder. It contains a lot of information that is useful if you want to understand how an email system works.

To get the help system working you may, depending on what version of Windows you are using, have to install this update: http://support.microsoft.com/kb/917607/de . (The help system will actually be replaced in the next version of Mercury to avoid this issue.)

Finally, please check logs to see what the server is doing when there is a problem.

[quote user="Rolf Lindby"]

nsynonym.exe is a Netware tool and normally not included with Mercury/32, so it's not part of the upcoming release. David will have a look at it though, and if it easily can be modified to 32-bit he will do so. 

[/quote]

 There seems to be some misconception: nconfig.exe is not a "NetWare" toll. It is a tool for Mercury in NDS mode. It reads the synonym entries from NDS/eDirectory (attribute "EMail address") and wrties them in a database for Mercury to read. There is a different method available in Mercury/32 to store synonyms (the NDS attribute "Internet EMail Address") but in our environment this attribute is reserverd for other uses.

Greetings

Markus

It depends on the version of Outlook and a number of other things. There is some useful information here: http://www.msoutlook.info/question/852

[quote user="J_Aarni"]

I think you should run spamhaltersetup.exe from \mercury\daemons directory.

[/quote]

That was exactly it J.  I simply had no idea that was there.  I'm quite happy that there's now a solved thread relating to this.

Thanks for your help. 

Hi Sellerie

Just to say thanks for your help, it does appear to be outlook. Changed to an SSD and it has improved the speed.

I installed stunnel (SSL encryption wrapper, as discussed earlier in this forum) in front of Mercury. It installs as a service and is working pretty fine. While Mercury operates unencrypted for both send and receive, the encryption is done by stunnel, using TLSv1.2

Be careful with your port assignment. While the clients use 110 (POP3), 143 (IMAP) and 25 (SMTP) to connect to Mercury, I chose 109 and 587 for Mercury -> stunnel connection, just to avoid double usage on my Mercury host.

Solved.

I set up pmail on another win 7 machine. No problems. So -- not a networking issue as such.

After some faffing, I found that, somehow, and only on the one machine, the shortcut had -roam on the command line! Doh! Remove that -- all is good!!

 Don't know how that got there, I installed with default settings on all, but anyway, good that it's all working!

Thanks Paul, I'll just avoid using the laptop with Thunderbird on anything but the home network until 4.80 is available. From other posts it looks like I could use stunnel but I have enough to do at the moment without learning new software!

Nothing 'normal' about these connections.

The first IP address is in Spamhaus and other DNSBLs so you could block that easily. The second isn't - yet.

Neither are doing anything but filling up your session log.

I suggest to update to the latest version 4.74.

[quote]

Fixes for MercuryI IMAP  MercuryI now

saves UID lists any time they change: this should prevent UID

synchronization problems from occurring, but may introduce small extra

processing delays with very large folders. There have also been some

changes in the way the IMAP SEARCH command is handled that should

improve performance and reliability in a number of search scenarios (in

some cases spectacularly), and MercuryI now caches FETCH data which

should significantly improve performance and reduce load when clients

like Apple Mail fetch messages a chunk at a time.[/quote]

Mercury/32 v4.74 available

Have you enabled session logging in MercuryS? If so, are the internet clients connecting to Mercury and being disconnected, or are they not reaching Mercury?

 If they are reaching Mercury, what is the conversation in the session log?

[quote user="questort"]

23:07:02.562: << 250 Recipient OK - send RCPT or DATA.<cr><lf>

23:07:03.156: 7: NB Socket read error 10054 (connection aborted by remote host)

23:07:03.156: --- Connection closed normally at Mon Sep 15 23:07:03 2014. ---

[/quote]

Sounds like a security mechanism to prevent spamming. The connection is closed after 100 recipients by your ISP. I would get in touch with their support desk and ask whether they could increase this limit. Sometimes you have to pay for it a monthly fee...

Try running the program from a policy and select "This task modifies the raw data of the job it examines":

In some cases, you may wish to allow the external task to modify the actual data in the mail message it examines (for instance, you may want it to add a header to the message). Checking this control tells Mercury to copy the temporary file it creates containing the message's data back into the queue job when policy processing is complete. It is your responsibility to ensure that the policy does not corrupt or damage the message data in this case, and to ensure that the message data remains in legal RFC2822 format. Checking this control will slightly increase the time it takes to process policies on your system. 

Another way to do it would be by using a daemon, but the policy approach is probably easier.

Yes. Shutdown Mercury32 and copy the files back in queue should work. The extension .$$$ is unknown to me. I know only the files listed in . I would take a look in the .$$$ files with Notepad++.

These files seem to be created by Mercury32. Either this is a program fault or the result after moving files in the queue while Mercury32 was running.

A couple of months ago there was a long thread discussing the problem of synonyms not being used by auto-replies.  A solution was found, or so we thought.  The problem was that the From: header in the auto-reply was populated with localusername@domain.com rather than domainusername@domain.com.  It was apparent that the synonym files was ignored by the auto-reply process (triggered by a FORWARD file).  Removing the local user entries from the MercuryD configuration appeared to have solved the problem but the problem is back for me.  The only change I can think of is switching from MercuryC to MercuryE.  Does anyone know if or why this change would affect this behavior?

Edit: I got it working again on auto-replies but not on auto-forwards generated by a FORWARD file.  The emphasis during the previous discussion on this topic was to get the From: header correct in the auto-replies.  I don't recall that the Resent-from: header in auto-forwards was given much attention so it may have never worked.  It is of low importance so I consider this problem fixed.

The [MercuryE] section in my Mercury.ini file was completely missing....  I inserted the section and now it appears to be working.

Thanks Rolf