Sender: Date: Wed, 04 Dec 1991 11:49:02 EST From: "Earle Ake 513.429.6500" 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: 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