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.
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.
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.
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.
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.
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.
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.
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!
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?
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.