Can you give us a little more detail about your configuration: what Mercury modules you are using and how the clients are communicating with Mercury.

There could be a problem connecting back to your public IP from inside the LAN, depending on router/firewall settings. Anyway, feel free to send connection details and we'll make some tests.

Try checking the log files for MercuryS (the SMTP server module) and Mercury core. You should be able to determine if the delay happens during the SMTP transfer or when the message is handled by the core process (where content control, SpamHalter and ClamWall are part of the equation). If we know it's in the SMTP transfer part you could then try temporarily switching on session logging while sending the same message one more time. If there are indications of problems in the log, like long delays at some point or error messages, that will show us where to look further. If not it's most likely a pure networking or antivirus software issue.

Thanks. Licence purchased!

Dear Rolf,

Many thanks for your answer, and for your help I am going to use this way (an alias with the IP)

Have a nice day

Thanks.

If you suspect that someone is using your server to distribute spam you should check relaying settings (Configuration/MercuryS SMTP Server/Connection control /Relaying control). At least "Use strict local relaying restrictions" should normally be checked. If on the other hand the empty message wasn't sent through your server it's obviously not something that you can block.

Additionally, there is an option in MercuryS configuration (Compliance/Restrictions to apply to message content) to refuse messages with no or empty Subject header.

Thank you very much

The FACT you sent solved totally our need and works just fine. It is perfect and just by adding one line in the Mercury.ini file

fantastic !

 Thanks again to you all 

David COHEN 

A public release of 4.80 is being prepared right now and should happen very soon.

Yes, I believe the "pre-release" is NOT the same beta "4.80" that was released in January.  At any rate, I think Rolf resolved a post or two ago..

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.