Mercury/NLM - common problems and solutions

FAQs - Mercury/NLM, problems and solutions

Problem: I'm using Mercury under NDS on a NetWare 4.11 server. Sometimes it starts rejecting mail as "user unknown" even though the user exists and the address is valid.

Solution: As far as we can determine, this is the result of a problem in NDS itself. If you are using a version of Mercury earlier than v1.44, upgrade to v1.44: it contains a number of workarounds to deal with this weakness in NDS. If the problem persists after you have upgraded, add the following statement to the [MercuryS] and [Mercury] sections of your MERCURY.INI file:

nds_reauthenticate: 1

This statement tells Mercury that it should perform regular NDS login and logout operations. In short, it appears that on widely-spread NDS trees, NDS sometimes gets confused about the status of Mercury's NDS login and "deauthenticates" it without telling Mercury. This effectively logs Mercury out of NDS, resulting in the "user unknown" errors. The problem appears to be exacerbated if you have NDS servers that crash or go offline frequently. Having Mercury login and logout regularly appears to work around this problem in NDS, at the risk of Mercury possibly not being able to secure a login to the server.

NOTE: You should not apply the "nds_reauthenticate" option as a matter of course - it should only be applied if it fixes this specific problem for you.

Problem: I recently upgraded to NetWare's SP7 or SP8 Patch Pack on my NetWare 4.11 server and now I'm getting regular "CPU Hog" abends in the MercNDSP POP3 Server.

Answer: We are currently trying to work out what is causing this problem - it appears to be a thread safety issue within NDS, but we have not been able to tie it down. We are currently doing all we can to find a solution to this problem, but have no workaround or solution at this stage.

Problem: When I unload Mercury, NetWare issues an error about unreleased resources. What do I do about this?

Solution: Nothing. The warning is completely benign and can be ignored. NetWare recovers the unreleased resources as a matter of course and it is quite normal for a program to have a few data structures left over at exit. In actual fact, in NDS mode, the unreleased resources are allocated by NetWare itself, not by Mercury. This warning is only significant if the numbers it reports are very large (for instance, more than 75,000 small memory allocations, or more than 20 BSD Sockets).

Problem: When I load PMUSER.NLM on my NetWare 4.11 server it abends.
Problem: When I unload PMUSER.NLM on my NetWare 4.x or 5.x server it abends.

Answer: PMUSER uses low-level features of NetWare that appear to change from version to version of the operating system. At the present time, we have no solution for this problem other than to recommend that you do not use PMUSER, or that you use the manual mailbox configuration utilities (MAKEMBOX or NConfig) instead and do not install PMUSER.

Problem: I can't send to or receive mail from Mercury

Solution: This and numerous variants of it make up over 95% of the problems reported with Mercury. In general, this is a configuration problem, in NetWare TCP/IP, in MERCURY.INI, or in your smart mailer. Things to check include:
- Make sure you are actually loading TCPIP.NLM on the server
- Make sure your netmask is correct - it must agree with every other host on your network.
- Make sure you have the correct address specified in [MercuryC] for your smart relay host.
- Make sure your name server is advertising the correct IP address for your server.
- If you have used Charon in the past, make sure you don't have invalid MX entries lying
around on the network.

Problem: I get "Loader could not find symbol 'inet_addr'" or similar loader errors from NetWare when I try to load MercuryS or MercuryC

Solution: You have not loaded NetWare TCP/IP (TCPIP.NLM). Examine MGUIDE.EXE for a brief description of installing and configuring TCP/IP on your server, and in the NetWare Red manual entitled "NetWare TCP/IP Transport Supervisor's Guide" for more detailed information.

Problem: I get one of the following errors: "Socket read/write timeout or error"; "Connection error during handshake with xx.xx.xx.xx"; "TCP/IP error during processing"???

Solution: These errors all typically indicate a routing or traffic problem on your IP network. Make sure that the "BIND IP" line of your server's AUTOEXEC.NCF includes a "GATE=" parameter (we suggest you ignore the Novell recommendation not to use GATE= when using RIP), and that all IP routers on your network are aware of your server and how to find it.

Problem: I get errors like "503 Need recipient" from Mercury

Solution: This error (and any error like it starting with a 3-digit number) is actually being issued by the mail host which Mercury uses to relay mail, not by Mercury. It usually indicates an addressing problem in your message, but you should refer it to the system manager on the mail host

Problem: I can send mail out, but no-one can send mail to me

Solution: This usually means that your server's Internet name is not being advertised on the Internet. You must have an entry in a DNS (Domain Name Server) system somewhere which allows other sites to work out your server's address from its name. Contact your IP network manager or Internet Service Provider for details.

Problem: Mail goes out with the wrong "From" address even though I've changed the MYNAME value in MERCURY.INI's [General] section.

Solution: You also need to change the Pegasus Mail configuration information to reflect the new Internet name. Use the Pegasus Mail PCONFIG program to do this.

Problem: Every time I receive a mail message I get a "message loop" - the message just bounces around between the smart host and Mercury until eventually one of them discards it.

Solution: You almost certainly have an incomplete or inaccurate [Domains] section in MERCURY.INI. You must list in your [Domains] section every possible Internet name by which your file server could be addressed. Mercury uses the [Domains] section to determine whether mail is local or remote: if you omit a possible name for your server then Mercury will not know that the mail is local and will refer it back to the smart host, which in turn will send it back to Mercury... and so on.

Problem: Error messages from mailing lists are returned to the sender of the original message.

Answer: This is an area where usage is vague on the Internet and it is difficult to provide a general solution. Try adding an "Errors-to:" field to the definition for the list in Mercury's "List of Lists". This will force error notifications to go to the specified address in many cases, but unfortunately not all Internet mail systems follow the rules.