Sender: <ake@Dayton.SAIC.COM>
Date: Wed, 04 Dec 1991 11:49:02 EST
From: "Earle Ake 513.429.6500" <ake@Dayton.SAIC.COM>
To: madison@vms.ecs.rpi.edu
Message-ID: <009529B7.EAF7A506.14346@Dayton.SAIC.COM>
Subject: MX Trouble Shooting Guide 12/4/91
Symptom: Mail is not delivered to a local user.
Solutions:
1) Incorrect privileges for the account running MX.
A few things could cause this. MX 2.3 and earlier used a subprocess
to deliver the mail. If the account that is running MX has the proper
AUTHORIZED privs but not DEFAULT privs. When the local delivery agent spawns
the subprocess to deliver the mail, VMS gives this process the DEFAULT privs
and not the current privs for the parent. If you do not have enough of the
privs needed, you will see an "-RMS-E-PRV, insufficient privilege or file
protection violation" error in the MX_LOCAL_LOG.LOG file. This file will be
created if the logical name MX_LOCAL_DEBUG is defined to a non-null string.
$ DEFINE/SYSTEM/EXEC MX_LOCAL_DEBUG TRUE
Look at the debug logs created in the MX_ROOT:[LOCAL] directory.
2) Incorrect local path defined.
If you incorrectly defined the local system you may get mail into a
sending loop. The local system will accept mail but not know it is to be
delivered locally. It will then try to re-send the mail out and will receive
it back in and so on.
Symptom: MX to UUCP delivery fails
Solutions:
1) Mailer account does not have or has exceeded diskquota on uucp files disk.
In versions of MX previous to 2.3-1, even though EXQUOTA was enabled for
the mailer account, MX turned off privs not needed during message delivery.
EXQUOTA was turned off accidently during delivery to the uucp mailshr. Look at
the MX_ROOT:[UUCP]MX_UUCP_LOG.LOG file for
DELIVER_FILE: Subprocess says: EXIT:10000004
This is the indicator. Run diskquota and turn on a quota for the MAILER account
on the disk MX_ROOT:.
Symptom: Inbound mail from UUCP is not transferred to MX
Solutions:
1) The RMAIL command in UUCP_BIN:UUXQT_DCL.COM is not properly configured.
Edit the UUCP_BIN:UUXQT_DCL.COM and put in the hack to transfer UUCP
mail into the MX mail system.
Symptom: Mail is looping through your system and never delivered
Solutions:
1) Incorrect local path defined.
If you incorrectly defined the local system you may get mail into a
sending loop. The local system will accept mail but not know it is to be
delivered locally. It will then try to re-send the mail out and will receive
it back in and so on.
2) MXLOOKUP is over-anxious.
When NETLIB tries to lookup a domain and fails, it will try different
variations on your local domain. If you local node is "node1.company.com" and
mail is addressed to "user@node1", you had better have "node1" defined as a local
delivery under MCP. Likewise if someone has addressed something to
"user@node1.company" and has left off the ".com" part, MXLOOKUP tries to resolve
as "user@node1.company", then "user@node1.company.node1.company.com", then
"user@node1.company.company.com", then finally "user@node1.company.com". It
then sends the message to itself and MX receives the message. The message is
still bound for "user@node1.company" so iit goes through this process again!
The solution is to define paths "node1.company.com", "node1.company",
and "node1" as all being local delivery.
Symptom: SMTP-over-DECnet mail not working
Solutions:
1) The DECnet network object is not properly defined at the remote node.
Turn on debugging information by defining the system logical
MX_DNSMTP_DEBUG to TRUE. Debug information will be in the directory
MX_ROOT:[DNSMTP]. Have the system manager at the receiving site make sure
the object is defined per the instruction manual. Make sure that you have
used the same NCP object number on both systems.
2) The account that handles MX is the system account and the password has been
recently changed.
If the default account for MX is not MAILER and that password was
recently changed, the DECnet NCP object DECSMTP needs to have it's password
updated to the current password. If the MAILER account was used and the
password lifetime was not set /NOPWDLIFETIME, this would also cause this
problem.
3) DECnet object points to the wrong file.
Be sure the NCP object will run the file MX_EXE:DNSMTP-SERVER.EXE.
Make sure the username/password are correct if you are not using proxy access.
4) MCP route improperly defined.
Make sure that mail not destined for the local node will be transferred
to a remote node acting as the mail gateway. The last path defined in MCP
should look like:
MCP> DEFINE PATH * DECNET/ROUTE="gateway"
where gateway is the DECnet node name of the mail gateway node.
5) Inbound proxy not properly set up
If you have elected to use proxies instead of specifying user/password
in the NCP object, you might not have the proxy set properly. Make sure that
for every inbound SMTP-over-DECnet node, you have a proxy of the form
NODEA::MAILER
MAILER (D)
Symptom: Users can not send or receive messages over the Internet
Solutions:
1) MX starting before TCP/IP software
If you have many messages whose destination process is the mx_router and
you have an error message in the file [mx.smtp]smtp_server.log like:
%SYSTEM-F-MEDOFL, medium is offline
%TRACE-F-TRACEBACK, symbolic stack dump follows
module name routine name line rel PC abs PC
SMTP_SERVER ACCEPT_CONNECTION 384 00000064 00001E4C
SMTP_SERVER SMTP_SERVER 298 000002F6 00001D5A
You are probably starting MX before the TCP/IP software has been started. If
MX detects the TCP/IP software is down, it will shutdown the TCP/IP portions
such as the smtp server and smtp delivery agents. You must make sure that
your TCP/IP software is started BEFORE starting MX.
Symptom: MX is generating bad from lines when used with DECUS uucp.
Solutions:
1) A bug exists in the DECUS uucp mailer.
There is a bug in the DECUS uucp mailer which does not properly handle
a from line without the expected "remote by" at the end. The result is DECUS
uucp will generate a uucp from line that has a back-to-back set of bangs "!".
Adjacent uucp sites might complain of return addresses that look like
"mynode!!yournode!user". This is fixed in the 1.3-2 version of the mailshr
image. Ask for the new mailer in the vmsnet.uucp newsgroup or send a message
to one of the developers requesting the new image. The fixed came out July 91.
Symptom: MX is generating a bad reply address on outbound mail
Solutions:
1) There is a bad host definition in your TCP/IP software.
If you are using UCX and originally defined your nodename as the manual
states, you might not have used the fully qualified domain name (FQDN) such as
'xx.yy.com' and instead used 'xx'. Outbound messages will have a return address
of 'user@xxx'. The solution is to define your node similar to this:
ucx> set host "xx.yy.com"/address=128.1.1.2/alias=xx
If you are using MultiNet, you may have done the same thing. Look in
the file MULTINET:HOSTS.LOCAL and see if your own host definition is using the
FQDN or an alias. It should be using the FQDN. This is a bad entry for the
local host:
HOST : 192.75.138.1 : AC : MICROVAX-3100 : VMS : TCP/FTP :
This is what the entry SHOULD look like:
HOST : 192.75.138.1 : AC.NSAC.NS.CA : MICROVAX-3100 : VMS : TCP/FTP :
Since MX picks up the hostname from this entry, the outbound mail had
been going out with a return address of 'user@ac' instead of the proper name
'user@ac.nsac.ns.ca'.
--------------------------------------------------------------------------------
Return-Path: <ake@Dayton.SAIC.COM>
Received: from ECS02 (ECS02::MAILER) by MDMVS (MX Q3.0) with SMTP (DECnet);
Wed, 04 Dec 1991 11:49:21 EST
Received: from DAYVC.DAYTON.SAIC.COM by vms.ecs.rpi.edu (MX Q3.0) with SMTP;
Wed, 04 Dec 1991 11:47:23 EST
Received: by Dayton.SAIC.COM (MX Q3.0) id 14346; Wed, 04 Dec 1991 11:49:19 EST