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:
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
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
- 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
- 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
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
Problem: Mail goes out with the wrong
"From" address even though I've changed the MYNAME value in MERCURY.INI's
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.
[ Page modified 23 Mar 2000 | Content © David Harris
| Design by Technology