TOPS-20 DECmail/MS V11 BEWARE File 16 Jul 86 COPYRIGHT (c) DIGITAL EQUIPMENT CORPORATION 1986. ALL RIGHTS RESERVED THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED ONLY IN ACCORDANCE WITH THE TERMS OF SUCH LICENSE AND WITH THE INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY OTHER COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO ANY OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS HEREBY TRANSFERRED. THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL EQUIPMENT CORPORATION. DIGITAL ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY OF ITS SOFTWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DIGITAL. TOPS-20 DECmail/MS V11 BEWARE File -- 16 Jul 86 Page 1 1.0 KNOWN PROBLEMS At this time, we are aware of a few known problems which we have not yet solved prior to shipping the DECmail/MS product. Depending on your use of the product, these problems may or may not impact your use of MS/MX. Unless otherwise noted, SPRs need not be sent in on these problems as we have a thorough understanding of these problems and will be addressing them in updates of DECmail/MS which will be distributed on Autopatch tapes. PLEASE NOTE: At the end of this beware file is a monitor patch which should be installed. o WHAT IS LOCAL MAIL ON CFS CLUSTERS - Systems which are clustered together present some unique problems for users when they send and receive mail on different systems within the cluster. For example, user XXX who receives mail on system A, and reads it and replies to all on system B, will receive an additional copy of the message. This is because MS on system B does not know that XXX@B is the same user as XXX@A. o OCCASIONAL MISSING <CR><LF> ON MESSAGE RECEIVED FROM A VAX - Occasionally, a mail message will be delivered to the system from a system using the MAIL-11 protocol and a carriage return and linefeed will be missing. There will be a corresonding 'Missing EOM ... ' message in the MX.LOG file. o MAIL RECEIVED FROM AN UNKNOWN NODE - When MX delivers mail to a TOPS-20 user from a node for which TOPS-20 does not know the node name, the node number will be used to identify the node which sent the mail. MS will be able to read the message, but there is no support in either MS or MX for sending or replying to that node until a name has been established for that node. o MX PROGRAM CRASHES - Occasionally the MX program will crash. We have fixed most all problems with MX crashing, however there do exist a few unreproducible crashes that we have not yet solved. If you experience MX crashing, PLEASE DO submit an SPR with a copy of the MX crash dump, MX log file, any text displayed by MX on the console, and any other pertinent information which might be useful in helping us solve the problem. o INFO PROGRAM RESTARTS - If the system program INFO is restarted, the MX program goes into an internal loop. MX must be restarted. TOPS-20 DECmail/MS V11 BEWARE File -- 16 Jul 86 Page 2 2.0 OBTAINING A CRASH DUMP OF MS/MX If you experience problems with MS or MX crashing, crash dumps can be obtained, which when sent to us, will assist in determining the problem. o Patch MS to make dumps in PS:<SPOOL>. NOTE: This will work only for privileged users unless the <SPOOL> area is unprotected for write access. (Unprotecting the <SPOOL> area should not normally be done). @GET MS @DEP IB+IB.FLG IP.STP @SAVE MS o Please read the installation doc file for info about obtaining dumps of MX. TOPS-20 DECmail/MS V11 BEWARE File -- 16 Jul 86 Page 3 3.0 INTERACTION WITH OTHER MAIL SYSTEMS MS/MX will provide message services between TOPS-10, TOPS-20, and VMS via DECnet links. Communication between TOPS-10/20 systems is accomplished using SMTP (Simple Mail Transfer Protocol (Arpanet spec. RFC822)). Communication to VMS systems uses the MAIL-11 protocol. 3.1 MMAILR/DMAILR/VMAILR Due to the previous lack of standard mail systems, MS-20 has a limited ability to interface to other non-supported TOPS-20 mail systems. At this time, MS-20 can coexist with the arpanet mailer called MMAILR provided that it knows about the POBOX: logical name. MS-20 will also coexist with the old DECnet mailers VMAILR and DMAILR. To give you control over which mailers MS will interface to, a flags word exists in MS, called NETFLG. These flags are used to control MS's behavior with mail that MX rejects due to its restrictions on mail protocols. Such mail can be requeued by MS, to be processed by MMAILR, DMAILR or VMAILR as appropriate. However, not all sites may have or desire such requeueing of mail. By lighting various RJ.nam bits in NETFLG, this requeueing can be prevented; instead, a warning message is typed to the user, explaining that MX has rejected the mail and MS is not allowed to queue it for other potential servers. Of the various bits defined, only RJ.AMA (reject ARPA mail) and RJ.VMA (reject mail to VMAILR or DMAILR) are implemented; the rest are reserved. Bits 0 through 11 may be used as desired by customers. When MS is started, the value of RJ.FLG is found in NETFLG. The default setting is RJ.VMA (reject VMAIL, DMAIL queueing, but attempt to queue mail for an external ARPA mailer if ARPA mail is given.) The flags are defined in MSCNFG.MAC, and NETFLG is found in MS.MAC. 3.2 ARMAIL ARMAIL is a utility subroutine package provided on the standard TOPS-20 distribution tape, which allows a customer to interface a user program to the mail system. It is currently also used by GALAXY and DUMPER for sending mail about archival requests. The ARMAIL.MAC found in the MS source area will communicate to MX. All previously released versions of ARMAIL communicate only to the MAILER program. Please recompile your version of GALAXY and DUMPER, and any user programs which interfaced to MAILER, using this new version of ARMAIL. TOPS-20 DECmail/MS V11 BEWARE File -- 16 Jul 86 Page 4 3.3 MAIL/RDMAIL/MAILER The MAIL, MAILER and RDMAIL programs were the supported programs for sending, receiving, and reading mail on TOPS-20. These programs will no longer be supported and are replaced by MS and MX. 4.0 REQUIRED MONITOR PATCH In cases where mail is received from a node which is not known to the monitor, i.e., whose name is not in the node and address table ADRTAB, then MX is unable to inform the recipient where the mail originated. In such a case, when the MTOPR function .MORHN is performed it fails with error NSPX24 (Node name not assigned to a network node). MX, as a result, returns with a null node name which results in the string <USERNAME@>. It turns out that the monitor does know the node address of a node even if it does not know the node's name. Therefore, we have modified the monitor so that in those cases where the node name is unknown, the node address is returned in the right half of the word pointed to by AC3 in the MTOPR .MORHN call. MX will then reformat the address and report the sender as <USERNAME@AREA .NODE >. The following is the DDT patch that must be inserted into the monitor: $GET SYSTEM:MONITR $START 140 DDT NTRHST+3/ CALL SCTA2N JRST FFF+2 FFF/ 0 MOVADR: MOVE T3,3 FFF+1/ 0 MOVEM STS,0(3) FFF+2/ 0 PUSH P,STS FFF+3/ 0 MOVE STS,T1 FFF+4/ 0 CALL SCTA2N FFF+5/ 0 JRST FFF+10 FFF+6/ 0 POP P,STS FFF+7/ 0 JRST NTRHST+5 FFF+10/ 0 XCTU MOVADR FFF+11/ 0 XCTU MOVADR+1 FFF+12/ 0 POP P,STS FFF+13/ 0 JRST LSCJSY+66 FFF+14/ 0 FFF: FFF+1/ 0 ^Z $SAVE SYSTEM:MONITR TOPS-20 DECmail/MS V11 BEWARE File -- 16 Jul 86 Page 5 5.0 UNSUPPORTED COMMANDS MS contains a few commands which are unsupported and invisible to the user. These commands have been included only for command file compatibility with older versions of MS. Use of these commands is not advised as the results can be indeterminate. The commands are: ANSWER, BBOARD, ECHO, EMACS, PREVIOUS, REDISTRIBUTE, SHOW INTERNAL-INFORMATION, SSEND, SUMMARIZE, ZSEND