V'0);0Message Exchange Management Guide9

Message Exchange Management Guide





*

October, 1998



HThis manual describes the management and operation of Message Exchange, )electronic mail software for VMS systems.

.Revision/Update Information: This is a revised manual.

.Operating System and Version:VAX/VMS V5.2 or later

OpenVMS Alpha V1.5 or later

"Software Version:Message Exchange V5.1


17 October 1998

EThe information in this document is subject to change without notice Aand should not be construed as a commitment by MadGoat Software. CMadGoat Software assumes no responsibility for any errors that may appear in this document.

<No part of this publication may be reproduced, transmitted, Btranscribed, stored in a retrieval system, or translated into any Glanguage or computer language, in any form or by any means electronic, Hmechanical, magnetic, optical, chemical, or otherwise without the prior 'written permission of MadGoat Software.

CUse of this software and documentation is subject to the terms and .conditions set forth in the License Agreement.

AThe Licensed Materials are provided with RESTRICTED RIGHTS. Use, Hduplication, or disclosure by the Government is subject to restrictions Has set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data <and Computer Software clause at DFARS §252.227-7013 or 8subparagraphs (c)(1) and (2) of the Commercial Computer FSoftware---Restricted Rights at 48 CFR §52.227-19, as applicable.

EMadGoat, Message Exchange, and MX are trademarks of MadGoat Software.

>The following are trademarks of Digital Equipment Corporation:               
DEC DECnet P.S.I.
ULTRIX VAX  VAXcluster
VMS AXP  VMScluster


;Jnet is a registered trademark of Wingra Technologies, Inc.

CMultiNet and TCPware are registered trademarks of Process Software Corporation.

;LISTSERV is a registered trademark of L-Soft International.

AWIN/TCP and Pathway are registered trademarks of Attachmate, Inc.

Copyright ©1998



 , 4  
GContents AIndex
 


$

Preface



FThis guide describes the management and operation of Message Exchange (MX).4

Intended Audience



HThis manual is intended for use by the system manager or any individual Dresponsible for installing and maintaining MX. The reader should be Egenerally familiar with VMS system concepts, electronic mail systems and networking terminology.5

Document Structure



FThis guide consists of two parts. Part I contains nine chapters which ?contain information on management and operation of the various Gcomponents of MX. Part II is the command dictionary for the MX Control Program (MCP).                                    
 Chapter 1 ? Contains information about how Message Exchange operates.
 Chapter 2 2 Describes how to use the MXCONFIG procedure.
 Chapter 3 3 Describes how to manage the Router functions.
 Chapter 4 : Describes how to manage the message delivery agents.
 Chapter 5 7 Describes how to manage the message entry agents.
 Chapter 6 0 Describes how to manage the message queue.
 Chapter 7 0 Describes some miscellaneous MX utilities.
 Chapter 8 ; Describes the tools available for troubleshooting MX.
 Chapter 9 ' Describes the MX startup process.
4

Related Documents



?You can find additional information in the following documents:

 


T

Chapter 1
Overview of Message Exchange Operation




/This chapter briefly describes how MX operates.S

1.1 What is a Message?



AElectronic mail messages are usually divided up into three parts:



FThere are several standards for the format of each part of a message. FMX uses the Internet RFC 822 format for message headers and body, and HInternet RFC 821 format for envelope information. When sending messages Gto non-Internet sites, MX will convert the message format as needed to >comply with the standards required by the destination system. kFigure 1-1 is an example of a message broken down into its parts.

)Figure 1-1 Message parts




 

"
 
Envelope:  1    <user1@host1.org>       Return address /    <user2@host2.org>       Recipient #1 /    <user3@host3.org>       Recipient #2  	Headers:  N    Received: from host1.org by host2.org with SMTP; 01 Oct 1990 12:32:01 EDT (    Date: Mon, 01 Oct 1990 11:19:47 EDT     From: user1@host1.org     To: user2@host2.org     Cc: user3@host3.org     Subject: Hello there  Body:  1    Just a quick note to let you know I'm alive.     Have a nice day.  


 T

1.2 What is an Address?



EMuch like the address on a real envelope, an electronic mail address Findicates where a message should be delivered, or where it came from. GMX uses the Internet RFC 822 format for addresses. RFC 822 specifies a 9very rich syntax for addresses, but most are of the form:

   

"
-                           local-part@domain 

>Where domain usually identifies a system and ?local-part identifies the user on that system.

#Envelope Addresses


;Envelope addresses are kept by MX in a special format, the ?route-address, which adheres to Internet RFC 821. Users cannot Bgenerally use route-addresses when addressing mail; they are used Ainternally by MX and other mail systems for tracking the route a Fmessage has taken to get from source to destination, or for forcing a +particular route to be taken for a message.

A route-address has the form

   

"
<local-part@domain> %                                  or /<@domain[,@domain...]:local-part@domain> 

DThis form of addressing is discouraged on the Internet, but is used ;when messages are gatewayed between multiple mail networks.N

1.3 MX Components



+Message Exchange consists of several parts:

<

1.3.1 The Message Queue



CAll MX messages are stored in a directory called the message queue D(sometimes called the file queue). This is the directory pointed to by theClogical name MX_FLQ_DIR. Besides the files comprising the messages <themselves, the queue directory also contains a file called BMX_SYSTEM_QUEUE.FLQ_CTL. This file, called the queue control Efile, is a sequential file that contains information about the Cstate of each message, who is processing it, etc. All MX processes 5access their queue entries through this control file.

DThe size of the queue control file determines the maximum number of Centries that can be in the queue at any given time. The larger the 0file, the more entries that can be in the queue.

HBecause the message queue is shareable cluster-wide, a user on any node Fin a VMScluster can send messages over a network, even if there is no @direct network connection (via TCP/IP, X.25, UUCP, etc.) on the ,particular node to the target network.¹?

1.3.2 Message Entry Agents



DMessages are entered into MX by users from VMS Mail through the MX% Gprotocol prefix. This invokes routines in image MX_EXE:MX_MAILSHR.EXE, Hwhich create the necessary files in the message queue for processing by the Router.

2Messages coming in from other hosts are handled by



BMessages are also entered into the queue by the Mailing List/File AServer (MLF) agent, in response to a mailing list or file server request.5

1.3.3 The Router



EThe Router is responsible for taking the envelope information from a Fmessage and determining where the message should be sent based on the !addresses listed in the envelope.

DEach recipient address in the envelope is processed in two or three phases:

    F
  1. In the rewrite phase, the address is checked against a G list of rewriting rules. If it matches one of the rules, the rule is / applied and the original address is replaced.G
  2. In the path identification phase, the next hop I domain of the address is identified and that domain is checked against H the domain-path mapping list. This identifies the delivery agent that < will be called on to deliver the message to the recipient.I
  3. If the recipient is on the local system, a third phase is entered, F which checks to see if the local-part of the address is an F alias for another address, a mailing list name, or file server name.


EThe Router is also responsible for maintaining the message queue. It *cleans out completed or cancelled entries.:

1.3.4 Delivery Agents



HThe Local delivery agent delivers mail to local users or to other hosts Dover DECnet using VMS Mail. It also identifies local users who have Hused SET FORWARD to direct their mail elsewhere and resends messages to their forwarding addresses.

<Other delivery agents send messages to other hosts or other mail-processing software.



EEach delivery agent is responsible for converting MX-format messages ?into the format required for the particular network or network interface package.4

1.3.5 MLF Agent



GThe Mailing List/File Server (MLF) agent is a special form of delivery Eagent that handles mailing list and file server requests. It doesn't Hactually deliver messages to a network directly. What it does is create Dnew messages based on the list or server requests and sends the new Cmessages back to the Router for processing and eventual delivery. 



/   
N
Note

 F

¹ When following the MX clustering R guidelines described in Message Exchange Installation Guide.






J

Chapter 2
Configuring MX with MXCONFIG




CThis chapter describes the MXCONFIG procedure, MX_DIR:MXCONFIG.COM.R

2.1 Why Use MXCONFIG?



EConfiguring MX by hand can be a complicated and error-prone process, Gdue to the number of options available. Based on a question-and-answer Dscript, MXCONFIG creates the MX startup information for its logical @names and agent invocation, as well as a command file that will Cgenerate an MX configuration database. Configurations created with HMXCONFIG should be adequate for most Internet and BITNET/EARN sites; it Ecan also be used as a base that can be tailored using the MX Control Program (MCP), if needed.O

2.2 Using MXCONFIG



GWhen you execute MXCONFIG, it displays a menu of configuration options:

 

"
 ;                  Message Exchange Configuration Procedure  
Main Menu  1    1. Configure MX message queue logical names. 5    2. Configure MX host and timezone logical names. %    3. Configure MX agent processes. ,    4. Create an MX configuration database. !    5. Exit from this procedure.  Enter choice: 




DTo completely reconfigure MX, start with menu option 1, then select Feach of the other options in order as you complete each section. Each Dsection displays information about the items being configured, then Casks you to answer some questions. Read the explanations carefully before answering.

GWhen you are finished with your configuration changes, select option 5 Ffrom the main menu to exit from the configuration procedure. You will Bbe asked whether you would like to save the configuration changes before the procedure exits. 


A

Chapter 3
Managing the Router




FThis chapter describes the MCP commands used to configure and control the Router.N

3.1 Rewrite Rules



AAddress-rewriting rules, or rewrite rules for short, areGchecked by the Router for every recipient address on every envelope of Cevery message that passes through MX. A rewrite rule consists of a Epattern and a result. If an address matches the pattern, the rule is Happlied and the address rewritten per the rule's result. The purpose of Cthis is to provide a general means of altering envelope addresses, Fprimarily for handling multi-gateway cases where DEFINE PATH/ROUTE is insufficient.

FBe careful, since the rule processor treats the addresses as ordinary Ftext strings and does not understand the syntax of RFC 821 addresses. GBecause they were designed mainly for handling domain aliases, rewrite (patterns are matched from right to left.

AThe rewrite rule list is searched only once per address, until a Fmatching pattern is found. Once a match is found, no additional rules @are searched. If no rule matches an address, further processing "continues on the original address.

DAn example of an application for rewrite rules is the mapping of an Eartificial domain name, such as host.dnet, :into an address for delivery through VMS MAIL over DECnet:

 

"
:MCP> DEFINE REWRITE_RULE "<{user}@{host}.dnet>" -H_MCP>                    "<""{host}::{user}""@local.host.name>"




CThe pattern matching routine treats the variable references in the Efirst string as wildcards; everything between the left angle bracket Cand the at sign is copied into the {user} variable, and everything Hbetween the at sign and the string .dnet> is copied =into the {host} variable. The variable names have no special -significance to the pattern matching routine.!X

3.2 Defining Delivery Paths



EThe first step the Router takes in determining a delivery path is to >identify the next hop the message should take. The next hop isDdetermined by looking at the address and selecting either the first Fdomain in the route path at the beginning of the address, or if there Gis no route path, the destination domain. The second step is to search Cthe list of defined domain/path mappings to determine the delivery 2path, and possibly a routing host for that domain.

DThe MCP DEFINE PATH command is used to create a domain/path mapping.@A mapping consists of a domain pattern (possibly containing VMS Ewildcard characters) and the name of the delivery path to be used if <the next hop matches the domain pattern. Possible paths are 9DECNET_SMTP, JNET, LOCAL, SITE, SMTP, UUCP, and X25_SMTP.

GFor example, a typical path list for an Internet host might be created with the commands:

 

"
0MCP> DEFINE PATH myhost.mycompany.ORG   LOCAL@MCP> DEFINE PATH myhost                 LOCAL  ! abbreviationCMCP> DEFINE PATH [1.2.3.4]              LOCAL  ! numeric address/MCP> DEFINE PATH *                      SMTP




FWhen setting up a path for X25_SMTP traffic, the DTE logicals defined Cin the PSI$DTE_TABLE logical name table should be specified as the C/ROUTE values. For example, assume two nodes wish to exchange mail Husing X25_SMTP. Node A's domain name is node_a.foobar_org.whatever, and BNode B's name is node_b.whocares_org.whatever. The MCP command to #define the path on node A would be:

 

"
8MCP> DEFINE PATH "*.whocares_org.whatever" X25_SMTP -&_MCP> /ROUTE="WHOCARES_DTE_LOGICAL"




$On Node B, the MCP command would be:

 

"
6MCP> DEFINE PATH "*.foobar_org.whatever" X25_SMTP -$_MCP> /ROUTE="FOOBAR_DTE_LOGICAL"


Cwhere the *_DTE_LOGICALs are the logicals defined in PSI$DTE_TABLE.

HThe path list is searched sequentially until a match is made. The first Ethree rules catch any locally-addressed messages. The next two rules @provide transparent routing of addresses in the BITNET and UUCP E"fake domains" through their respective Internet gateways. CThe last rule, which would match any other domain name, routes all Aother messages off-system via SMTP. Notice that abbreviations or Dnicknames for the local host must have LOCAL path definitions to be recognized by MX.=

3.2.1 DOMAIN.NAMES Paths



HIf no paths from the configuration file match a domain name, the Router Gwill automatically examine paths built from a BITNET/EARN DOMAIN.NAMES Ffile, which describes the appropriate BITNET/EARN routes for Internet rdomain-style addresses. See Section 4.3.5 for further information about obtaining a DOMAIN.NAMES file.R

3.3 Alias Translation



FThe third phase of Router address processing is the identification andCtranslation of local aliases. The system manager or postmaster can Bdefine aliases on the local system that translate to any local or Gremote address with the MCP DEFINE ALIAS command. If an address, after Fpassing through the first two Router phases, is identified as a local Faddress, the Router searches the alias list. If the local part of the Eoriginal address matches one of the aliases, the original address is Cdiscarded and the alias address is substituted in its place and is 3passed through the other address processing phases.

HNote that alias processing is totally transparent to the sender as well Gas the recipient of a message. No message headers are changed or added Fto indicate that the message is being forwarded via an alias address. @In addition, aliases are kept in a simple list that is searched Dsequentially, rather than a more efficient structure. For these two @reasons, it is recommended that aliases be used sparingly. Mail @forwarding is better done with the VMS MAIL SET FORWARD command.

DAlso performed during this phase is "percent-dehacking" ofEaddresses. MX supports the "percent-sign hack" that allows Busers to route messages through the local system by specifying an Gaddress of the form "user%host1@host2". If the local part of Dthe address is found to contain a percent sign, the percent sign is Hconverted to an at sign, the original address is discarded, and the new Aaddress is substituted as for aliases. While this form of routed Gaddressing is not recommended, it is sometimes required when the local Fhost is acting as a gateway between two networks. You can disable the 4percent-dehacking function with the MCP command SET ROUTER/NOPERCENT_HACK._

3.4 Controlling the Router Process



FThe Router process will respond to shutdown and reset signals sent by Hthe MCP SHUTDOWN and RESET commands, respectively. Using these commands Bis the only way that the Router can be shut down or reset without possibly losing messages.

DYou can control Router functions, such as creation of an accounting %log, with the MCP SET ROUTER command.V

3.5 Logging Router Events



CMajor events in the Router process, such as startup, shutdown, and Cconfiguration resets, are automatically logged to the Router's log Ffile, MX_ROUTER_DIR:MX_ROUTER_nodename.LOG_process-id. These Aevents may also be logged to an operator console by defining the logical name MX_EVENT_OPER_CLASS:

 

"
3$ DEFINE/SYSTEM/EXEC MX_EVENT_OPER_CLASS class-name




Fwhere class-name can be any recognized OPCOM operator class, such as NETWORK.

HThis logical name must be defined before MX is started Fin order to have any effect. Its definition affects all MX processing agents. 


J

Chapter 4
Managing the Delivery Agents




FThis chapter describes some of the MCP commands used to configure and 'control the various MX delivery agents.W

4.1 Local Delivery Options



CThe local delivery agent can be configured to place message header Blines at either the beginning of the message text, the end of the @message text, or both, when delivering locally through VMS Mail.

?In addition, you can control whether accounting information is Hgenerated, the delivery retry interval, and the maximum retry count. By Fdefault, unsuccessful deliveries into VMS Mail are retried every half Ahour up to 96 times total (giving a two-day period) before being returned to sender.

FThe MCP SET LOCAL command can be used to alter any of these settings; 9refer to the command description for further information.q

4.2 SMTP, DECNET_SMTP, and X25_SMTP Delivery Options



HAs with the local delivery agent, you can alter the accounting setting, Gthe retry interval, and the maximum retry count for SMTP, DECNET_SMTP, Hand X25_SMTP deliveries. However, the SMTP agent differentiates between Hfailed deliveries due to domain name lookup failures and other kinds of Gfailed deliveries, and you can set a different maximum retry count for @DNS lookup failures. The MCP SET SMTP, SET DECNET_SMTP, and SET HX25_SMTP commands are used to alter the settings for the three delivery Hagents. The defaults are 30 minutes for retry interval, 12 DNS failures 9maximum (for SMTP only), and 96 general failures maximum.

:Refer to the command descriptions for further information.V

4.2.1 Internet "Mail Exchanger" Support



DSome of the supported TCP/IP packages include domain name resolvers Fthat provide access only to host name-to-address mapping information. BHowever, not all Internet domain names map directly to addresses. HDomain names are also used to identify hosts on other networks to which Felectronic mail can be sent via some other Internet-connected gateway )host, called a mail exchanger.

FMail exchangers are recorded in the Internet Domain Name System (DNS) Gusing mail exchanger resource records (MXRRs). The initial list of DNS Eservers to be asked for MXRR information is controlled by the NETLIB Dsoftware. Refer to the NETLIB documentation for further information.>

4.2.2 Default SMTP Router



GWhen the local system uses host tables instead of Domain Name Service, Gyou may want to establish a default router for SMTP messages. The SMTP delivery agentHwill automatically forward to the default router all messages addressed Fto users on hosts whose names are not found either in the Domain Name BSystem or in the local host table provided by your TCP/IP package.

HA default router is established in MCP with the SET SMTP/DEFAULT_ROUTER command.

8Before you use a default router, you should ensure that:

S

4.3 The Jnet Interface



FThe MX/Jnet interface module runs as a detached process. For incoming Dmessages, it will convert CMS NOTEs and PROFS notes into mostly-RFC F822-compliant messages. Also supported is BSMTP for both incoming and 6outgoing mail to BITNET nodes with registered mailers.B

4.3.1 Jnet Address Conversion



DThe Jnet interface will automatically convert addresses on outgoing >mail such that local addresses use the RSCS node name and all Bnon-BITNET, non-local addresses are "percent-hacked" to Aprovide a route back through the local system for hosts that are connected only to BITNET.

DBITNET-style addresses are automatically percent-hacked on incoming Emessages and de-hacked when outgoing, to guarantee a return path for Dmail being forwarded to other networks. If Jnet is the only network Htransport you are using for mail, you can disable this feature with the HMCP SET JNET/NOPERCENT_HACK command. This is done automatically for you 6if you use the MXCONFIG.COM procedure to configure MX.

DYou can also use the SET JNET command to control whether accounting Finformation is generated and whether BSMTP replies are generated. See 9the SET JNET command description for further information.9

4.3.2 Gateway Policy



DBITNET/EARN rules prohibit Internet/BITNET gateways from gatewaying Hmail to or from BITNET hosts that do not have a BSMTP-compliant mailer. HMX enforces these rules unless you use the MCP SET JNET/LENIENT command.9

4.3.3 Jnet Node Name



DMX will use the Jnet cluster node name on all outgoing mail, if you Dhave enabled Jnet clustering. Otherwise, MX will use the local Jnet Gnode name. You can override this selection by defining the logical name MX_JNET_NODE:

 

"
%$ DEFINE/SYSTEM MX_JNET_NODE nodename




=No validity checking is performed on the specified node name.:

4.3.4 Mailer Username



GBITNET mail protocols require the use of a reserved "mailer" Fusername, through which most incoming and outgoing mail messages will Hbe sent. This username is registered in the BITNET/EARN node tables and @is used by other mailers on the network to determine which mail Gprotocols can be used to communicate with your system. The recommended Dmailer username is MAILER. You should not use SYSTEM as your mailer username.

HYou can implement a mailer username either with the /USERNAME qualifier Don the SET JNET command or by running the MX/Jnet interface under a Hmailer account you create specifically for use with MX, as described in -Message Exchange Installation Guide._

4.3.5 XMAILER.NAMES, DOMAIN.NAMES, and BITEARN.NODES Files



HIn order to communicate with other mailers on BITNET, you must register Gyour node's mailer username in the BITNET/EARN node table. Information Hon how to update your BITNET node entry can be obtained from your local LISTSERV@BITNIC:

 

"
*$ SEND LISTSERV@BITNIC GET UPDATE PROCEDUR




GThe person performing the update must be the BITNET contact person for 8the node being updated, or some other authorized entity.

BThe following example shows a typical command used to update your BITNET node entry for MX:

 

"
MODIFY NODE node 1:servers1.mailer@node(MAIL,ND PU,M,BSMTP,P_user) 




CThis command can be sent to UPDATE@BITNIC to establish your mailer Eaccount (substituting the appropriate username and node, of course). DJnet can received mail files in either NETDATA or PUNCH format; the H"ND PU" in the command above will inform other BITNET mailers Ethat your node can accept both (and prefers NETDATA). NETDATA is the Fpreferred format, because there is no line length limitation as there is for PUNCH files.

BIn order for MX to determine the capabilities of mailers on other Asystems on BITNET, you must provide either BITEARN.NODES file or EXMAILER.NAMES. If you're not directly connected to the Internet, you Fshould also provide DOMAIN.NAMES. All three files are described below.

FIf BITEARN.NODES is available, then MX can send either files via Jnet Has either NETDATA or PUNCH, depending on the preference established for Ethe target nodes. If XMAILER.NAMES is used instead, only PUNCH files Hcan be sent, because preferred mail format information for nodes is not supplied in XMAILER.NAMES.!W

4.3.5.1 BITEARN.NODES and MXBITNET.MAILERS Files



GThe file BITEARN.NODES contains descriptions of all the systems on the >BITNET/EARN networks. Every BITNET node is fully described in DBITEARN.NODES; the file XMAILER.NAMES is created from this file. In <order to provide support for sending NETDATA files, MX uses EBITEARN.NODES to create its own mailer file, called MXBITNET.MAILERS.

BITEARN.NODES


FBecause all BITNET nodes are listed in BITEARN.NODES, the file can be Fpretty big (several thousand blocks). You can arrange to have monthly Bupdates sent to you from a NETSERV site near you. By applying the 7monthly updates, your mailer information stays current.

HYou can obtain a copy of BITEARN.NODES from your local NETSERV, or from NETSERV@BITNIC:

 

"
'$ SEND NETSERV@BITNIC GET BITEARN NODES




GThe file may also be available from a neighboring site; because of the Dfile's size, you might try to acquire a copy from a neighbor before requesting it from NETSERV.

HIf you have a NETSERV access password, you can have the monthly updates Hdistributed to you automatically with the NETSERV AFD command. Send the Ecommand HELP to your local NETSERV for further information. Software Bfor applying the updates can be obtained by sending the following ;commands in the body of a mail message to FILESERV@WKU.EDU:

 

"
SEND UPDNODES SEND FILESERV_TOOLS 




!MXBITNET.MAILERS


@If the file BITEARN.NODES is found in MX_JNET_DIR:, the MX Jnet Ginterface will scan the file for mailer information for all the nodes, ;producing the MX-private file MX_JNET_DIR:MXBITNET.MAILERS.G This file contains the mailer names for all BITNET sites, as well as J the sites' preferred mail formats. This file is then read during the MX H Jnet interface initialization; when mail is sent to a BITNET site, MX D consults the data from this file to determine whether the message I should be sent as a PUNCH file or as a NETDATA file. Lines are wrapped > at 80 characters for PUNCH files, but not for NETDATA files.

HYou can avoid the need for maintaining BITEARN.NODES if you get it from Gthe VMS Store, a repository of VMS utilities maintained by Eric Thomas 8(ERIC@SEARN.BITNET). You can get the current version of 5MXBITNET.MAILERS by sending the following command to LISTSERV@SEARN.BITNET.

 

"
8$ SEND LISTSERV@SEARN GET <BITNET>MXBITNET.MAILERS




DYou can also have MXBITNET.MAILERS automatically distributed to you 'each month using the following command.

 

"
<$ SEND LISTSERV@SEARN AFD ADD <BITNET>MXBITNET.MAILERS


!A

4.3.5.2 XMAILER.NAMES File



HIf you elect not to use BITEARN.NODES and/or MXBITNET.MAILERS, then you Gshould obtain an XMAILER.NAMES file for your RSCS network and place it Fin the directory MX_ROOT:[JNET]. For BITNET hosts, you should be able Dto obtain this file from your local NETSERV, or from NETSERV@BITNIC:

 

"
'$ SEND NETSERV@BITNIC GET XMAILER NAMES




FIf you cannot contact a NETSERV server, the contact person for a host :that is upstream from you should have a copy of this file.

FIf you do not have a copy of this file in MX_ROOT:[JNET], MX will not Gbe able to contact mailers at other sites on the networks, nor will it Hbe able to use the BSMTP protocol, which is required when communicating with the INTERBIT gateways. @

4.3.5.3 DOMAIN.NAMES File



HIf you do not have a direct Internet connection, you should also obtain Ga copy of DOMAIN.NAMES and place it in MX_ROOT:[JNET]. The Router will Duse this file to route non-BITNET messages to appropriate gateways. ,DOMAIN.NAMES is also available from NETSERV:

 

"
&$ SEND NETSERV@BITNIC GET DOMAIN NAMES




FIf you cannot contact a NETSERV server, the contact person for a host :that is upstream from you should have a copy of this file.

HThese files are updated monthly. If you have a NETSERV access password, Gyou can have the monthly updates distributed to you automatically with Ethe NETSERV AFD command. Send the command HELP to your local NETSERV for further information.

FIf you cannot obtain an XMAILER.NAMES file for your RSCS network, you Hcan create one for your own use. You need one line in the file for each @node in your network. Each line in the file must be of the form:

 

"
5:nick.HOSTNAME :alias.ALIAS :net. :mailer. :netsoft. 




Fwhere "HOSTNAME" is the name of the host, "ALIAS" @is either the host name repeated or an alias for the host name, B":net." is followed by the name of the network the node Hresides on (optional for use with MX), ":mailer." is followed Aeither by a blank (indicating no mailer) or by a mailer username Fdesignation, and ":netsoft." is followed by the name of the 7RSCS software in use on the node (optional for MX use).

AYou should only specify a mailer username for other nodes runningGMX or running some other mailer package that can handle BSMTP. Be sure Gthat the other mailers on your network are also aware of your system's Amailer username in order to take full advantage of BSMTP message Etransfers. Until your mailer username is registered, you should omit 4any reference to mailers in your XMAILER.NAMES file.V

4.4 UUCP Delivery Options



GThe MX_RMAIL program (part of the UUCP interface) can be configured to Guse DECUS UUCP's MAIL_REWRITE rules to translate addresses on messages Hcoming in from UUCP. To use this feature, execute the following logical Dname definition to your system startup procedure before starting MX:

 

"
$$ DEFINE/SYSTEM MX_UUCP_REWRITE TRUE




EThe MX_RMAIL program will automatically use the rewrite rules in the Ffile UUCP_CFG:MAIL_REWRITE.RULES. If you would rather define your own EINBOUND_TO and INBOUND_FROM rules for use by MX_RMAIL, place them in Gthe file MX_UUCP_DIR:UUCP_MAIL_REWRITE.RULES. If that file is present, 5MX_RMAIL will use it instead of the file in UUCP_CFG.V

4.5 SITE Delivery Options



EThe SITE delivery agent includes support for retry on error. The MCP ESET SITE command can be used to alter the retry interval and maximum Cretry count. Refer to the SET SITE command description for further information."W

4.6 The LISTSERV Interface



GThe MX/LISTSERV interface module runs as a detached process. If L-Soft GInternational's LISTSERV product is installed on the system, MX Router Gautomatically detects messages destined for LISTSERV and mailing lists ;and passes them on to the LISTSERV software for processing.

,There are no MCP commands to control MX LSV.U

4.7 Shutdowns and Resets



GEach of the delivery agents will respond to shutdown and reset signals Das sent by the MCP SHUTDOWN and RESET commands, respectively. Using Gthese commands is the only guaranteed way of cleanly shutting down and Dresetting the delivery agents, without loss of messages in progress.

DThere may be times when it is necessary to prevent local users from Husing VMS Mail to send mail via MX. To do so, define the executive-mode system logical name MX_SHUTDOWN:

 

"
%$ DEFINE/SYSTEM/EXEC MX_SHUTDOWN TRUE




BIf a user tries to send mail to an MX% address and MX_SHUTDOWN is Edefined, VMS Mail (MX_MAILSHR) will display an error message stating <that MX has been temporarily disabled by the system manager.^

4.8 Logging Delivery Agent Events



DMajor events in the delivery agents, such as startup, shutdown, and Cconfiguration resets, are automatically logged to each agent's log @file. These events may also be logged to an operator console by defining the logical name MX_EVENT_OPER_CLASS:

 

"
3$ DEFINE/SYSTEM/EXEC MX_EVENT_OPER_CLASS class-name




Fwhere class-name can be any recognized OPCOM operator class, such as NETWORK.

HThis logical name must be defined before MX is started Fin order to have any effect. Its definition affects all MX processing agents. 


K

Chapter 5
Managing Message Entry Agents




GThis chapter describes the options available with the MX message entry agents.T

5.1 Local Message Entry



DThe VMS MAIL interface (MX_MAILSHR) is used for local message entry.G It is controlled through the definition of system-wide logical names.

=Use of MX through VMS Mail can be restricted by defining the Dexecutive-mode logical MX_RESTRICT_USAGE in the system logical name table:

 

"
+$ DEFINE/SYSTEM/EXEC MX_RESTRICT_USAGE TRUE




AIf the logical is defined, the user must hold the MX_MAIL_ACCESS Bprocess rights identifier in order to send mail using MX. The VMS :utility AUTHORIZE is used to create and grant identifiers:

 

"
$ set default sys$system:$ run authorize%UAF> ADD/IDENTIFIER MX_MAIL_ACCESSEIdentifier MX_MAIL_ACCESS value: %X8001000D added to rights data base2UAF> GRANT/IDENTIFIER MX_MAIL_ACCESS GOATHUNTER/Identifier MX_MAIL_ACCESS granted to GOATHUNTERUAF> 




DUsers not holding the identifier and trying to send mail through MX Gwill see an error message stating that they are not authorized to send mail using MX.X

5.1.1 System-wide MX Aliases for Outgoing Addresses



DMX supports the use of personal and system-wide alias databases for Fdefining aliases for frequently-used addresses for outgoing mail. The bMXALIAS utility, described in the Message Exchange User's Guide, is used to maintain the database file.

GTo create a system-wide alias database, you can use the USE command in CMXALIAS to open a centrally-located database file that can then be Fpopulated with the ADD command. To make the file accessible to users, =set the protection to allow WORLD:READ access and define the 6MX_GLOBAL_ALIAS_DATABASE logical to point to the file:

 

"
/$ set file/prot=w:re mx_dir:mx_global_alias.datH$ define/system/exec mx_global_alias_database mx_dir:mx_global_alias.dat




DYou will also need to add the DEFINE command to your system startup.C

5.1.2 VMS MAIL Protocol Prefix



7MX by default uses the foreign protocol prefix MX% whenEinterfacing with VMS Mail. You can define alternate foreign protocol Eprefixes for use with MX, to provide a migration path for users from Aother mail systems to MX. MX will correctly handle the following @prefixes: SMTP%, WINS%, IN%, JNET%, IHMF%, VN%, ST%, INET%, and DUUCP%.¹ To set up one of these alternate prefixes in VMS Mail, -define the logical name MAIL$PROTOCOL_prefix:

 

"
4$ DEFINE/SYSTEM/EXEC MAIL$PROTOCOL_prefix MX_MAILSHR


Fwhere prefix is one of the above-mentioned prefixes, "without the trailing percent sign.

HNote that incoming mail from MX will always bear the MX% prefix. If you Awish to use another prefix for incoming mail, you can define the logical name MX_PROTOCOL_PREFIX:

 

"
/$ DEFINE/SYSTEM/EXEC MX_PROTOCOL_PREFIX prefix%


Fwhere prefix is one of the above-mentioned prefixes, >with the trailing percent sign. The default prefix MX% is the recommended prefix.=

5.1.3 Default Host Names



FBy default, MX uses the logical name MX_NODE_NAME as the host name to @be appended when converting a username into a full network mail Daddress. For sites that require more control over how addresses are 3formatted, additional logical names may be defined.

BThese logical names are not automatically defined by MX; you must Hdefine them yourself (e.g., in your system startup procedure). The must Bbe defined in executive mode, but may reside in the process, job, Agroup, or system logical name table. The logical names and their Mdescriptions are in Table 5-1.

P  ' &              
Table 5-1 Address Formatting Logical Names
Logical name Description
 MX_ENVELOPE_FROM_HOST E Host name to be used when formatting envelope return addresses + (equivalent to the RFC821 MAIL FROM).
 MX_FROM_HOST < Host name to be used when formatting the From: header.
 MX_TO_HOST 8 Host name to be used when on a To: or Cc: address.


DYou can also affect address formatting by installing a SITE address aconversion callout. See the Message Exchange Programmer's Guide for more information on address conversion callouts.X

5.1.4 Disabling Automatic Quoted-Printable Encoding



FMX_MAILSHR automatically detects the inclusion of 8-bit characters in Houtgoing messages, causing the messages to be re-encoded using the MIME Bquoted-printable content transfer encoding. In some locales, this Eautomatic encoding may not interoperate properly with other systems, Fand this feature should be disabled. To do this, define the following logical name:

 

"
0$ DEFINE/SYSTEM/EXEC MX_MAILSHR_IGNORE_8BIT TRUE


EThe value of the equivalence string is unimportant; the existence of <this logical name will cause 8-bit characters to be ignored.

DIf Kanji support is enabled, automatic quoted-printable encoding is also disabled.



/   
N
Note

 O

¹ You should not re-direct the UUCP% prefix L to MX if you are using MX with UUCP. Doing so will prevent messages M from being delivered to UUCP from MX, since MX uses the UUCP_MAILSHR 0 interface (the same as UUCP% does).



L

5.2 SMTP_SERVER



GThe SMTP server is a detached, multi-threaded process. You can specify Dhow many threads the server should handle simultaneously by defininga logical name:

 

"
-$ DEFINE/SYSTEM/EXEC MX_SMTP_SERVER_THREADS n




EThe value of n should range from 1 to 16. The default is 4. FThe SMTP server may require larger process quotas/limits if more than four threads are allowed.[

5.3 DECNET_SMTP Network Object



@You must create a DECnet object called DECSMTP for establishing ASMTP-over-DECnet connections. To do this, either use your mailer Eaccount or create a dedicated server account for use with the DECnet Hobject (a dedicated server account is recommended). Using the AUTHORIZE Autility, set a password for the this account and set the account D/NOPWDLIFETIME. Also be sure the account has network access enabled.

 

"
UUAF> MODIFY account/PASSWORD=some-password/NOPWDLIFETIME/network




;A DECnet object needs to be created to handle the incoming ESMTP-over-DECnet connections and to map the DECSMTP object name to a DDECnet object number. Choose an unused DECnet object number. To see :what object numbers are currently in use, use the command:

 

"
$ MCR NCP SHOW KNOWN OBJECT




FAssign the object name DECSMTP to an unused object number; the number Fused must be identical on all nodes on your network that use ESMTP-over-DECnet (this example uses 254). In NCP, use these commands:

 

"
 NCP> PURGE OBJECT DECSMTP ALL:NCP> DEFINE OBJECT DECSMTP NUMBER 254 PROXY NONE FILE -^_NCP>    MX_EXE:DNSMTP_SERVER.EXE USER server-acct PASSWORD some-passwordNCP> SET OBJECT DECSMTP ALL




EYou do not need to specify the FILE, USER, or PASSWORD parameters if Fyou do not intend to accept incoming SMTP connections over DECnet. Be Fsure to use both the DEFINE and SET commands of NCP, and be sure that Ethe password in the DECnet database matches the password you set for the server account in AUTHORIZE.

Using Proxies


GInstead of storing the username and password for the server account in Bthe DECnet database, you could grant access using DECnet proxies. HProxies give you more control over who on the network has access to the Fobject, and eliminate the need for storing the password to the server &account in the DECnet object database.

@To enable proxy access to the DECSMTP object, use the following commands in NCP:

 

"
 NCP> PURGE OBJECT DECSMTP ALL>NCP> DEFINE OBJECT DECSMTP NUMBER 254 PROXY INCOMING FILE -$_NCP>    MX_EXE:DNSMTP_SERVER.EXENCP> SET OBJECT DECSMTP ALL




GThen in AUTHORIZE, create proxy entries for the mailer accounts on the ?other systems on the network that will be sending you mail via SMTP-over-DECnet:

 

"
FUAF> ADD/PROXY remote::mailer server-acct/DEFAULT




FFor remote::mailer substitute the DECnet node of the Eremote system and the username of the mailer account on that system. CFor server-acct substitute the name of the server 7account you set up for use with the DECnet-SMTP object.X

5.4 X25_SMTP Network Object



AYou must create a DECnet object called X25_SMTP for establishing 7SMTP-over-X.25 connections, both incoming and outgoing.

HIf you intend to accept incoming SMTP-over-X.25 connections, you should Gestablish an account (either your mailer account or a dedicated server daccount) for use with each DECnet object. See Message Exchange Installation Guide for more >information on the requirements for the DECnet object account.

;A DECnet object needs to be created to handle the incoming DSMTP-over-X.25 connections and to map the X25_SMTP object name to a DDECnet object number. Choose an unused DECnet object number. To see :what object numbers are currently in use, use the command:

 

"
$ MCR NCP SHOW KNOWN OBJECT




GAssign the object name X25_SMTP to an unused object number; the number Fused must be identical on all nodes on your network that use ESMTP-over-DECnet (this example uses 253). In NCP, use these commands:

 

"
!NCP> PURGE OBJECT X25_SMTP ALL;NCP> DEFINE OBJECT X25_SMTP NUMBER 253 PROXY NONE FILE -]_NCP>    MX_EXE:XSMTP_SERVER.EXE USER server-acct PASSWORD some-passwordNCP> SET OBJECT X25_SMTP ALL




EYou do not need to specify the FILE, USER, or PASSWORD parameters if Dyou do not intend to accept incoming SMTP connections over X.25. Be Gsure that the password in the DECnet database matches the password you (set for the server account in AUTHORIZE.

@You must also add an X.25 "destination" to the P.S.I. (database that maps to the DECnet object:

 

"
7NCP> DEFINE MODULE X25-SERVER DESTINATION X25_SMTP -'_NCP>   OBJECT X25_SMTP PRIORITY 0 -0_NCP>   CALL MASK  FFFFFFFFFFFFFFFFFFFFFFFF -._NCP>   CALL VALUE FF0000005832355F534D5450 6NCP> SET MODULE X25-SERVER DESTINATION X25_SMTP ALL 




Section 3.2, Defining Delivery Paths, contains information about defining X25_SMTP paths using MCP.^

5.5 Message Entry Agent Shutdowns



DThe two message entry mechanisms that do not get shut down with the Frest of MCP are the VMS Mail interface and the DECNET_SMTP server (if ?you are using SMTP-over-DECnet). The VMS Mail interface can be 2deactivated by de-installing the MX_MAILSHR image:

 

"
$ INSTALL REMOVE MX_MAILSHR




GThe SMTP-over-DECnet server gets shut down automatically when you shut Cdown DECnet, or can be manually removed by eliminating the DECSMTP object from the DECnet database:

 

"
"$ MCR NCP CLEAR OBJECT DECSMTP ALL




EThe SMTP-over-X.25 server gets shut down automatically when you shut Ddown P.S.I., or can be manually removed by eliminating the X25_SMTP object from the DECnet database:

 

"
#$ MCR NCP CLEAR OBJECT X25_SMTP ALL


 


H

Chapter 6
Managing the Message Queue




FThis chapter describes the various commands needed to control how the message queue operates.\

6.1 Establishing the Queue Size



BThe maximum number of queue entries that can be present in the MX Gmessage queue at any one time is determined by the size, in blocks, of Gthe MX message queue file. Each entry in the queue requires one block, Dwith 10 additional blocks used to store a bitmap of entries in use. FThis means, for example, that a queue file that is 510 blocks in size Hwill allow 500 entries to be present in the queue. The upper ceiling on the maximum entries is 131,072.

AMost sites that process several thousand mail messages a day can Gprobably work well with a queue file of about 5,000 blocks. If you are Fnot short on disk space, creating a 131,072-block file will eliminate ,the need to ever modify the queue file size.[

6.2 Running the MX FLQ Manager



HAs entries in the message queue are processed, they are marked as being =finished. By default, one of the MX Router processes will be -responsible for purging out finished entries.

HYou have the option of running a separate MX FLQ Manager process, whose Gsole job is to purge the queue of finished entries and cancel or ready Cany in-progress entries leftover from system crashes, disconnected Fprocesses, etc. Running a separate FLQ manager frees the MX Router to Broute messages, instead of splitting its time between routing and Gmaintaining the queue. This means that the MX Router has more time for Brouting messages and queue maintenance isn't delayed while the MX Router is routing.

DWhile the MX FLQ Manager can be run on multiple nodes in a cluster, Eonly one manager is ever actively maintaining the queue. Running the Hmanager on multiple nodes can provide failover backup in case of a node Hcrash, etc. If the MX FLQ Manager is shutdown and there are no managers =running on another node, one of the MX Router processes will *automatically start maintaining the queue.

BSites that do not process many messages per day will probably not 2benefit from running the MX FLQ Manager process. W

6.3 Queue Cleanup Logicals



AThe Router process (or the MX FLQ Manager process) automatically Fhandles cleanup of the message queue. The time between cleanup events hcan be controlled with logical names, as described in Table 6-1.

Y  " ( &                      
Table 6-1 FLQ Manager/Router queue-related logicals
Logical Default value Description
MX_FLQ_MGR_WAKEUP_INTERVAL 2 min. L Amount of time FLQ Manager sleeps before checking for entries to purge
 MX_ROUTER_WAKEUP_INTERVAL 10 min. J Amount of time MX Router sleeps before checking for entries to purge
 MX_FLQ_CHECK_WAIT 10 min. B Amount of time between checks for other queue-related events
 MX_FLQ_PURGE_WAIT 15 min. L Amount of time a queue entry should remain in queue after it has been  processed


HTo alter one of these values, use the DEFINE command to set the logical Gto a new time (using VMS delta-time format) and send a reset signal to (the Router and/or FLQ Manager processes:

 

"
.$ DEFINE/SYSTEM MX_FLQ_PURGE_WAIT "0 00:10:00"$ MCP RESET ROUTER,FLQ




G (If the Router runs on a different node in the cluster, you will have # to define the logical name there.)

EIf you want this change to be permanent and survive a system reboot, Cyou should add this logical name definition to your system startup procedure before MX is started.#l

6.4 Automatic Purging of Finished Queue Entries



@Finished queue entries are left in the queue for 15 minutes, by Bdefault, before they are purged. It is not necessary to leave the Fentries in the queue once they have been marked "FINished." AIf you prefer to not leave them around, you can enable automatic Epurging of FIN entries and their related files. Use the MXCONFIG.COM Dcommand procedure, option 1, to configure the message queue logical names.

GEven when autopurging is enabled, it is still necessary for the MX FLQ @Manager or MX Router process to occasionally scan the queue for HCANCELed entries. However, a dedicated MX FLQ Manager process is not as 6beneficial as it is when autopurging is not enabled. W

6.5 The MCP QUEUE Commands



DMCP includes a suite of commands for queue management to be used by Cprivileged users. These commands are documented in the MCP command dictionary.M

6.5.1 Interpreting MCP QUEUE SHOW Output



BWhen there are messages in the queue, MCP QUEUE SHOW displays the 'following information about each entry:

 

"
6Entry Status  Size  Source  Agent  Entry Status  Size 7----- ------ ------ ------ ------- ----- ------ ------ > 2980 INPROG    229 LOCAL  <usr01@myhost.mycompany.com> 7                           SMTP     2981 READY     229 K                                   (waiting until 15-NOV-1991 15:07:21.75) 9 9872 INPROG     34 JNET   <JUSER@SOMENODE.BITNET> 7                           LOCAL    9874 INPROG     34 E10859 READY   65120 LOCAL  <FileServ-Mgr@myhost.mycompany.com> .      (Waiting until 15-NOV-1991 18:00:00.00) 




<The fields of the display contain the following information:



FIf a message is being processed by one of the MX delivery agents, the Gbase queue entry will be immediately followed by indented entries that Hbegin with the Agent field. The Agent Bfield identifies the delivery agent that is working on the entry. HPossible values are LOCAL, LSV, SMTP, JNET, UUCP, SITE, HOLDn, "and DNSMTP (for SMTP-over-DECnet).

@The second Entry, Status, and GSize fields provide information about the queue entry Eused by the delivery agent. This agent-specific entry refers back to Hthe base entry for the message headers and text, and the base entry has >pointers to the agent-specific entries related to it. When an Hagent-specific entry is finished, the reference to it in the base entry Gis removed; when no agent-specific entries are left, the base entry is marked FINISHED.!S

6.5.2 Interpreting MCP QUEUE STATISTICS Output



>The MCP command QUEUE STATISTICS displays the following entry statistics:

 

"
MCP> QUEUE STATISTICS:Total entries: 16/502  (3%)   Highest entry used: 24  (4%)MCP> 




HThe first number after "Total entries:" is the current number Dof entries in the queue. The second number is the maximum number of Gentries allowed by the queue file size. The percentage of entries used is also shown.

EThe "Highest entry used:" is the largest entry number ever Gused during the life of the queue file. The percentage of the queue in Duse at that time is also shown. This value can be used to determine Gwhether or not the selected queue file size is sufficiently large. The GMCP command QUEUE EXTEND can be used to increase the size of the queue file. 


_

Chapter 7
Configuring MX for Part-Time Internet Connections




?This chapter describes how to configure MX to use holding Hqueues for messages that get delivered over a TCP/IP network path #that is not available all the time.f

7.1 Environment for Part-Time Connections



2MX supports a messaging environment consisting of:



HMX can act as either a client or server system; when configured as as a Bserver, MX can service up to eight clients with part-time network Alinks. The client systems must have static IP addresses >assigned to their domain names, or there must be an automatic Hassignment in the DNS between each client's domain name and its dynamic IP address.e

7.2 Configuring MX as a Part-Time Client



@To configure MX as a part-time client, use MCP to configure the delivery path to the server:

 

"
7MCP> DEFINE PATH * HOLDING_QUEUE=1/ROUTE=server-name


FIf you have already used MXCONFIG.COM to create your MX configuration Hdatabase, you may need to use the MODIFY PATH command to configure this path change.

DThis path configuration causes MX to hold all messages that are not .delivered through other, more specific, paths.

BIf your client system creates the network path to the server, you Fshould execute the following command to start the holding queue agent when the path is established:

 

"
$ @SYS$STARTUP:MX_STARTUP HOLD1


CThe agent will then attempt to deliver all messages in the holding Hqueue to the server. You may also use this command if the server system Ecreates the dial-up connection, but this may not be necessary if the Gserver system supports the SMTP ETRN extension (documented in Internet HRFC 1985). The MX SMTP server supports ETRN and can automatically start >the holding queue agent when requested to do so by the server.q

7.3 Configuring MX as a Server for Part-Time Clients



CThe configuration for MX as a server also uses holding queues, but Gdefines paths for the specific host(s) or domain(s) at the client site:

 

"
KMCP> DEFINE PATH client.host.name HOLDING_QUEUE=n/ROUTE=client.host.nameHMCP> DEFINE PATH client.domain HOLDING_QUEUE=n/ROUTE=client.host.name


DThe value of n can be 1 through 8, representing one of the Geight available holding queues. If the name defined in the DEFINE PATH Ccommand does not match the client's actual Internet host name, you Cmust specify the /ROUTE qualifier to set the host name to Gwhich messages will be delivered. In addition, all /ROUTE values for a 0single holding queue must be identical.

CTo start the delivery agent for one of the holding queues, use the command:

 

"
($ @SYS$STARTUP:MX_STARTUP HOLDn


Gwhere n is the number 1 through 8, representing the number of Hthe holding queue for a particular client system. If a client system is Dalso running MX, and is configured to start its holding queue agent Fwhen the network path is established, the ETRN support in the MX SMTP Gserver will be used to automatically start the holding queue agent for their system.M

7.4 ETRN Support



EWhen both the client and the server systems run MX or another mailer Gthat supports the RFC 1985 ETRN extension to SMTP, only one of the two Fsystems has to be set up to start its delivery agent when the dial-up Hconnection is active; the SMTP ETRN command will cause the other system 7to start delivering messages in the opposite direction.

EA parameter is sent on the ETRN command; this parameter can identify Hthe host or domain for which messages should be delivered, or it can be Ca special "queue name," a private identifier used by the Cclient and server systems to identify the holding queue agent that Eshould be started. By default, MX holding queue agents will send the following ETRN commands:

 

"
ETRN mx-host-nameETRN #ip-host-name




=Where mx-host-name is the value of the logical name EMX_NODE_NAME, and ip-host-name is the local system's TCP/IP Chost name (either from the logical name MX_INET_HOST, or from your FTCP/IP package's configured host name). In the second case, the pound Esign ("#") indicates that ip-host-name is a queue identifier.

HIf the system at the other end of the connection is running MX, and has HPATH definitions with /ROUTE qualifiers that specify the same host name Eas the ip-host-name appearing in the ETRN command, then the Eremote system will automatically start the appropriate holding queue Gagent for that system. The holding queue agent will also be started if Fthe mx-host-name appearing in the first ETRN command matches one of PATH definitions.

DYou can override the default ETRN behavior for a particular holding -queue agent with the following logical names:

 

"
=$ DEFINE/SYSTEM/EXEC MX_HOLDn_REQUEST_DELIVERY FALSE


DThis logical name prevents the holding queue agent from sending any GETRN commands at all; use this when the remote system does not support DETRN or if you need to control the holding queue agents manually at both ends of the connection.

 

"
=$ DEFINE/SYSTEM/EXEC MX_HOLDn_HOST_NAME "name"[,...]


FThis logical names overrides the parameters sent on the ETRN command. DMultiple names may be specified; enclose each in quotation Fmarks, and separate them with commas. The value of each name Cis passed to the remote system exactly as entered; you may use the D"@" or "#" prefix character to specify a domain Dname or a queue identifier (see RFC 1985 for more information). Use >this logical name when the remote system supports ETRN but is Bnot running MX, or if the IP host name used on the local ;system does not match the /ROUTE host names used in the MX #configuration on the remote system.V

7.5 Example Configuration



EThis example shows the commands used to configure a client servicing 4the domain "mxclient.com", with host name A"mailer.mxclient.com", and a server with the host name !"mailhub.mxserver.com".

Client configuration:

 

"
2MCP> DEFINE PATH "mxclient.com" LOCAL9MCP> DEFINE PATH "mailer.mxclient.com" LOCALLMCP> DEFINE PATH * HOLDING_QUEUE=1/ROUTE="mailhub.mxserver.com"




Server configuration:

 

"
2MCP> DEFINE PATH "mxserver.com" LOCAL:MCP> DEFINE PATH "mailhub.mxserver.com" LOCALbMCP> DEFINE PATH "mxclient.com" HOLDING_QUEUE=1/ROUTE="mailer.mxclient.com"iMCP> DEFINE PATH "mailer.mxclient.com" HOLDING_QUEUE=1/ROUTE="mailer.mxclient.com"MCP> DEFINE PATH * SMTP


 


]

Chapter 8
Reducing or Eliminating "Junk" E-Mail




DThis chapter describes the facilities in MX for preventing unwanted E"junk" e-mail messages (also called "spam") from being processed.a

8.1 What is "junk" E-Mail?



DThe Internet has grown explosively since its humble beginnings as a Gtool for researchers wishing to exchange information. The designers of Cthe early Internet electronic mail systems and standards kept SMTP ?simple (in fact, the S in SMTP stands for "Simple"), Foperating under the assumption that Internet users were, for the most part, well-behaved.

FDue to the explosive growth, there are now many more people using the HInternet that are not well-behaved, exploiting the openness of SMTP and Gthe low cost of generating immense e-mail distribution lists either to Bannoy or to send unsolicited advertisements to the huge number of )people who currently use Internet e-mail.

DThis use of e-mail, while costing almost nothing to the sender, can Eplace a heavy burden---in terms of network and system resources---on Cthe sites that receive these unsolicited messages. System managers Gwishing to reduce the number of unwanted "junk" messages can Bconfigure MX to block them from being received locally as well as Dprevent their systems from being used as a "relay" point, Fsometimes employed by unscrupulous "spammers" that have had >their own systems blocked from direct delivery by other sites.

EYou can get more information about junk e-mail on the World Wide Web )from http://spam.abuse.net/spam.V

8.2 MX Filtering Features



6MX contains several features to help curb junk e-mail:

R

8.3 Sender Validation



FSpammers often hide their identity by using a false return address on Dtheir messages. In many cases, the return address contains a domain Gname that does not actually exist in the Domain Name System (DNS). You Dcan have the SMTP server validate the domain name appearing in SMTP HMAIL FROM commands (which specify the return address for SMTP messages) Cto ensure that it exists in the DNS with the following MCP command:

 

"
'MCP> SET SMTP/VALIDATE_SENDER_DOMAIN




DThis feature should only be enabled if you use the Internet and the GDomain Name System. You should also ensure that all of your legitimate Eusers that might send mail via SMTP to your system (such as PC users Fwith POP mail clients) have their systems properly configured to send 5valid domain names as part of their return addresses.

HReliable DNS service is also helpful when enabling this feature; if the GSMTP server cannot resolve a domain name due to communication problems Bwith the DNS server, the validity check is not performed.b

8.4 Disabling the SMTP Relay Function



CIn some cases, junk e-mail senders who are unsuccessful in getting Cmessages delivered directly from their own systems, or who wish to ?obscure the source of the junk messages, take advantage of the G"relay" function available in most SMTP servers. By default, Bmost SMTP servers accept messages coming from any source and will Gattempt to deliver those messages to any destination, even if both the Fsource of the message and its intended recipients are remote. This is @called relaying. The MX SMTP server allows relaying by Hdefault; you can disable the relay function if you wish to prevent your 8system from being used as a relay point for junk e-mail:

 

"
 MCP> SET SMTP/NORELAY_ALLOWED




DOnce relaying is disabled, the SMTP server checks the envelope FROM Faddress (also called the Return-Path) of each incoming message to see Hif it is local or remote. It also checks each recipient address. If the Cenvelope FROM address is remote and a recipient address is remote, :delivery to the remote recipient is refused by the server.

HThe SMTP server uses the following tests to determine whether or not an ?envelope address (either FROM or recipient) is local or remote:

    G
  1. The address is passed through the message routing rules (rewrite I rules and path checks). If the resulting path is LOCAL, the address is  considered local.H
  2. If the address does not resolve to a LOCAL path, the host name in J the address is compared against the MX host name. If both names are the C same, or both hosts share the same parent domain, the address is  considered local.I
  3. If the previous check did not classify the address as local, it is & repeated using the TCP/IP host name.G
  4. If none of the above checks classified the address as local, the G host name is compared against the local domains list, which 5 you configure with the DEFINE LOCAL_DOMAIN command.


FYou may need to use the DEFINE LOCAL_DOMAIN command if your host acts Cas a mail gateway for other systems that are not part of your home :domain. For example, if your system is part of the domain Amycompany.com but also acts as a gateway for the domain Htheircompany.com, you would define the following local domains:

 

"
,MCP> DEFINE LOCAL_DOMAIN theircompany.com.MCP> DEFINE LOCAL_DOMAIN *.theircompany.com




FThese commands will cause the SMTP server to treat any address of the 8form user@theircompany.com or Buser@somehost.theircompany.com as being >"local" for the purposes of relay-rejection testing.P

8.4.1 Identifying Inside Networks and Hosts



EYou can further strengthen the anti-relay checks by using the DEFINE EINSIDE_NETWORK_ADDRESS command to create a list of IP network and/or Ghost addresses that are considered to be "inside" your local Gnetwork. Creating this list prevents an outside system from using your Fsystem as a junk mail relay by masquerading as a local user (by using >one of your local domain names in the SMTP MAIL FROM address).

@If your system is acting as a relay between other hosts on your Gnetwork(s) and the Internet, or you have POP or IMAP mail clients that Hsend their messages through your system, you should add your network(s) Fto the list. For example, if your local network is 10.10.10.0, set up 0with a 24-bit subnetwork mask, you would specify

 

"
FMCP> DEFINE INSIDE_NETWORK_ADDRESS 10.10.10.0/NETMASK=255.255.255.0


CAny SMTP connection coming from a system on the 10.10.10.0 network Awould be allowed to specify a local domain in the SMTP MAIL FROM Gcommand in combination with a list of recipients that are outside your Ddomain; all other systems would be considered outside, and would be Funable to specify a list of outside recipients even when sepcifying a #local domain in the SMTP MAIL FROM.

FIf there were another mailer for your network (such as another system Gin the Domain Name System list of mail exchanger [MX] records for your :domain) at the address 10.10.20.37, you would also specify

 

"
1MCP> DEFINE INSIDE_NETWORK_ADDRESS 10.10.20.37


HBy omitting the /NETMASK qualifier, the address is assumed to be a host rather than a network.

GIf your system is the only mailer for your domain, and you do not have 0any POP or IMAP mail clients, you should specify

 

"
/MCP> DEFINE INSIDE_NETWORK_ADDRESS 127.0.0.1


Fto enable the inside-address checks and prevent any other system from Husing a local e-mail address in the SMTP MAIL FROM in order to relay to outside hosts.

GThe DEFINE INSIDE_NETWORK_ADDRESS command has a /REJECT qualifier that Dallows you to set up specific exceptions to the list for individual Hhosts or subnetworks. For example, if on your local 10.10.10.0 network, ?there is one host (10.10.10.100) that should not be considered %"inside", you could specify

 

"
:MCP> DEFINE INSIDE_NETWORK_ADDRESS 10.10.10.100 /REJECT


,to eliminate that host from the inside list.

HNote that the list of addresses is kept in order based on the length of Fthe network mask, from longest (host addresses) to shortest. The list Bis search sequentially from the beginning for a match against the sending host's IP address.X

8.5 Realtime Blackhole List



GThe Mail Abuse Protection System (MAPS) project maintains the Realtime DBlackhole List (RBL), a list of network and host addresses of known Fjunk e-mail abusers. Information on RBL and other MAPS efforts can be &found at http://maps.vix.com.

CMAPS makes the RBL available in two forms: a routing protocol (for 0routers) and the domain name system (for hosts).

GSeveral Internet Service Providers (ISPs) subscribe to the RBL routing Finformation, and will automatically "black-hole" any TCP/IP Epackets that come from the offending hosts and networks. If your ISP Fdoes not subscribe to the RBL, you can configure MX to perform an RBL Gdomain name system check for every host connecting to the SMTP server. HIf the connecting host is found in the RBL, the SMTP server will refuse any message it tries to send.

5Use the following MCP command to enable RBL checking:

 

"
MCP> SET SMTP/RBL_CHECK




FRBL checking is disabled by default. Consult the MAPS web site to get Cfull information on how the RBL is maintained before enabling this feature.>

8.5.1 Other RBL Providers



EIf you would prefer to use the services of another RBL provider (for Dexample, see http://www.dorkslayers.com), you may specfy a Fdomain name on the /RBL_CHECK qualifier to have the SMTP server check 1in that domain for a blocked system. For example:

 

"
0MCP> SET SMTP/RBL_CHECK="rbl.dorkslayers.com"


<If you specify /RBL_CHECK with no domain name, the MAPS RBL /(rbl.maps.vix.com) is used by default.l

8.6 Establishing Rejection Criteria with REJMAN



DThe REJMAN utility lets you create and manage a database containing Dcriteria by which MX's SMTP server will reject incoming messages as mjunk e-mail that you do not want to be processed. See REJMAN for *information on how to invoke this utility.

BREJMAN provides commands for rejecting messages based on envelope Econtents (combinations of return address, recipient address, and the GTCP/IP address of the sending host) as well as on headers contained in the message.C

8.6.1 Address-Based Rejections



CThe REJMAN ADD REJECTION command can be used to configure the SMTP Eserver to reject incoming messages with specific return addresses or Bmatching specified patterns, or being sent from particular hosts. HMessages matching the rejection criteria are refused by the SMTP server Hbefore the message contents are sent---reducing network load as well as #the processing load on your system.

CIf your users are being bombarded with unwanted e-mail, review the Hunwanted messages for the Return-Path: header and the Received: headers E(you should ensure that your SET LOCAL settings do not prevent those Fheaders from being included in delivered messages). You can program a Brejection rule into the SMTP server based on the Return-Path with:

 

"
'REJMAN> ADD REJECTION sender-address




>For example, if some junk e-mail had a Return-Path address of A<spammer@spamhost.com>, you would use the command:

 

"
/REJMAN> ADD REJECTION "spammer@spamhost.com"




HIf the Return-Path has different usernames, but the same host name, you could use a wildcard pattern:

 

"
)REJMAN> ADD REJECTION "*@spamhost.com"




9to reject all messages coming from spamhost.com.

CIf a large number of junk messages were all sent to your host from Fanother single host or network, they would all have Received: headers that follow this pattern:

 

"
NReceived: from spam-source.com by yourhost.com with SMTP... 




FYou can block incoming messages sent by a particular host or on hosts Efrom a particular network using the /ADDRESS qualifier on the DEFINE FREJECTION command. For example, if spam-source.com has an IP .address of 10.0.0.1, you could use the command

 

"
/REJMAN> ADD REJECTION "*@*"/ADDRESS=10.0.0.1




Fto have the SMTP server refuse all messages that were sent or relayed Gthrough that particular host. You must know the IP address of the host Hin order to use the /ADDRESS qualifier. Address specifications may also 3contain wildcards so you can block entire networks.

EOnce you have added one or more rejection rules to the database, you Hmust use MCP to reset the SMTP server to have the new rules take effect:

 

"
MCP> RESET SMTP_SERVER






/  
Note

FExercise caution when establishing rejection rules. An incorrect rule =could block legitimate messages from reaching their intended destinations.


HThe ADD REJECTION command has more options for narrowing the scope of a Drejection based on recipient addresses, for setting the text of the Fmessage returned when a rejection occurs, and for forwarding messages @that would have been rejected to a different address to collect tevidence of junk e-mail. See ADD REJECTION for more information.B

8.6.2 Header-based Rejections



FAs spammers have become more sophisticated, junk e-mail messages have Gstarted looking more and more like legitimate messages, with perfectly Bvalid envelope information. Such messages, however, often contain ERFC822 message headers that can be used to identify them as junk. To Fblock such messages, REJMAN provides for the addition of header-based +rejection rules, with ADD REJECTION/HEADER:

 

"
3REJMAN> ADD REJECTION/HEADER header-text-pattern




GFor example, some types of junk e-mail messages, advertising "get Erich quick" schemes contain Subject: headers that begin and end %with a string of dollar signs, as in:

 

"
 Subject:  $$ MAKE MONEY FAST $$ 




GSince it is unlikely that a legitimate message will contain a Subject: Eheader that begins and ends with dollar signs, you might want to add <the following header-based rejection to the REJMAN database:

 

"
0REJMAN> ADD REJECTION/HEADER "Subject: $$*$$"




CThis will cause the SMTP server to reject any message containing a !header that matches this pattern.



/  
Note

FAs with address-based rejections, you should be careful when creating Cheader-based rejection rules, to prevent the unwanted rejection of #legitimate e-mail messages.


FFor header-based rejections, the SMTP server receives the entire text Fof an incoming message before it can identify an unwanted message and Greturn a status code to the sending system indicating that the message >was not accepted (due to the way the SMTP protocol operates). ?Address-based rejections occur before any message data is sent.

ERejections based on header information cannot be redirected to other Baddresses, nor can you modify the message returned to the sending ,system when a header-based rejection occurs.>

8.6.3 Tracking Rejections



?Tracking information is stored in the REJMAN database for each *rejection rule. This information includes:



>This information is mainly for your use, so you can gauge the Geffectiveness of the rejection rules you have entered. The SMTP server Eperiodically updates the statistics in the database, and updates the 'database when it is reset or shut down.<

8.6.4 Purging Old Rules



=Since particular patterns of junk e-mail envelope and header Fcharacteristics tend to last only for a short time, REJMAN includes a GPURGE command to allow you to delete rules from the database that have not been used recently:

 

"
$REJMAN> PURGE [/BEFORE=date-time]




HUnless you specify the /BEFORE qualifier, the PURGE command will remove Grules from the database that have not been used to reject messages for 30 days or more.

BPeriodically using the PURGE command helps keep the database from Egrowing too large, reducing the overhead involved in performing junk e-mail checks.R

8.7 Heuristic Filters



HSenders of junk e-mail use various techniques to disguise the source of Ctheir messages, and change their source addresses frequently. This Cmakes it difficult to keep rejection rules up-to-date. In spite of Fthese changes in addresses, most junk e-mail messages exhibit certain Bcharacteristics in the contents of their headers. The SMTP server ;contains a number of heuristic filters that look for these <characteristics and classify matching messages as junk mail.

DThe filters are called "heuristic" because they determine Gonly the probability that a message may be junk e-mail, based Hon rules created from empirical observation of thousands of junk e-mail Fmessages. It is possible for legitimate, non-junk e-mail to match one For more of these filters, too. Because of this, the heuristic filters Fcome with configuration options for forwarding matching messages to a Gmailbox (typically the local Postmaster or system manager) for further @review, and for creating exceptions to the filters based on the sender's address.

EThe REJMAN utility is used to configure the heuristic filters, using .the commands described on the following pages:

EThe REJMAN SHOW HEURISTICS command displays the current settings for the heuristic filters.<

8.7.1 Confidence Levels



oThe heuristic filters provided by MX are listed in Table 8-1. Each Gfilter is assigned a confidence level (CL) that represents, Eon a scale from zero to ten, the probability that a message matching Hthe filter is junk mail. The default CL for each filter is shown in the Btable; you can change these values when configuring the heuristic filters.

GWhen a message is received by the SMTP server, its headers are checked Gagainst each heuristic filter, and the message is assigned the highest GCL found for all matching filters. When no filters match, the assigned CL is zero.

BThe message's assigned CL is the checked against two configurable :threshold values, the accept threshold and the reject threshold.



A  & % &                                                                        
Table 8-1 Heuristic Filters
Filter name Default CL Description
 FROM_TO_SENDER_SAME  10 N Matches when the SMTP MAIL FROM: address matches both the From: and To: & addresses in the RFC822 headers.
 INVALID_AOL_ADDRESS  10 N Matches when the RFC822 From: or To: headers contain an invalid address F for AOL.COM (username too long or containing invalid characers).
 INVALID_HOTMAIL_ADDRESS  10 N Matches when the RFC822 From: or To: headers contain an invalid address N for HOTMAIL.COM, or when the SMTP MAIL FROM: and RFC822 From: addresses ? are HOTMAIL.COM addresses and the message is missing the L X-Originating-IP: header that HOTMAIL.COM mailers add to all outgoing  messages.
 MSGID_HAS_FROM  10 L Matches when the Message-ID: header contains the RFC822 From: address.
 MSGID_HAS_TO  10 J Matches when the Message-ID: header contains the RFC822 To: address.
 NULL_FROM  8 J Matches when there is no RFC822 From: header in the message, or the " header is present but empty.
 NULL_MSGID  10 L Matches when the RFC822 Message-ID: header contains a null message ID.
NULL_TO  6 H Matches when there is no RFC822 To: header in the message, or the " header is present but empty.
 NUMERIC_ADDRESS  7 J Matches when the username part of the From: or To: address contains D only digits. Exceptions are provided for domains known to use 1 all-numeric usernames, such as MCIMAIL.COM.
 PRECEDENCE_BULK  4 L Matches when the message contains a Precedence: header containing the  word "bulk".
 RECEIVED_AFTER_FROM  4 L Matches when a Received: header is found after the From: header. This N is usually an indication that the sender did not include a From: header N in the original message, or that the sender forged the misplaced header.
 RECEIVED_ALL_ZEROS  10 F Matches when a Received: header is found after the From: header,= and that Received: header contains the string " "000.000.000.000".
 UIDL_AUTH_SENDER  10 9 Matches when the message contains an X-UIDL: header? and a Comments: header that contains the string * "authenticated sender is".
X_UIDL  8 J Matches when the message contains an X-UIDL: header. This header is K normally used internally by some POP servers and clients to uniquely K identify messages in mailboxes, and should not generally be found in  outbound messages.
<

8.7.2 Rejection Actions



GWhen a message's confidence level exceeds the rejection threshold, the HSMTP server applies the rejection action that you configure. BThis action can either be REJECT, which causes the SMTP server to Grefuse the message, or FORWARD, which causes the SMTP server to accept Dthe message, but forward it either to the local Postmaster or to an address you specify.

DBy setting the rejection action to FORWARD, you can review messages Gthat have been rejected by the filters and recover those messages that Amay have been misclassified. Each forwarded message will contain Fadditional headers listing the original sender and recipients, plus a ?header that indicates the filter that caused the message to be Erejected. If a legitimate message was misclassified, you can use the FREJMAN ADD EXCLUSION command to prevent future messages from the same (originating address from being rejected.=

8.7.3 Junk Mail Warnings



BFor a message that is identified as possible junk mail but is not Arejected, the SMTP server inserts one or two headers to warn the Erecipient(s) that the message was identified as junk mail. The first header is:

 

"
0     X-Junk-Mail-Rating: {LOW, MEDIUM, or HIGH} 


HLOW indicates a CL less than 4; MEDIUM, 4 through 7; HIGH, 8 or higher. @If your users have e-mail client programs that can also perform Ffiltering, the addition of this header should make it simple for them Ato set their own policy regarding junk mail that is sent to them.

GYou may configure the SMTP server to include an additional header that Gidentifies the filter that caused the message to be classified as junk Email. The REJMAN command that turns on this additional header is SET HEURISTICS/INCLUDE_REASON._

8.8 Logging SMTP Server Rejections



FYou can have the SMTP server notify you when it rejects a message due Hto sender validation, REJMAN rules, or heuristic checks by defining the +logical name MX_SMTP_REJECTION_EVENT_CLASS:

 

"
C$ DEFINE/SYSTEM/EXEC MX_SMTP_REJECTION_EVENT_CLASS opcom-class-name




GIf that logical name is defined as one of the OPCOM event class names, @the SMTP server will log a notification each time it rejects an Cincoming message based on DNS validation of the sender address, or Cbased on the rejection rules you have added to the REJMAN database.p

8.9 Debugging Rejection Rules and Heuristic Filters



DThe SMTP server contains some additional logging code for debugging HREJMAN rejection rules and heuristic filters. You can enable this debug 3logging with the following logical name definition:

 

"
-$ DEFINE/SYSTEM/EXEC MX_ANTI_SPAM_DEBUG level


@where level is an integer value greater than zero that Dspecifies how much information should be included in the debug log. HBasic information is included when the debug level is 1; more detail is -included when the debug level is 2 or higher.

EAfter defining this logical name, you must use MCP to RESET the SMTP Hserver. To turn off debug logging, you should DEASSIGN the logical name Cand RESET the SMTP server. That will close the log file so you can examine the debug output. 


K

Chapter 9
Other Miscellaneous Utilities




9This chapter describes other utilities available with MX.S

9.1 The MLFAKE Utility



GFor those times when you need to act on behalf of one of your users to Hsign off or subscribe to a mailing list, the MLFAKE utility may come in handy:

   

"
$ MLFAKE  :== $MX_EXE:MLFAKE 4$ MLFAKE  listname  hostname  [command] [arguments]      /LISTSERV[=lsvname]      /REQUEST=reqaddress      /FROM=fromuser 



@Specify the name of the mailing list and its host (with no @ in Hbetween). If you omit command, it defaults to SIGNOFF. FIf the command requires additional arguments, you should specify them Cafter command (in which case you must specify the Gcommand). If the mailing list is managed by a BITNET LISTSERV, use the C/LISTSERV qualifier; otherwise the request will go to the -Request Faddress for the list (the Internet convention). You can override this ?altogether by specifying the request address with the /REQUEST Gqualifier. Finally, you must specify who the request is supposed to be from with the /FROM qualifier.

For example:

 

"
,$ MLFAKE/FROM=someuser MX-List LISTS.WKU.EDU1$ MLFAKE/FROM=someuser ESL-L UBVM.BITNET/LISTSERV+$ MLFAKE/FROM=someuser/REQUEST="FileServ" -&_$         "" WKU.EDU SEND MX040.BLURB




DThe first example is for an Internet-type mailing list. The message Dwill be constructed with "someuser" as the originator and EMX-List-Request@vms.ecs.rpi.edu as the destination, with the message Greading SIGNOFF. In the second example, for a BITNET mailing list, the Cdestination will be LISTSERV@UBVM.BITNET, with the message reading HSIGNOFF ESL-L. The third example shows how MLFAKE can be used with file Gservers by specifying the destination user with the /REQUEST qualifier Fand omitting the listname argument (which is ignored when /REQUEST is specified).

HMLFAKE requires SYSPRV privilege. SYSLCK privilege is not required, but Hwill speed processing of the message. DO NOT install the MLFAKE Bimage with these privileges! Only trusted users Hshould have access to this utility, since it can be used to fake a mail message from any other user.V

9.2 The MAILQUEUE Utility



FMAILQUEUE is a program that scans the message queue for entries still Gin progress. It can be used by non-privileged users to view only those Gentries which were sent by them. When used from an account with SYSPRV 8privilege turned on, it lists all pending queue entries.

AMAILQUEUE resides in the MX_EXE: directory and is designed to be "executed as a DCL foreign command:

 

"
"$ MAILQ*UEUE :== $MX_EXE:MAILQUEUE$ MAILQ




?If there are no delayed messages, MAILQUEUE returns the message

 

"
<%MAILQ-I-MQNONE, no MX mail messages queued on local system 




=Otherwise, the MAILQUEUE display will resemble the following:

 

"
 =Entry: 9872, Origin: [Jnet] <SOMEUSER@YOYODYNE.BITNET>   Status: IN-PROGRESS #  Local entry #9874, status: READY 7      Waiting for retry until: 15-NOV-1991 16:46:44.12 9      Recipient #1: SOMEUSER, Route=myhost.mycompany.com       Error count=93 ?      Last error: %MAIL-E-OPENOUT, error opening !AS as output  DEntry: 10859, Origin: [Local] <FileServ@myhost.mycompany.com> 7  Status: READY, waiting until 15-NOV-1991 18:00:00.00 H    Recipient #1: <SOMEUSER%SOMEHOST.BITNET@myhost.mycompany.com> 


#V

9.3 The MX_DECODE Utility



DThe MX_DECODE utility will decode MIME-compliant mail messages with Gcontents encoded as BASE64 or QUOTED-PRINTABLE. If the content type of Gthe message is APPLICATION/VMS-RMS, it will also automatically restore Ethe file's original RMS attributes. The MX Local agent automatically Gdecodes VMS-RMS and QUOTED-PRINTABLE when they are received. MX_DECODE His provided for use in decoding messages delivered by other mailers, as Fwell as for use with the MX Site agent, so that messages destined for $MX Site may sent using SEND/FOREIGN.

5MX_DECODE should be executed using a foreign command:

 

"
%$ MX_DECODE :== $MX_EXE:MX_DECODE.EXE'$ MX_DECODE MAIL_MESSAGE.BASE64 XYZ.xxx




HIt accepts two required parameters: the input file and the output file. FBy default, in order to decode the file properly, the input file must Einclude the MIME RFC822 headers before the encoded body. The headers Hare used only to find the stored VMS file attributes. If the file has a Gcontent type of APPLICATION/VMS-RMS, the resulting decoded output file Awill retain all of the VMS file attributes of the original file. ;Otherwise, the format of the resulting file will either be Gfixed-length, 512-byte records (for binary BASE64-encoded messages) or Da text file (for QUOTED-PRINTABLE and BASE64-encoded text messages).

EYou can also decode base64-encoded files without the mail headers by Gusing the qualifier /NOHEADER to tell MX_DECODE that there are no mail Cheaders in the file, only encoded text. By default, MX_DECODE will Gproduce a standard VMS binary file (fixed-length 512-byte records). If Bthe text you're decoding is a text file, you can specify /TEXT to Bcreate a normal VMS text file. If it is a text file encoded using 8QUOTED-PRINTABLE, use the /QUOTED_PRINTABLE qualifier. 


B

Chapter 10
Troubleshooting MX




@This chapter contains information on MX useful for debugging MX components.d

10.1 Queue Files Used by MX Components



CAs has already been discussed, each MX component uses files in the Fmessage queue when processing messages. Each queue entry has at least Fone file associated with it, usually containing envelope information. AThe files created by MX are stored in a directory tree under the EMX_FLQ_DIR: directory. The files are named n.type, Gwhere n is the queue entry number and type is a file 7type indicating the type of information is in the file.

?There are ten subdirectories under the MX queue directory. The Dsubdirectories are used to keep the size of the MX queue .DIR files Hbelow 128 blocks so that they can be cached by RMS. The subdirectory in Ewhich a file is located is determined by using the last digit in the ;file name as the subdirectory name ([.0], [.1], ..., [.9]).

?Most of the queued files used by MX contain records written in Htag-length-value (TLV) format. The tag and length fields are written in Fbinary format, although the value may contain plain ASCII. While more Aefficient for MX, this storage format makes it more difficult to Fdisplay the contents of these files, since the binary headers tend to Econfuse terminals. When examining these files, it is usually best to 2use DUMP or a text editor, rather than using TYPE.7

10.1.1 File Types



FThe following list describes the file types used for queue files, the 6agents that write them, and the agents that read them.

CSRC_INFO. This is the envelope information writtenGon message entry. This file contains TLV records indicating the source Fof the message, the originating address, and the recipient addresses. BWritten by: MX_MAILSHR, DNSMTP_SERVER, XSMTP_SERVER, SMTP_SERVER, =MX_JNET (incoming), MX_RMAIL, MX_SITE_IN. Read by: MX_ROUTER.

BHDR_INFO. This file contains the message headers,Hin TLV format. The headers are only used during address conversion when @gatewaying mail into UUCP or Jnet, or for making return-address Gdeterminations on local delivery of mail. Written on message entry by: >MX_MAILSHR, DNSMTP_SERVER, XSMTP_SERVER, SMTP_SERVER, MX_JNET =(incoming), MX_RMAIL, MX_SITE_IN. Read by: MX_LOCAL, MX_JNET B(outgoing), MX_SMTP, MX_UUCP, MX_SITE, MX_MLF, MX_LSV, MX_DNSMTP, MX_XSMTP.

=MSG_TEXT. This file contains the text of theBbody of the message, in plain ASCII. Written on message entry by: >MX_MAILSHR, DNSMTP_SERVER, XSMTP_SERVER, SMTP_SERVER, MX_JNET ?(incoming), MX_RMAIL, MX_SITE_IN. Read on message delivery by: AMX_LOCAL, MX_JNET (outgoing), MX_SMTP, MX_UUCP, MX_SITE, MX_MLF, MX_LSV, MX_DNSMTP, MX_XSMTP.

BDNSMTP_INFO, JNET_INFO, LOCAL_INFO, SMTP_INFO, UUCP_INFO, 0SITE_INFO, MLF_INFO, XSMTP_INFO . TheseHfiles contain envelope information used by the delivery agents. Written Hby: MX_ROUTER. Read by: MX_DNSMTP, MX_JNET, MX_LOCAL, MX_SMTP, MX_UUCP, )MX_SITE, MX_MLF, MX_XSMTP (respectively).

DJNET_INPUT. This file is used by the Jnet interfaceGfor holding the original message as it comes in from Jnet until it can Bbe processed by MX_JNET. Written by: MX_MFSDISP. Read by: MX_JNET (incoming).

HNote that the SRC_INFO, HDR_INFO, and MSG_TEXT files remain attached to @the original (base) queue entry. When the queue entries for the Hdelivery agents are created, a back link to the original queue entry is Bentered so the delivery agents can gain access to the headers and Gmessage text. In addition, forward links to the delivery agent entries Care kept in the original queue entry, which are zeroed out as each Cdelivery agent finishes its processing. When all forward links are =zeroed, the original queue entry is changed to FINISH status.P

10.2 Process Names



FThe MX_START.COM command procedure assigns a specific process name to Deach of the MX detached processes. To determine whether an agent is Frunning or not, use the MCP command STATUS or examine the SHOW SYSTEM output for the followingprocess names:                                                        
 MX Router  The Router
 MX FLQ Manager  The MX queue manager
MX SMTP  SMTP delivery agent
 MX DNSMTP % SMTP-over-DECnet delivery agent
 MX XSMTP # SMTP-over-X.25 delivery agent
 SMTP Server  SMTP server
 MX Local  Local delivery agent
 MX Jnet Intfc D Jnet interface (delivery agent and incoming message processor)
MX LSV , Gateway to L-Soft's LISTSERV processor
MX MLF  Mailing list/file server
 MX Site Agent # Site-specific interface agent
 MX->SITE * Subprocess created by site interface
 MX uucp Intfc  UUCP interface
 MX->uucp * Subprocess created by UUCP interface


FNote that the subprocesses are not created until at least one message 1is processed by the corresponding delivery agent.U

10.3 Debug/Trace Output



HEach of the delivery agents has debug/trace code that can be enabled to Aprovide information on message processing. Tracing is enabled by Fdefining a system-wide logical name, and disabled by deassigning that Flogical. Debugging can be enabled or disabled "on the fly": Bthe process being debugged will automatically start logging trace Ginformation for each entry processed after the logical name is defined.

FThe trace log file, by default, is created in the same directory used 3for the agent's main log file, with a file type of H.LOG_process-id (for the SMTP server, the default file type is B.LOG_process-id_thread-id). Trace output can be Eredirected by defining a system-wide logical name. The logical names Xused for debugging are outlined in Table 10-1.

HThere is no debugging code available in the MX_MAILSHR/MX_MAILSHRP (the GVMS MAIL interface), MX_MFSDISP (the Jnet mail/file dispatcher), or in MX_SITE_IN.

J  + % ,                                                                                            
Table 10-1 Debug/Trace logical names
Agent Enabling logical Trace file Default directory
 Jnet intfc  MX_JNET_DEBUG  MX_JNET_LOG  MX_JNET_DIR:
Local  MX_LOCAL_DEBUG  MX_LOCAL_LOG  MX_LOCAL_DIR:
Local  MX_LSV_DEBUG  MX_LSV_LOG  MX_LSV_DIR:
ML/FS  MX_MLF_DEBUG  MX_MLF_LOG  MX_MLF_DIR:
 RMAIL (UUCP in)  MX_UUCP_RMAIL_DEBUG  MX_RMAIL_LOG  MX_UUCP_DIR:
Router  MX_ROUTER_DEBUG  MX_ROUTER_LOG  MX_ROUTER_DIR:
 Router/file queue  MX_FLQ_DEBUG  MX_FLQ_LOG  MX_ROUTER_DIR:
 SMTP out  MX_SMTP_DEBUG  MX_SMTP_LOG  MX_SMTP_DIR:
 SMTP server  MX_SMTP_SERVER_DEBUG  SMTP_SERVER_LOG  MX_SMTP_DIR:
 SMTP-over-DECnet out  MX_DNSMTP_DEBUG  MX_DNSMTP_LOG  MX_DNSMTP_DIR:
 SMTP-over-DECnet server  MX_DNSMTP_SERVER_DEBUG  DNSMTP_SERVER_LOG  MX_DNSMTP_DIR:
 SMTP-over-X.25 out  MX_XSMTP_DEBUG  MX_XSMTP_LOG  MX_XSMTP_DIR:
 SMTP-over-X.25 server  MX_XSMTP_SERVER_DEBUG  XSMTP_SERVER_LOG  MX_XSMTP_DIR:
 Site Agent  MX_SITE_DEBUG  MX_SITE_LOG  MX_SITE_DIR:
 UUCP intfc  MX_UUCP_DEBUG  MX_UUCP_LOG  MX_UUCP_DIR:
 


F

Chapter 11
The MX Startup Process




-This chapter describes the command procedures(and files used by MX when it is started.]

11.1 Startup Command Procedures



>Typically, MX is started up by executing the command procedureFSYS$STARTUP:MX_STARTUP.COM. This file is created at installation time 8simply to make MX easy to start; all it does is execute MX___STARTUP.COM, whichDis located in the directory that eventually becomes the equivalence @name for the logical name MX_EXE. MX___STARTUP.COM contains the Hcommands for setting up the MX logical names and invoking MX_START.COM, also located in8the MX_EXE directory, to start the MX processing agents.

GIndividual MX components can be started by passing their names (one or ?more, separated with commas and with no intervening blanks) as jarguments to SYS$STARTUP:MX_STARTUP.COM. Table 11-1 lists the 9components that the startup command procedures recognize.

\   &                                                      
Table 11-1 Component names for use with MX_STARTUP.COM
Name Description
 LOGICALS G Defines MX logical names and installs the MX shareable libraries.
NETLIB M Executes NETLIB's startup command procedure. (Prerequisite for ROUTER, 5 SMTP, and SMTP_SERVER if using TCP/IP with MX.)
ROUTER Starts the Router process.
LOCAL & Starts the local delivery agent.
SMTP 1 Starts the SMTP-over-TCP/IP delivery agent.
 SMTP_SERVER * Starts the SMTP server (for TCP/IP).
DNSMTP 1 Starts the SMTP-over-DECnet delivery agent.
XSMTP / Starts the SMTP-over-X.25 delivery agent.
JNET Starts the Jnet Interface.
UUCP % Starts the UUCP delivery agent.
SITE Starts the SITE interface.
MLF * Starts the mailing list/file server.
LSV . Starts the gateway to L-Soft's LISTSERV.
U

11.2 Startup Data Files



BMX___STARTUP.COM uses two data files, both located in the MX root Hdirectory (MX_DIR:). MX_LOGICALS.DAT contains logical name definitions, Bsome of which can be customized or altered after MX is installed. GMX_STARTUP_INFO.DAT contains information on which of the MX components 5are installed, and on which nodes they should be run.

ADo not edit these files directly. Use the MXCONFIG.COM procedure Fprovided in the MX root directory to make any changes to the standard 1MX logical names and agent startup information. 


2

MCP Command Dictionary



>

MCP



Executes the MX Control Program.



Format



MCP [command]

      
Command QualifiersDefaults
 /[NO]FILE=file-spec " /FILE=MX_DIR:MX_CONFIG.MXCFG



PARAMETERS



[command]

?Any MCP command except the input redirection operator (@). The =specified command is executed and control is returned to DCL immediately thereafter.



DESCRIPTION

HMCP was written to be used as a DCL "foreign" command. To use =it as a foreign command, you must define a symbol as follows:

 

"
$ MCP :== $MX_EXE:MCP




FDefining the symbol in this way allows you to use the /FILE qualifier >and specify "one-shot" commands on the command line.

9By default, MCP loads in the current configuration file, %MX_DIR:MX_CONFIG.MXCFG, when started.




QUALIFIERS



/[NO]FILE=file-spec

>Loads the specified MX configuration file for editing. If not Fspecified, MX_DIR:MX_CONFIG.MXCFG is loaded. The default file type is CMXCFG. If /NOFILE is specified, MCP is started without loading any configuration information.

U

@ (Redirect Command Input)



'Executes MCP commands read from a file.



Format



@ file-spec




PARAMETERS



file-spec

GName of the file containing MCP commands. If omitted, the default file type is MCP.



DESCRIPTION

AUse this command to have MCP take further command input from the Fspecified file. There is no built-in limit on the number of levels of Enesting of command files, so be careful when using input redirection from within a command file.

BThis command can only be used at the MCP command prompt, not as a G"one-shot" MCP command. To have a file be used for input for Ban entire MCP session, use the following sequence of DCL commands.

 

"
!$ DEFINE/USER SYS$INPUT file-spec$ MCP




A

ATTACH



ATransfers control to another process in the current process tree.



Format



ATTACH [process-name]

          
Command QualifiersDefaults
/IDENTIFICATION=process-id
/PARENT



PARAMETERS



process-name

BName of the process to which the terminal should be attached. The Gprocess must be in the current process tree. This parameter is omitted &if one of the qualifiers is specified.



DESCRIPTION

AThis command is similar to the DCL ATTACH command. It is used in Binteractive jobs to attach the terminal to another process in the !current process tree for the job.



QUALIFIERS

#

/IDENTIFICATION=process-id

CSpecifies the process by its process identification, a hexadecimal number.

/PARENT

>Specifies that the terminal should be attached to the current 2subprocess's immediate parent in the process tree.

E

DEFINE/KEY



HDefines an equivalence string and a set of attributes with a key on the terminal keyboard.



Format

0

DEFINE/KEY key-name equivalence-string

                              
Command QualifiersDefaults
/ECHO
/ERASE
 /IF_STATE
 /LOCK_STATE
/LOG
 /SET_STATE
 /TERMINATE



DESCRIPTION

CSee the DCL help entry for DEFINE/KEY for more information on this command.

EYou can have a set of keys defined automatically for use with MCP by Fplacing DEFINE/KEY commands in the file SYS$LOGIN:MX_MCP_KEYDEFS.INI. ENote that this is the same file that is used with the REJMAN program.


G

DEFINE ALIAS



6Defines a local alias for transparent mail forwarding.



Format

3

DEFINE ALIAS local-name fwd-address[,...]




PARAMETERS



local-name

EA string up to 32 characters in length. Any E-mail addressed to this >name on the local host will be sent to the forwarding address.

fwd-address

CA valid E-mail address, which will be substituted for the matching Dlocal alias address. Multiple addresses may be given; use commas to Gseparate the addresses. The maximum character length for all addresses $is 255 characters, including commas.



DESCRIPTION

<An alias can be used to cause mail messages to be forwarded Bautomatically to another address. Unlike forwarding using the SET HFORWARD command in VMS Mail, no "Resent" headers are added to Hthe message. In addition, alias-based forwarding is performed by the MX Erouting agent rather than the local delivery agent, thus affording a Esmall savings in message queue space and processing time. Due to the Flack of notification, however, it is recommended that aliases be used sparingly.

M

DEFINE FILE_SERVER



Creates a file server.



Format

!

DEFINE FILE_SERVER name

                                          
Command QualifiersDefaults
 /BEGIN_SEND_PERIOD=hh:mm
 /[NO]DELAY_THRESHOLD=size
 /[NO]DESCRIPTION=text  /NODESCRIPTION
 /END_SEND_PERIOD=hh:mm
 /[NO]HOST_LIMIT=hostlim
/[NO]MAILING_LIST=listname
 /MANAGER=address
 /ROOT=rootspec
 /[NO]SERVER_LIMIT=servlim
 /[NO]USER_LIMIT=userlim



PARAMETERS

name

BLocal name to be used for the file server, up to 32 characters in length.



DESCRIPTION

BThis command is used to establish or remove an MX mail-based file Cserver on the local system. The server can be set up to distribute @groups of files called "packages" using E-mail as the Fdistribution medium. The file server responds to commands placed, one @per line, in the text of a mail message sent to the file server Cusername. The commands the file server responds to are HELP, LIST, SENDME, QUIT, and ADDRESS.

EThe root you specify with /ROOT qualifier is used by the file server @software to locate packages. Each package must have a directory @[package-name] under that root where all its files are kept. In Faddition, the file name of each of the files in the package must also Bmatch the package name. Each package must also have a file called Gpackage-name.DESCRIPTION in the top-level root directory that contains :a description of the package and the files in the package.

GThe .DESCRIPTION files may be placed in the package subdirectories, if Gdesired, but they cannot exist in both the root and the subdirectories.

CThe SENDME command takes one argument, the name of a package or an Bindividual file. If a package name is specified, all files in the Gpackage directory are sent to the requesting user. Otherwise, just the specified file is sent.

@The LIST command can take a wildcard pattern as an argument (if Homitted, it defaults to "*"). The contents of the description Hfiles of all packages whose names match the wildcard pattern are placed *in a file and sent to the requesting user.

9The HELP command causes the file server to send the file FFILESERV_HELP.TXT from the top-level root directory to the requesting Guser. A sample help file is provided with MX, which the system manager 0can modify to provide site-specific information.

FThe QUIT command causes the file server to ignore any remaining lines Gin the message. It can be used to prevent the unintentional parsing of mail signatures.

FThe ADDRESS command takes a valid RFC822-compliant address. It causes Fall file server replies to be redirected to the given address instead "of the Reply-To or From addresses.




QUALIFIERS

!

/BEGIN_SEND_PERIOD=hh:mm

HIdentifies the time of day when the file server can begin sending files 8that exceed the delay threshold size. Defaults to 17:00."

/[NO]DELAY_THRESHOLD=size

EUse /DELAY_THRESHOLD to establish the maximum size, in bytes, a file >can be to be sent at any time during the day. Files exceeding Esize are sent only during the sending period established by C/BEGIN_SEND_PERIOD and /END_SEND_PERIOD. Use /NODELAY_THRESHOLD to remove size restrictions.

/[NO]DESCRIPTION=text

EThis qualifier defines a brief description for the file server. This Ddescription is added to the file server address in the X-FileServer #header on outgoing server messages.

/END_SEND_PERIOD=hh:mm

DIdentifies the time of day when the file server should stop sending >files that exceed the delay threshold size. Defaults to 09:00.

/[NO]HOST_LIMIT=hostlim

GSpecifies that a maximum of hostlim bytes may be sent per day to any single host.$

/[NO]MAILING_LIST=list-name

ESpecifies a mailing list to be linked to the file server. Only those Fusers who are subscribed to the specified list may have access to the Hfile server. The specified list must exist on the local system in order &for this qualifier to have any effect.

/MANAGER=address

FWhen establishing a file server, you can provide an E-mail address to Gwhich all error messages and mail that bounces back to the file server Gcan be forwarded. The local alias name-Mgr will be created to Edirect those error messages to the /MANAGER address. If you omit the D/MANAGER qualifier, bounced mail will be directed to the Postmaster.

/ROOT=rootspec

FYou must specify a location (either a rooted logical or a device plus Broot directory specification) to be used as the root for the file :server files and directories. Examples of valid roots are :FILESERV_ROOT: (if it is defined as a rooted logical) and GDISK:[FILE_SERVER.] (note the final dot before the bracket, indicating it is a root specification)."

/[NO]SERVER_LIMIT=servlim

GSpecifies that a maximum of servlim bytes may be sent per day from the server.

/[NO]USER_LIMIT=userlim

GSpecifies that a maximum of userlim bytes may be sent per day to any one user.
"
X

DEFINE INSIDE_NETWORK_ADDRESS



=Defines an "inside" network address for SMTP relay determination.



Format

2

DEFINE INSIDE_NETWORK_ADDRESS ip-address

              
Command QualifiersDefaults
 /NETMASK=ip-netmask  /NETMASK=255.255.255.255
 /[NO]REJECT  /NOREJECT
 /[NO]RELAY_ALLOWED  /NORELAY_ALLOWED



PARAMETERS



ip-address

>IP address of the network or host to be added to the list, in Hdotted-decimal form. The address is assumed to be for a host unless the /NETMASK qualifier is specified.



DESCRIPTION

I This command establishes an IP address or network that is in one of the G local domains, is permitted to use your SMTP server as a relay, or to F reject a particular host or network from being considered as part of  your local domain.

G Inside network address definitions are only used with the SMTP server H is set to disallow relays with SET SMTP/NORELAY_ALLOWED. When at least H one inside address is defined, messages coming in via SMTP are allowed G to have recipients outside of the local domain(s) only if the sending ; system's IP address is on the inside network address list.

G By default, the SMTP server will still reject a message that contains E non-local addresses for both the sender and the receiver, even from I hosts on the inside network address list. You can ease that restriction # with the /RELAY_ALLOWED qualifier.




QUALIFIERS



/NETMASK=ip-netmask

= Specifies the network mask to be applied to the address, in F dotted-decimal form. The default is 255.255.255.255, which indicates 2 that the IP address is for a host, not a network.

/[NO]REJECT

F Indicates whether relay is to be rejected from the specified host or ? network. This qualifier can be used to reject SMTP relay from I particular hosts or subnetworks that are below a parent network that is , already on the inside network address list.

/[NO]RELAY_ALLOWED

E Indicates that the host(s) should be allowed full relay permission; @ that is, messages sent from the host(s) are allowed to contain 2 non-local addresses for both sender and receiver.

G This qualifier is useful when your system is acting as a central mail C hub, and there are hosts on your local network that automatically I forward messages for their local users to hosts outside your domain via H an alias. When such messages are sent back to your system (as the mail I hub), they will contain non-local addresses for both the sender and the recipient.


F

DEFINE LIST



Creates a mailing list.



Format



DEFINE LIST list-name

                                                                                          
Command QualifiersDefaults
 /[NO]ADD_MESSAGE=fspec  /NOADD_MESSAGE
 /[NO]ARCHIVE=fspec  /NOARCHIVE
 /[NO]CASE_SENSITIVE  /CASE_SENSITIVE
 /[NO]CC_POST_ERRORS  /NOCC_POST_ERRORS
 /[NO]DESCRIPTION=text  /NODESCRIPTION
 /[NO]DIGEST  /NODIGEST
 /ERRORS_TO=address  See text
/[NO]FORWARD_MESSAGE=fspec  /NOFORWARD_MESSAGE
 /[NO]HIDE_ERRORS_TO  /HIDE_ERRORS_TO
' /[NO]LIST_HEADERS=(keyword[,...])  /NOLIST_HEADERS
$ /[NO]MODERATOR=(address[,...])  /NOMODERATOR
 /OWNER=(address[,...])
 /PRIVATE  /NOPRIVATE
 /PROTECTION=prot-spec  See text
( /[NO]RECIPIENT_MAXIMUM={DEFAULT|n} /RECIPIENT_MAXIMUM=DEFAULT
 /[NO]REMOVE_MESSAGE=fspec  /NOREMOVE_MESSAGE
 /REPLY_TO=(kwd[,...])  /REPLY_TO=SENDER
! /[NO]RETURN_ADDRESS=address  See text
 /SETTINGS=(kwd[,...])  /SETTINGS=DEFAULT
 /STRIP_HEADERS=keyword  See text
 /SUBJECT_PREFIX=string  /NOSUBJECT_PREFIX
 /XHEADERS=(string[,...])  /NOXHEADERS



PARAMETERS



list-name

CLocal name to be used for the mailing list, up to 32 characters in length.



DESCRIPTION

DThis command is used to establish a mailing list. When a message is Hsent to the mailing list address, the mailing list processor forwards a Fcopy of the message to all the addresses on the list. In addition, it =can place a copy of the message in a file, called an archive.

^Mailing lists are fully described in Message Exchange Mailing List/File Server Guide.




QUALIFIERS



/[NO]ADD_MESSAGE=fspec

ESpecifies the name of a file to be sent to a user subscribing to the Dlist. If omitted, the device and directory default to MX_MLIST_DIR: A(MX_ROOT:[MLF.MAILING_LISTS]), and the file type defaults to TXT.

CThe default for this qualifier is /NOADD_MESSAGE, which causes the Hglobal add message, MX_MLIST_DIR:MLIST_ADD_MESSAGE.TXT, to be sent when qa user subscribes to the list. See Message Exchange Mailing List/File Server Guide for more information about notification messages.

/[NO]ARCHIVE=fspec

HSpecify /ARCHIVE to have the mailing list messages placed in an archive Efile automatically by the mailing list processor. For fspec Hyou must provide at least a device/directory specification. If the file Hname is omitted, the mailing list name is used as the file name for the Harchive file. If the file type is omitted, yyyy-mm is Cused as the file type, where yyyy is the current year and Hmm is the number of the current month at the time a message is added to the archive.

/[NO]CASE_SENSITIVE

CThis qualifier enables or disables case-sensitivity with regard to Fmailing list subscribers. By default, MX treats the left-hand side of Gsubscriber addresses in a case-sensitive manner with regard to SIGNOFF Hand SET commands. If a list is defined /NOCASE_SENSITIVE, then the case (of subscriber addresses will be ignored.

/[NO]CC_POST_ERRORS

@This qualifier enables or disables copying mailing post failure Gmessages to the /ERRORS_TO address. By default, if a message cannot be Hforwarded to a list, an error message is sent back to the sender of the Gmessage. If /CC_POST_ERRORS is set, those error messages are also sent Hto the /ERRORS_TO address. This lets the list owner see attempted posts 0from non-subscribers and other posting failures.

/[NO]DESCRIPTION=text

FThis qualifier defines a brief description for the mailing list. This Cdescription is added to the mailing list address in the X-ListName header on list messages.

/[NO]DIGEST

FThis qualifier enable or disables digest support for the list. A list Fmarked /DIGEST can support the DIGEST flag for subscribers. Mail sent Dto the "-digest" form of the list address will be forwarded only to /those subscribers marked as digest subscribers.

/ERRORS_TO=address

EThis qualifier is used to direct error messages and mail returned to Gthe mailing list processor to the specified address. If not specified, Dthe address of the the first specified owner of the mailing list is used.#

/[NO]FORWARD_MESSAGE=fspec

ESpecifies the name of a file to be sent to a user subscribing to the Dlist when the list does not have W:E access set. The message should Hnotify the user that the subscription request was forwarded to the list Eowner. If omitted, the device and directory default to MX_MLIST_DIR: A(MX_ROOT:[MLF.MAILING_LISTS]), and the file type defaults to TXT.

GThe default for this qualifier is /NOFORWARD_MESSAGE, which causes the !global forward-to-owner message, HMX_MLIST_DIR:MLIST_FORWARD_MESSAGE.TXT, to be sent when a user tries to psubscribe. See Message Exchange Mailing List/File Server Guide for more information about notification messages.

/[NO]HIDE_ERRORS_TO

BControls how the mailing list processor formats the envelope FROM Gaddress and Errors-To: header. When a list is set /HIDE_ERRORS_TO (the Fdefault), the address specified with the /ERRORS_TO qualifier (or the Bfirst /OWNER address, if /ERRORS_TO is not specified) is replaced 5automatically in outbound list postings by the alias H"owner-listname". Setting /NOHIDE_ERRORS_TO prevents :this substitution, using the errors-to address explicitly.2

/[NO]LIST_HEADERS=(keyword[=value][,...])

EThe /LIST_HEADERS qualifier instructs MLF to include or omit special >X-List-* headers that provide URLs for subscribing to a list, :unsubscribing from a list, and getting help for that list.

FThere are three valid keywords: SUBSCRIBE, UNSUBSCRIBE, and HELP. All @three accept values that are used in the creation of the actual Cheaders, which will be added to each message posted to the mailing Glist. However, only HELP requires a value. If the value is omitted for ESUBSCRIBE and UNSUBSCRIBE, the proper URLs for those actions will be automatically generated by MLF.

CThe List-* headers are currently a proposed Internet standard. The Gactual headers generated are X-List-Subscribe, X-List-Unsubscribe, and X-List-Help.

CClients that support these headers (both X-List-* and List-*) will @provide click buttons to perform the specified actions (usually "mailto" URLs).

jSee Message Exchange Mailing List/File Server Guide for more information on mailing list headers.'

/[NO]MODERATOR=(address[,...])

HThis qualifier is for future use. Moderated mailing lists are currently not supported.

/OWNER=(address[,...])

DThis qualifier specifies the addresses of one or more owners of the Emailing list. Each mailing list must have at least one owner, who is ;responsible for handling subscription requests not handled Aautomatically by the mailing list processor and problems with or questions about the list.

/[NO]PRIVATE

DThis qualifier specifies that the list is private and should not be Ddisplayed in response to DIRECTORY commands sent to the MXserver or @-Request addresses. The list protection is not affected by this qualifier.

/PROTECTION=prot-spec

BThis qualifier determines the protection of the mailing list. The Dprotection specification, prot-spec, is identical to a VMS /file protection specification, and defaults to H(S:RWED,O:RWED,G:RWED,W:RWE). The four protection classes are described gin Table MCP-1 and the four protection types are described in 5Table MCP-2.

Q  &                  
Table MCP-1 Mailing list protection classes
Class Description
SYSTEM M any address matching one of the addresses on the system user list (see  DEFINE SYSTEM_USERS)
OWNER N any address matching one of the owner addresses specified on the /OWNER  qualifier
GROUP L any address matching one the addresses on the subscriber list for the  mailing list
WORLD  any other address


DJust as with VMS file protections, the SYSTEM and OWNER classes are Himplicitly granted C (control) access, allowing them to use the ADD and BREMOVE commands to add and remove addresses from the mailing list.

O   &                  
Table MCP-2 Mailing list protection codes
Code Description
 R (Read) * allows the use of the REVIEW command
 W (Write) 2 allows the user to post messages to the list
 E (Enroll) < allows the automatic handling of the SUBSCRIBE command
 D (Delete) : allows the automatic handling of the SIGNOFF command


GNote that protection code E (enroll) is only meaningful when used with Gthe WORLD class and that protection code D (delete) is only meaningful when used with the GROUP class.

DSome typical GROUP and WORLD protection specifications are shown in lTable MCP-3. In most cases, you would also want to give SYSTEM and OWNER users RWED access.

J                 
Table MCP-3 Typical protection codes
 (G:RWED,W:RWE) H Public list. Anyone can subscribe, sign off, and review the list; " anyone can post to the list.
 (G:RWED,W:E) M Semi-public list. Anyone can subscribe and sign off the list, but only 1 subscribers can review or post to the list.
(G:W,W) C Private list. Only subscribers can post to the list, and all K subscription requests are screened by the owners of the mailing list.
(G,W) H One-way list. Only the owners can post to the list, and they also + screen all the subscription requests.




/  
Note

FSince electronic mail can readily be forged, you should not depend on Hthis protection scheme for absolute security of your mailing lists. The Gmailing list processor attempts no authentication of addresses when it receives messages.
+

/[NO]RECIPIENT_MAXIMUM={DEFAULT|n}

FSpecifies the maximum number of recipients to be entered per outbound Fmailing list message for the list being defined. The default setting, E/RECIPIENT_MAXIMUM=DEFAULT, causes this setting to be taken from the CSET MLF/RECIPIENT_MAXIMUM setting. Specifying /NORECIPIENT_MAXIMUM Fcauses a single outbound message to be created for each list posting, Gwith all recipients listed. You may also specify a postive integer for An, which instructs MLF to enter no more than n Brecipients in a single message. If the mailing list has more than ?n subscribers, each list posting will cause multiple, Fduplicate messages to be generated, each with no more than n recipients."

/[NO]REMOVE_MESSAGE=fspec

HSpecifies the name of a file to be sent to a user signing off the list. >If omitted, the device and directory default to MX_MLIST_DIR: A(MX_ROOT:[MLF.MAILING_LISTS]), and the file type defaults to TXT.

FThe default for this qualifier is /NOREMOVE_MESSAGE, which causes the Dglobal remove message, MX_MLIST_DIR:MLIST_REMOVE_MESSAGE.TXT, to be ksent when a user signs off the list. See Message Exchange Mailing List/File Server Guide for more (information about notification messages.

/REPLY_TO=(kwd[,...])

@Specifies how the mailing list processor should handle Reply-To Dheaders. Available reply-to types are SENDER and LIST, which may be Acombined. The default is SENDER, which prevents the mailing list Gprocessor from modifying the headers. If LIST is specified, a Reply-To Eheader is added to list messages to re-direct replies to the mailing Hlist, eliminating any existing Reply-To header in the original message. DIf LIST and SENDER are both specified, a Reply-To header containing Cboth the mailing list address and the original Reply-To address is Eadded to list messages (using the From address if no Reply-To header !existed in the original message).

?The /RETURN_ADDRESS=address qualifier can be used to supply an ?alternate list return address when /REPLY_TO=LIST is specified.$

/[NO]RETURN_ADDRESS=address

EThis qualifier is used to specify an alternate address to be used as Dthe "Reply-To:" address when /REPLY_TO=LIST is specified. GThis qualifier is most useful when multiple lists should have a common Ereturn address. For example, it can be used to redirect replies to a 8"-Digest" list back to the non-digest address."

/SETTINGS=(keyword[,...])

CThe /SETTINGS qualifier is used to override the default subscriber Bsettings for a list. The valid keywords are MAIL, REPRO, CONCEAL, #DIGEST, POST, and their "NO" forms.

EA special keyword, DEFAULT, can be used to reset the settings to the DMLF default for a mailing list. The default settings for a list are +MAIL, REPRO, NOCONCEAL, NODIGEST, and POST.

/STRIP_HEADERS=keyword

EThis qualifier is used to strip certain RFC822 headers from messages posted to a mailing list.

%The following keywords are supported:

HWhen /STRIP_HEADERS=RECEIVED is set, the Received: headers are stripped >from the incoming message before it is mailed out to the list Gsubscribers, thereby reducing the total number of Received: headers in Athe final message. This is especially beneficial to BITNET hosts Hbecause there can be a substantial number of Received: headers added to Fa message that must pass through one or more Internet/BITNET gateways.

DWhen /STRIP_HEADERS=OTHER is set, all "other" headers are Gstripped from posts. The "other" headers are any headers not =recognized by MX, which includes such headers as X- headers, >return-receipt headers, X.400 headers, etc. Setting a list to A/STRIP_HEADERS=OTHER handily gets around potential problems with Hsubscribers using the DOS package Pegasus Mail, which will send message Dreceipt messages back to a list. Note that this may not be a viable Gsetting for a mailing list that is gatewayed to a newsgroup, depending Bon the gateway software, since headers used by the gateway may be omitted.

jSee Message Exchange Mailing List/File Server Guide for more information on mailing list headers.%

/[NO]SUBJECT_PREFIX="string"

AThe /SUBJECT_PREFIX qualifier can be used to add a prefix to the FSubject line of messages posted to the list. By default, no prefix is Badded. When the list is set to /REPLY_TO=(SENDER), a short prefix Bstring may be supplied to help subscribers recognize mailing list Hmessages. The given string is bracketed by square brackets ([]) when it Dis prefixed to the subject lines. The maximum length for the prefix Fstring is 32 characters. Prefix strings should be kept short to avoid (generating extremely long subject lines.'

/[NO]XHEADERS=("string"[,...])

DThe /XHEADERS qualifier can be used to add additional site-specific Eheaders to mailing list posts. For example, you can use /XHEADERS to 6add additional non-standard "X-List-" headers such as H"X-List-Archives". The format of the header string is: "Keyword: text". HFor example, "Precedence: Bulk", which is a non-standard header used by some mailers.

GExtreme care should be taken when adding additional headers to mailing Glists to ensure that duplicate headers or improperly formatted headers D(those that don't comply with RFC 822) aren't added to mailing list posts.

jSee Message Exchange Mailing List/File Server Guide for more information on mailing list headers.


N

DEFINE LOCAL_DOMAIN



FDefines a host name or wildcard pattern as a "local" domain for the SMTP server.



Format

-

DEFINE LOCAL_DOMAIN name-or-pattern




PARAMETERS



name-or-pattern

AA host name or a string containing VMS-style wildcard characters 2against which an SMTP host name should be matched.



DESCRIPTION

DThis command is used in conjunction with the SMTP server's /NORELAY Fsetting to establish domains that the SMTP server considers local, to Cprevent messages to or from these domains from being refused. When Hrelaying in the SMTP server is disabled, it refuses to deliver messages Dto remote mailboxes when the originating mailbox is also remote. By Ddefault, the SMTP server considers any mailbox resolving to a LOCAL Hpath, or with a host name sharing the same parent domain as the MX host Hname or TCP/IP host name, as being local. If your system is acting as a Ggateway for hosts in other domains, and you disable SMTP relaying, you Gshould list the names of those other hosts, or a wildcard pattern that Dwill match those names, in a DEFINE LOCAL_DOMAIN command, to ensure Fthat messages coming from or going to those hosts will not be refused.

@You may specify multiple local domains by using multiple DEFINE ELOCAL_DOMAIN commands. Only one name or wildcard pattern is accepted Hper command. Use the REMOVE LOCAL_DOMAIN command to delete domains from the local-domain list.


G

DEFINE PATH



@Defines a mapping between a domain name and a distribution path.



Format

+

DEFINE PATH domain-name path-name

      
Command QualifiersDefaults
 /ROUTE=host-name



PARAMETERS



domain-name

2A domain name or pattern containing VMS wildcards.

path-name

=One of the supported MX path names: LOCAL, SMTP, JNET, SITE, 0DECNET_SMTP, X25_SMTP, UUCP, or HOLDING_QUEUE=n.



DESCRIPTION

CThis command is used to associate a domain name and a distribution Gpath. The Router uses this information to determine which distribution Apath should be used when routing mail messages. Each DEFINE PATH Fcommand adds a path definition to the list. The list is automatically Fsorted based on the length of the path and the presence of wildcards. FThe Router searches this list until the domain name of the address it Eis trying to route to matches the domain name or wildcard pattern of the path definition.



QUALIFIERS



/ROUTE=host-name

HSpecifies the name of a host that will route messages for the specified Gdomain. For SMTP and HOLDING_QUEUE paths, this host name must Gdirectly resolve to an IP address; it cannot be the name that has only )MX information in the Domain Name System.

O

DEFINE REWRITE_RULE



8Defines an address-rewriting rule for use by the Router.



Format

,

DEFINE REWRITE_RULE pattern result




PARAMETERS



pattern

GAn RFC 821-compliant address string, possibly with the addition of one Bor more substitution strings. The address string must include the 9opening and closing angle brackets. Any address matching >pattern will be rewritten by the Router based on the result string.

result

GAn RFC 821-compliant address string, possibly with the addition of one or more substitution strings.



DESCRIPTION

GThis command is used to provide the Router with rules for transforming Csome addresses into other forms. The pattern string is an Faddress string that must be matched to have the transformation apply. For example:

 

"
JMCP> DEFINE REWRITE_RULE "<{user}@{host}.DECnet.mycompany.com>" -N_MCP>                     "<""{host}::{user}""@myhost.mycompany.org>"




AThe strings "{user}" and "{host}" are called Bsubstitution strings. They are identified by the curly @braces surrounding the substitution name, which you may specify Carbitrarily. In the pattern string, a substitution string Amatches any number of any characters, like the asterisk in a VMS Awildcard pattern. The matched string can be substituted into the Drewritten address by specifying the same substitution string in the -result string, or it may be omitted.

BRewriting rules can be used when the DEFINE PATH/ROUTE command is Ainadequate, such as when a message must pass through two or more Egateways to get to its destination, or when the rewrite affects both Fthe local-part and the domain-part of an address. They should be used Dsparingly, however, since every address must be matched against the rewrite rules list.

DThe rewrite rules list is searched in the order you specify, so you Hshould place more specific rules before more general rules. All pattern $matching is done from right to left.


O

DEFINE SYSTEM_USERS



?Defines the address to be given SYSTEM access to mailing lists.



Format

+

DEFINE SYSTEM_USERS address[,...]




PARAMETERS



address[,...]

>One or more addresses, separated by commas. Each of the users Didentified by these addresses will be considered "system" Gusers by the mailing list processor, and granted access via the SYSTEM Eprotection class to all mailing lists. Case is important only in the Dusername portion of the address. To retain the case of the address, !surround it with quotation marks.



DESCRIPTION

GThis command is used to provide the mailing list processor with a list Eof privileged users. These users are granted access to mailing lists Fvia the SYSTEM protection class, and are also given CONTROL access to Call mailing lists. They receive all messages sent to MXserver that >cannot be handled automatically by the mailing list processor.

HThe first address on the SYSTEM_USER list is used as the return address Afor generic MXserver replies (those replies that are not about a Dspecific mailing list). For this reason, you may want to specify an alias as the first system user.

CTypically only the system manager and/or postmaster for the system Hshould be identified as system users. This will allow them to control a Amailing list on the system when the owners of the list cannot be contacted.


@

EXIT



Exits MCP.



Format



EXIT




DESCRIPTION

;Use this command to leave MCP. If you have modified the MX Econfiguration, it is saved before exiting. If the configuration file Dhas not been named, you are prompted for a file name before exiting.

@

HELP



Displays help information.



Format



HELP [topic...]




PARAMETERS



topic

FThe name of a topic in the help library. If omitted, a list of topics is displayed.

B

MODIFY



,Modifies existing configuration information.



Format

MODIFYF




DESCRIPTION

EThis command alters configuration information of the types listed in @above. Each of the MODIFY commands takes the same arguments and @qualifiers as its corresponding DEFINE command, so refer to the 3appropriate DEFINE command for further information.

H

QUEUE CANCEL



Cancels a queue entry.



Format

)

QUEUE CANCEL entry-number[,...]

      
Command QualifiersDefaults
 /[NO]LOG /NOLOG



PARAMETERS



entry-number

BQueue entry number to be cancelled. If the number of a base queue Aentry, all related agent-specific entries will also be cancelled.



DESCRIPTION

?This command sets the status of the specified queue entries to BCANCELLED, which prevents further processing of the entries. This Gshould only be done on entries which are not currently being processed ,by the Router or one of the delivery agents.



QUALIFIERS



/[NO]LOG

GCauses a message to be displayed for each cancelled entry. The default is /NOLOG.

J

QUEUE COMPRESS



Compress the message queue file.



Format



QUEUE COMPRESS

          
Command QualifiersDefaults
 /MAXIMUM_ENTRIES=value None.
 /[NO]LOG /NOLOG



DESCRIPTION

FShrinks the message queue file by creating a new file and renumbering Ball the existing entries in the file. This command may be used to Dcreate a smaller message queue, which affects the maximum number of entries allowed in the queue.

+The /MAXIMUM_ENTRIES qualifier is required.

EThis command requires exclusive access to the MX message queue file. GBefore compressing the file, all MX agents must either be shut down or inactive.




QUALIFIERS

+

/MAXIMUM_ENTRIES=number-of-entries

ESpecifies the maximum number of queue entries to be allowed. MX will Cnot allow more entries to be added to the queue than the specified Fvalue. MCP QUEUE EXTEND can be used to increase the number of allowed entries.

GThe size of the queue file in blocks is equal to the maximum number of Eentries, plus 10 blocks, plus whatever is added for the disk cluster.

/[NO]LOG

DCauses a status message to be displayed after successful operation. Default is /NOLOG.
 
H

QUEUE CREATE



Create a message queue file.



Format



QUEUE CREATE

      
Command QualifiersDefaults
 /MAXIMUM_ENTRIES=value None.



DESCRIPTION

ACreates a new, empty MX message queue file. The /MAXIMUM_ENTRIES qualifier is required.



/  
Note

FThis command simply creates a new queue file; the existing queue file Gis not automatically deleted. Any files for any existing queue entries are also left in place.


EThis command requires exclusive access to the MX message queue file. GBefore compressing the file, all MX agents must either be shut down or inactive.




QUALIFIERS

+

/MAXIMUM_ENTRIES=number-of-entries

ESpecifies the maximum number of queue entries to be allowed. MX will Cnot allow more entries to be added to the queue than the specified Fvalue. MCP QUEUE EXTEND can be used to increase the number of allowed entries.

GThe size of the queue file in blocks is equal to the maximum number of Eentries, plus 10 blocks, plus whatever is added for the disk cluster.

 
H

QUEUE EXTEND



Extends the message queue file.



Format



QUEUE EXTEND

      
Command QualifiersDefaults
 /MAXIMUM_ENTRIES=value None.



DESCRIPTION

GExtends the existing message queue file to allow more entries to be in the queue at any given time.

+The /MAXIMUM_ENTRIES qualifier is required.

EThis command requires exclusive access to the MX message queue file. GBefore compressing the file, all MX agents must either be shut down or inactive.




QUALIFIERS

+

/MAXIMUM_ENTRIES=number-of-entries

ESpecifies the maximum number of queue entries to be allowed. MX will Cnot allow more entries to be added to the queue than the specified Fvalue. MCP QUEUE EXTEND can be used to increase the number of allowed entries.

GThe size of the queue file in blocks is equal to the maximum number of Eentries, plus 10 blocks, plus whatever is added for the disk cluster.


G

QUEUE PURGE



;Purges the message queue of finished and cancelled entries.



Format



QUEUE PURGE

      
Command QualifiersDefaults
 /[NO]LOG /NOLOG



DESCRIPTION

EThis command searches the message queue for all entries of FINISH or 1CANCELLED status and deletes them from the queue.



QUALIFIERS



/[NO]LOG

HCauses a message to be displayed for each deleted entry. The default is /NOLOG.

G

QUEUE READY



Readies a queue entry.



Format

(

QUEUE READY entry-number[,...]

      
Command QualifiersDefaults
 /[NO]LOG /NOLOG



PARAMETERS



entry-number

GQueue entry number to be readied. If the number of a base queue entry, Gthe base entry will be readied and all existing agent-specific entries will be cancelled.



DESCRIPTION

EThis command sets the status of the specified queue entries to READY Eand clears the delay flag. This should only be done on entries which Gare not currently being processed by the Router or one of the delivery agents.



QUALIFIERS



/[NO]LOG

HCauses a message to be displayed for each readied entry. The default is /NOLOG.

F

QUEUE SHOW



Displays queue entries.



Format

'

QUEUE SHOW [entry-number,...]

                                                              
Command QualifiersDefaults
/ALL
 /BEFORE=time
/BRIEF
 /CREATED
/DATE
/DELAY
 /DESTINATION_AGENT=agent
/EXPIRE
/FULL
 /IN_PROGRESS
 /MODIFIED
 /ORIGIN_AGENT=agent
 /OUTPUT=file-spec
 /SINCE=time
 /WAITING



PARAMETERS



entry-number

>Queue entry number to be displayed. If omitted, all READY and "IN-PROGRESS entries are displayed.



DESCRIPTION

3This command displays entries in the message queue.



QUALIFIERS

/ALL

CCauses all queue entries to be displayed, regardless of status. If >omitted, just the READY and IN-PROGRESS entries are displayed.

/BEFORE[=time]

DSelects only those entries dated before the specified time. You can Fspecify time as an absolute time, a combination of absolute and delta Gtimes, or as one of the following keywords: TODAY (default), TOMORROW, Gor YESTERDAY. Specify one of the following qualifiers with the /BEFORE Equalifier to indicate the time attribute to be used as the basis for =selection: /CREATED (default), /DELAY, /EXPIRE, or /MODIFIED.

/BRIEF

ACauses a brief listing of all the queue entries to be displayed, Fincluding those that have finished or been cancelled. The information Gdisplayed is taken only from the MX queue file and includes the target MX process for each entry.

/CREATED

AModifies the time value specified with the /BEFORE or the /SINCE Gqualifier. The /CREATED qualifier selects entries based on their dates of creation.

/DATE

DCauses the creation and modification dates to be displayed for each queue entry.

/DELAY

AModifies the time value specified with the /BEFORE or the /SINCE Equalifier. The /DELAY qualifier selects entries based on their delay dates.!

/DESTINATION_AGENT=agent

HSelects only those entries that are to be or have been processed by the Hspecified MX agent. Valid keywords are: ROUTER, MLF, LOCAL, SMTP, SITE, GLSV, JNET, UUCP, DNSMTP, and XSMTP. This qualifier is most useful when used with /BRIEF.

/EXPIRE

AModifies the time value specified with the /BEFORE or the /SINCE Fqualifier. The /EXPIRE qualifier selects entries based on their dates of expiration.

/FULL

FProvides more details about the displayed entries, including intended Hrecipients, error counts, and last error status messages. If omitted, a 3brief, one-line display is produced for each entry.

/IN_PROGRESS

;Displays only entries marked as being in-progress (INPROG).

/MODIFIED

AModifies the time value specified with the /BEFORE or the /SINCE Hqualifier. The /MODIFIED qualifier selects entries based on their dates of modification.

/ORIGIN_AGENT=agent

CSelects only those entries that were entered into the queue by the Gspecified MX agent. Valid keywords are: LOCAL, SMTP, JNET, UUCP, SITE, MAIL, DNSMTP, XSMTP, and BSMTP.

/OUTPUT=file-spec

GDirects the results to the specified file. If omitted, the results are displayed on SYS$OUTPUT.

/SINCE[=time]

CSelects only those entries dated after the specified time. You can Fspecify time as an absolute time, a combination of absolute and delta Gtimes, or as one of the following keywords: TODAY (default), TOMORROW, For YESTERDAY. Specify one of the following qualifiers with the /SINCE Equalifier to indicate the time attribute to be used as the basis for =selection: /CREATED (default), /DELAY, /EXPIRE, or /MODIFIED.

/WAITING

;Limits the display to only those entries with READY status.

L

QUEUE STATISTICS



BDisplays statistical information concerning the entries in the MX message queue.



Format



QUEUE STATISTICS




DESCRIPTION

DThis command displays the total number of entries in the queue, the Fmaximum number of entries possible for the queue file, the percentage Eof entries in use, and the largest entry number ever used during the life of the file.

M

QUEUE SYNCHRONIZE



ESynchronizes the message queue bitmap with the actual entries in the queue.



Format



QUEUE SYNCHRONIZE

          
Command QualifiersDefaults
/LOG
/RESET



DESCRIPTION

CThis command updates the bitmap for the MX system message queue to Hsynchronize it with the actual entries in the queue. The only time this Ccommand may be necessary is in the event of a system crash or disk failure.

EThe command may be issued at any time; it does not require exclusive $access to the MX message queue file.




QUALIFIERS

/LOG

DCauses a status message to be displayed after successful operation. Default is /NOLOG.

/RESET

EResets the "Highest entry used" counter displayed by QUEUE 1STATISTICS. By default, the counter is not reset.

@

QUIT



4Leaves MCP without saving any configuration changes.



Format



QUIT




DESCRIPTION

EUse this command leave MCP without saving any of the changes made to Ethe MX configuration. If the configuration was changed, MCP will ask )for confirmation before returning to DCL.

B

REMOVE



Removes a configuration record.



Format

REMOVE5




DESCRIPTION

BThis command removes one record of the specified type from the MX Gconfiguration. The specified alias, inside network address, list name, Gdomain, rejection rule, or rewrite rule pattern must match exactly the ,identical field in the record to be removed.

CWhen removing an inside network address, you must also specify the H/NETMASK qualifier when the address is for a network rather than a host.


A

RESET



4Sends a reset signal to one or more delivery agents.



Format



RESET [agent-name...]

              
Command QualifiersDefaults
 /ACCOUNTING
 /CLUSTER
 /NODE=(node[,...])



PARAMETERS



agent-name...

FOne or more MX delivery agent names, separated by commas. Valid names Fare DECNET_SMTP, JNET, LOCAL, LSV, MLF, ROUTER, SITE, SMTP, UUCP, and FX25_SMTP. If omitted, all agents running on the same node as the user !executing this command are reset.



DESCRIPTION

GThe RESET command can be used to signal one or more MX delivery agents @to reload their configuration information. This command 'requires the SYSLCK privilege.



QUALIFIERS



/ACCOUNTING

ECauses the specified agents to open new versions of their accounting Ffiles. Only useful for those agents that support accounting, and with BMLF (which causes a new version of FILESERV_LOG.LOG to be opened).

@If /ACCOUNTING is specified, no reload of configuration data is /performed; only the accounting files are reset.

/CLUSTER

DSpecifies that the RESET command should affect all of the specified Fagents cluster-wide, rather than just the ones on the node from which the command is executed.

/NODE=(node[,...])

BSpecifies that the RESET command should affect only the specified "agents running on the given nodes.

B

REVIEW



1Displays the subscribers of a local mailing list.



Format



REVIEW mailing-list

      
Command QualifiersDefaults
 /OUTPUT=file-spec



PARAMETERS



mailing-list

GName of the mailing list whose subscriber list is to be displayed. The -mailing list must reside on the local system.



DESCRIPTION

DThis command performs the functional equivalent of the mailing list Eprocessor's REVIEW command for any mailing list on the local system. EAll subscribers' addresses and personal names (if any) listed, along with their MAIL/NOMAIL status.



QUALIFIERS



/OUTPUT=file-spec

GDirects the results to the specified file. If omitted, the results are displayed on SYS$OUTPUT.

@

SAVE



*Saves the current configuration to a file.



Format



SAVE file-spec




PARAMETERS



file-spec

HThe name of the file to which the configuration is written. If omitted, the file type defaults to MXCFG.



DESCRIPTION

CUse this command to write the MX configuration you are creating or Bchanging to a file. You should save the configuration to the file FMX_DIR:MX_CONFIG.MXCFG if you want it to be used by the MX processing agents.

K

SET DECNET_SMTP



@Alters settings specific to the SMTP-over-DECnet delivery agent.



Format



SET DECNET_SMTP

              
Command QualifiersDefaults
 /[NO]ACCOUNTING
 /MAXIMUM_RETRIES=count
/RETRY_INTERVAL=delta-time



DESCRIPTION

CThis command is used to change the SMTP-over-DECnet agent settings.



QUALIFIERS



/[NO]ACCOUNTING

HEnables or disables the recording of accounting information. Accounting His disabled by default. When enabled, accounting information is written Bto the file MX_DNSMTP_DIR:MX_DNSMTP_ACC.DAT. You can redirect the Daccounting information to another file by defining the logical name MX_DNSMTP_ACC.

'The format of the accounting record is:

 

"
Xdd-mmm-yyyy hh:mm XMIT: PROTO=DECNET_SMTP, SOURCE="src-addr", HOST="host", BYTES_SENT=n 




Gwhere dd-mmm-yyyy hh:mm is the date/time stamp of the Gaccounting record; src-addr is the source address for Hthe message; host is the host to which the message was Esent; and n is the number of bytes in the delivered message.

/MAXIMUM_RETRIES=count

ESets the maximum number of retries for message delivery. The default Gcount is 96, which for a half-hour retry interval comes to roughly two days of retries.#

/RETRY_INTERVAL=delta-time

FSets the amount of time that should elapse between delivery attempts. =The default is 30 minutes. Specify as a VMS delta time value.

D

SET JNET



/Alters settings specific to the Jnet interface.



Format



SET JNET

                      
Command QualifiersDefaults
 /[NO]ACCOUNTING
 /[NO]BSMTP_REPLY
 /[NO]LENIENT
 /[NO]PERCENT_HACK
$ /[NO]USERNAME=(username[,...])



DESCRIPTION

HThis command is used to enable or disable the various settings specific to the Jnet interface.



QUALIFIERS



/[NO]ACCOUNTING

HEnables or disables the recording of accounting information. Accounting His disabled by default. When enabled, accounting information is written >to the file MX_JNET_DIR:MX_JNET_ACC.DAT. You can redirect the Daccounting information to another file by defining the logical name MX_JNET_ACC.

'The format of the accounting record is:

 

"
Rdd-mmm-yyyy hh:mm XMIT: PROTO=proto, SOURCE="src-addr", HOST="dest", BYTES_SENT=n 




Hwhere proto is one of the BITNET mailer protocol types B(BSMTP, JNET, or BITNET), src-addr is the source Eaddress for the message, dest is the BITNET host to Dwhich the message was sent, and n is the number of Gbytes transmitted. Note that with the BSMTP and BITNET protocol types, Aone transmission can have multiple destinations on a single host.

/[NO]BSMTP_REPLY

HControls whether replies are sent for incoming BSMTP transactions. Most Chosts supporting BSMTP discard any replies, so this is disabled by "default to reduce network traffic.

/[NO]LENIENT

@Controls whether BITNET gateway rules are strictly or leniently Fenforced. The gateway rules specify that no messages may be gatewayed Bto or from a BITNET/EARN host that does not run a BSMTP-compliant Hmailer. Until more BITNET and EARN hosts start running mailers, you may @wish to use the lenient setting to avoid excessive rejection of gatewayed mail.

/[NO]PERCENT_HACK

GEnables or disables automatic percent-hack translation. The default is to enable translation.

APercent hacking should be disabled when Jnet is the only network transport being used for mail.'

/[NO]USERNAME=(username[,...])

FSpecifies the username(s) in the NJE tags on incoming mail files that Ashould be considered as being destined for the mailer. The first Husername in the list, called the primary mailer username, will Galso be used as the NJE origin user on outgoing messages, which should Gmatch the value of the :mailer tag in the XMAILER.NAMES file entry for the local host.

GIf omitted or disabled by SET JNET/NOUSERNAME, MX uses the username of Athe process running the MX/Jnet interface as the mailer username.

HGenerally, only one mailer username will be needed per system, which by EBITNET recommendations should be MAILER. The need for recognition of Hmultiple mailer usernames should occur only if you decide to change the Gmailer username for your system, during the transition period from old to new.


E

SET LOCAL



(Alters Local-delivery-specific settings.



Format



SET LOCAL

                                  
Command QualifiersDefaults
 /[NO]ACCOUNTING
 /[NO]CC_POSTMASTER
 /[NO]DISALBE_EXQUOTA
. /[NO]HEADERS=(loc:(hdrname[,...])[,...])
 /MAXIMUM_RETRIES=count
 /[NO]MULTIPLE_FROM
 /[NO]QP_DECODE
/RETRY_INTERVAL=delta-time



DESCRIPTION

AThis command is used to change the local delivery agent settings.



QUALIFIERS



/[NO]ACCOUNTING

HEnables or disables the recording of accounting information. Accounting His disabled by default. When enabled, accounting information is written @to the file MX_LOCAL_DIR:MX_LOCAL_ACC.DAT. You can redirect the Daccounting information to another file by defining the logical name MX_LOCAL_ACC.

'The format of the accounting record is:

 

"
Bdd-mmm-yyyy hh:mm DELIVER: SOURCE="src-addr", USER="user", SIZE=n 




Gwhere dd-mmm-yyyy hh:mm is the date/time stamp of the Gaccounting record; src-addr is the source address for Gthe message; user is the address on the local host to Fwhich the message was delivered; and n is the number "of bytes in the delivered message.

/[NO]CC_POSTMASTER

FSpecifies whether or not error messages resulting from LOCAL delivery Gerrors are mailed to the local POSTMASTER, in addition to the original message sender.

/[NO]DISABLE_EXQUOTA

FSpecifies whether the local delivery agent should disable the EXQUOTA Gprivilege when attempting to deliver messages to VMS MAIL. By default, GEXQUOTA privilege remains enabled during local message delivery. Using Bthe /DISABLE_EXQUOTA qualifier will prevent users' mailboxes from exceeding their diskquotas.-

/HEADERS=(loc:(hdrname[,...])[,...])

DControls the inclusion and placement of RFC 822 headers in messages Edelivered to VMS Mail. Valid values for loc are TOP Dand BOTTOM. Valid values for hdrname are listed in 7Table MCP-4.

F  " "                                                                                                  
Table MCP-4 Header name keywords
Keyword Meaning
ALL  All headers.
BCC ) The Bcc (blind carbon copy) header.
 CC " The CC (carbon copy) header.
DATE  The Date header.
FROM  The From header.
 IN_REPLY_TO  The In-Reply-To header.
 KEYWORDS 1 The Keywords header (not strictly RFC 822).
 MESSAGE_ID  The Message-Id header.
OTHER & Any header not recognized by MX.
 RECEIVED  The Received header(s).
 REFERENCES 3 The References header (not strictly RFC 822).
 REPLY_TO  The Reply-To header.
 RESENT_BCC  The Resent-Bcc header.
 RESENT_CC  The Resent-CC header.
 RESENT_DATE  The Resent-Date header.
 RESENT_FROM  The Resent-From header.
 RESENT_MESSAGE_ID # The Resent-Message-Id header.
 RESENT_REPLY_TO ! The Resent-Reply-To header.
 RESENT_SENDER  The Resent-Sender header.
 RESENT_TO  The Resent-To header.
 RETURN_PATH  The Return-Path header.
SENDER  The Sender header.
SUBJECT  The Subject header.
 TO  The To header.


CThe header names can be negated by prefixing them with NO. You may Ginclude any combination of headers for inclusion at the top and/or the Eend of the message. For example, you might want to move the Received =and Return-Path headers to the bottom of messages, since the Dinformation they convey are of interest only when there are network problems:

 

"
?MCP> SET LOCAL/HEADERS=(TOP:(ALL,NORECEIVED,NORETURN_PATH),-@_MCP>                    BOTTOM:(NOALL,RECEIVED,RETURN_PATH))




/MAXIMUM_RETRIES=count

DSets the maximum number of retries for DECnet message delivery. The Cdefault count is 96, which for a half-hour retry interval comes to roughly two days of retries.

/[NO]MULTIPLE_FROM

HControls whether or not the VMS Mail "From:" line on incoming Bmessages can contain multiple return addresses. By default, if an GRFC822 From: or Reply-To: line contains more than one address, as many <of those addresses as will fit are included on the VMS Mail :"From:" line (up to 255 characters). Specifying G/NOMULTIPLE_FROM limits the "From:" line to a single address.

/[NO]QP_DECODE

DControls whether or not incoming MIME quoted-printable messages are Gautomatically decoded by MX Local before delivery through VMS Mail. By Fdefault, such messages are decoded. If your users read their mail via FPOP or IMAP, you might want to disable the decoding to let the users' browsers do the decoding.#

/RETRY_INTERVAL=delta-time

FSets the amount of time that should elapse between delivery attempts. =The default is 30 minutes. Specify as a VMS delta time value.

C

SET MLF



/Alters MLF (Mailing List/File server) settings.



Format



SET MLF

          
Command QualifiersDefaults
/[NO]DELAY_DAYS[=(dow...)]
/[NO]RECIPIENT_MAXIMUM[=n]



DESCRIPTION

EThis command sets global parameters for the Mailing List/File Server agent (MLF).



QUALIFIERS

#

/[NO]DELAY_DAYS[=(dow...)]

B Specifies the days of the week on which file servers' send-delay E threshold should be respected. The default is to respect send-delay I thresholds on every day of the week. A list of day-of-week names may be A specified. Specify /NODELAY_DAYS to globally disable send-delay thresholds on all file servers.#

/[NO]RECIPIENT_MAXIMUM[=n]

H Sets the maximum number of recipients per message generated by the MLF H agent. If your MLF agent services large mailing lists with many remote F subscribers, you may want to use this setting to limit the number of A recipients per message generated by MLF. This will break up the I distribution to the mailing list into smaller chunks, allowing for more  parallelism in delivery.

FSetting too small a value, however, could create a lengthy backlog in Fyour MX message queue, depending on the number of subscribers on your Fmailing list(s) and the number of messages the list receives each day.

HThe default is /NORECIPIENT_MAXIMUM, which forces each incoming mailing :list message to be forwarded as just one outbound message.


F

SET ROUTER



Alters Router-specific settings.



Format



SET ROUTER

              
Command QualifiersDefaults
 /[NO]ACCOUNTING
 /[NO]OMIT_VMSMAIL_SENDER
 /[NO]PERCENT_HACK



DESCRIPTION

FThis command is used to enable or disable the automatic de-hacking of Bpercent signs in a local address. Percent-hacking is explained in 4Section 3.3.



QUALIFIERS



/[NO]ACCOUNTING

HEnables or disables the recording of accounting information. Accounting His disabled by default. When enabled, accounting information is written Bto the file MX_ROUTER_DIR:MX_ROUTER_ACC.DAT. You can redirect the Daccounting information to another file by defining the logical name MX_ROUTER_ACC.

<The format of the accounting record is one of the following:

 

"
^dd-mmm-yyyy hh:mm ROUTE: SENDER="src-addr", RCPT="rcp-addr", ROUTE="host", PATH=path, BYTES=n cdd-mmm-yyyy hh:mm BOUNCE: SENDER="src-addr", RCPT="rcp-addr", ORIGRCPT="orcp-addr", ERROR="errmsg" 




Gwhere dd-mmm-yyyy hh:mm is the date/time stamp of the Gaccounting record; src-addr is the source address for Cthe message; rcp-addr is the recipient's address; Dorcp-addr is the recipient's address before it was Fchanged by any rewrite rules; host is the host route @associated with the matching path; path is the 5delivery path (agent) that will deliver the message; Herrmsg is the text of the error message describing why Erouting failed; and n is the number of bytes in the delivered message.!

/[NO]OMIT_VMSMAIL_SENDER

DEnables or disables the omission of the Sender: header for messages Hsent from VMS Mail. Normally, a Sender: line is included if the Sender: Aand From: addresses are different. However, some sites using the GMX_SITE_NAME_CONVERSION feature with the FULL_CONVERT routine have had Eproblems sending mail to some mailers when the Sender: and From: are Cdifferent, despite the fact that it is allowed by RFC822 (in fact, Eaccording to RFC822, the Sender: should be omitted if it is the same Gaddress as the From: address). To allow those sites to work around the Fproblems with those mailers, /OMIT_VMSMAIL_SENDER can be used to omit the Sender: line in all cases.

ZMX_SITE_NAME_CONVERSION is documented in the Message Exchange Programmer's Guide.



/  
Note

DIf /OMIT_VMSMAIL_SENDER is specified, then the Sender: line is also ;omitted from any SMTP messages forwarded by users with the 1MX_FAKE_RFC822 process rights identifier.


/[NO]PERCENT_HACK

GEnables or disables automatic percent-hack translation. The default is to enable translation.

D

SET SITE



4Alters settings specific to the SITE delivery agent.



Format



SET SITE

          
Command QualifiersDefaults
 /MAXIMUM_RETRIES=count
/RETRY_INTERVAL=delta-time



DESCRIPTION

7This command is used to change the SITE agent settings.



QUALIFIERS



/MAXIMUM_RETRIES=count

ESets the maximum number of retries for message delivery. The default Gcount is 96, which for a half-hour retry interval comes to roughly two days of retries.#

/RETRY_INTERVAL=delta-time

FSets the amount of time that should elapse between delivery attempts. =The default is 30 minutes. Specify as a VMS delta time value.

D

SET SMTP



'Alters SMTP-delivery-specific settings.



Format



SET SMTP

                                      
Command QualifiersDefaults
 /[NO]ACCOUNTING
 /DEFAULT_ROUTER=hostname
 /DNS_RETRIES=dnscount
 /MAXIMUM_RETRIES=count
 /[NO]RBL_CHECK[=domain]
 /[NO]RELAY_ALLOWED  /RELAY_ALLOWED
/RETRY_INTERVAL=delta-time
! /[NO]VALIDATE_SENDER_DOMAIN
 /[NO]VERIFY_ALLOWED



DESCRIPTION

;This command is used to change the SMTP interface settings.



QUALIFIERS



/[NO]ACCOUNTING

HEnables or disables the recording of accounting information. Accounting His disabled by default. When enabled, accounting information is written >to the file MX_SMTP_DIR:MX_SMTP_ACC.DAT. You can redirect the Daccounting information to another file by defining the logical name MX_SMTP_ACC.

'The format of the accounting record is:

 

"
qdd-mmm-yyyy hh:mm XMIT: PROTO=SMTP, SOURCE="src-addr", HOST="dest", SENT-TO="relay", BYTES_SENT=n, RCPT=rcp-addr 




Gwhere src-addr is the source address for the message; Ddest is the name of the Internet host to which the @message was directed; relay is the name of the 6Internet host to which the message was actually sent; ;n is the number of bytes transmitted; and Ercp-addr is the recipient's address. One accounting Emessage is written for each successful delivery of a message, so one 4message could result in multiple accounting records.!

/DEFAULT_ROUTER=hostname

HSpecifies the name of a host to which SMTP messages can be forwarded if EMX cannot resolve a host name. This qualifier should only be used if 8you are not using the Internet domain name service. The Hhostname should be the name of a host which appears in your local host table.

/DNS_RETRIES=dnscount

GSets the maximum number of retries for SMTP delivery when the cause of Gthe failure is the inability to determine the address corresponding to Ea host name. Certain types of domain server failures can cause MX to Gbelieve a host name is invalid. When a host name is genuinely invalid, Fhowever, the sender should be told relatively quickly. Therefore, the Cdefault count is 12 (giving about 6 hours' worth of attempts for a half-hour retry interval).

/MAXIMUM_RETRIES=count

BSets the maximum number of retries for SMTP message delivery. The Cdefault count is 96, which for a half-hour retry interval comes to roughly two days of retries.

/[NO]RBL_CHECK[=domain]

GControls whether the SMTP server checks to see if a connecting host is Don the Internet Realtime Blackhole List (RBL) before allowing it to 3start an SMTP session. This is disabled by default.

DWhen /RBL_CHECK is specified without a domain, the default $domain is rbl.maps.vix.com.

sSee Section 8.5 for more information about the Realtime Blackhole List.

/[NO]RELAY_ALLOWED

GControls whether the SMTP server accepts "relayed" messages. ?A relayed message is a message from a remote source that lists @recipients that are also remote. Relaying is allowed by default.

EWhen relaying is disabled, the SMTP server examines the originator's Faddress on each incoming message as well as each recipient's address. EIf both addresses are remote, delivery to the remote recipient(s) is >refused. By default, any address that maps to a LOCAL path is Bconsidered local, as is any host name that shares the same parent Ddomain as the MX host name or the TCP/IP host name. You may specify Eother host or domain names that should also be considered local with the DEFINE LOCAL_DOMAIN command.#

/RETRY_INTERVAL=delta-time

FSets the amount of time that should elapse between delivery attempts. =The default is 30 minutes. Specify as a VMS delta time value.$

/[NO]VALIDATE_SENDER_DOMAIN

FEnables or disables a check by the SMTP server on the validity of the Adomain name appearing in the SMTP MAIL FROM: command on incoming Gmessages. When enabled, the SMTP server attempts to look up the domain Cname of the sender in the domain name system; if the name does not Dappear in the DNS (with any type of resource record), the MAIL FROM Hcommand, and hence the incoming message, will is rejected. This setting is disabled by default.

FEnabling this option can be useful in preventing unwanted junk e-mail Afrom entering your system, since junk e-mail is often sent using Efictitious return addresses, sometimes with nonexistent domain names.

/[NO]VERIFY_ALLOWED

HEnables or disables the processing of VRFY commands in the SMTP server. DThe VRFY command, a required command in the SMTP protocol, is often Dused by users on other systems to check whether or not a particular Gmailbox is valid. This information can be regarded as a security risk, Fand security-conscious system administrators may want to prevent VRFY commands from being processed.

&By default, VRFY commands are allowed.


H

SET X25_SMTP



>Alters settings specific to the SMTP-over-X.25 delivery agent.



Format



SET X25_SMTP

              
Command QualifiersDefaults
 /[NO]ACCOUNTING
 /MAXIMUM_RETRIES=count
/RETRY_INTERVAL=delta-time



DESCRIPTION

EThis command is used to change the SMTP-over-X.25 interface settings.



QUALIFIERS



/[NO]ACCOUNTING

HEnables or disables the recording of accounting information. Accounting His disabled by default. When enabled, accounting information is written @to the file MX_XSMTP_DIR:MX_XSMTP_ACC.DAT. You can redirect the Daccounting information to another file by defining the logical name MX_XSMTP_ACC.

'The format of the accounting record is:

 

"
Udd-mmm-yyyy hh:mm XMIT: PROTO=X25_SMTP, SOURCE="src-addr", HOST="dest", BYTES_SENT=n 




Gwhere src-addr is the source address for the message; Gdest is the name of the host to which the message was Fsent; and n is the number of bytes transmitted. Note @that with X25_SMTP messages, one transmission can have multiple destinations on a single host.

/MAXIMUM_RETRIES=count

FSets the maximum number of retries for X25_SMTP message delivery. The Cdefault count is 96, which for a half-hour retry interval comes to roughly two days of retries.#

/RETRY_INTERVAL=delta-time

FSets the amount of time that should elapse between delivery attempts. =The default is 30 minutes. Specify as a VMS delta time value.

@

SHOW



5Displays all or part of the current MX configuration.



Format



SHOWD

          
Command QualifiersDefaults
 /[NO]COMMAND  /NOCOMMAND
 /OUTPUT=file-spec  /OUTPUT=SYS$OUTPUT:



DESCRIPTION

@The SHOW command displays the specified parts of the current MX Dconfiguration. For aliases, file servers, lists, paths, and rewrite Grules, only those records matching pattern (which may contain Fwildcard characters) are displayed; if you omit pattern, all records are displayed.

DSHOW CONFIGURATION_FILE displays the name of the configuration file ?loaded when MCP was started. SHOW VERSION displays the version )identifier for the current version of MX.




QUALIFIERS



/[NO]COMMAND

FThe /COMMAND qualifier indicates that the display should be formatted Gas the commands that would be entered to create the specified records. FUse /COMMAND with the /OUTPUT qualifier to create an MCP command file Gthat can be altered with your favorite editor, then read back into MCP to create a new configuration.

/OUTPUT=file-spec

EThe /OUTPUT qualifier is used to direct the SHOW result to a file or Hother device. By default, the result is displayed on the current output device, SYS$OUTPUT.

D

SHUTDOWN



7Sends a shutdown signal to one or more delivery agents.



Format

"

SHUTDOWN [agent-name...]

          
Command QualifiersDefaults
 /CLUSTER
 /NODE=(node[,...])



PARAMETERS



agent-name...

FOne or more MX delivery agent names, separated by commas. Valid names <are DECNET_SMTP, JNET, LOCAL, LSV, MLF, ROUTER, SITE, SMTP, GSMTP_SERVER, UUCP, and X25_SMTP. If omitted, all agents running on the ;same node as the user executing this command are shut down.

GNote that the SMTP delivery agent may be shut down separately from the SMTP_SERVER message entry agent.




DESCRIPTION

CThe SHUTDOWN command can be used to signal one or more MX delivery Hagents to finish processing and exit. This command requires the SYSLCK privilege.



QUALIFIERS



/CLUSTER

GSpecifies that the SHUTDOWN command should affect the specified agents 7on all nodes in the cluster, not just the current node.

/NODE=(node[,...])

GSpecifies that the SHUTDOWN command should affect the specified agents only on the given nodes.

A

SPAWN



Spawns a subprocess.



Format



SPAWN [dcl-command]




PARAMETERS



dcl-command

CA DCL command to be executed in the subprocess. If omitted, MCP is =suspended and the terminal is attached to the subprocess for Einteractive entry of commands. To return to the process running MCP, 1use the DCL LOGOUT command to end the subprocess.



DESCRIPTION

GThis command creates a subprocess to execute one or more DCL commands. ESee the description of the DCL SPAWN command for further information.

B

STATUS



DDisplays a list of the MX agent processes currently running and the $current state of each agent process.



Format

STATUS [agent-name...]

      
Command QualifiersDefaults
 /NODE=(node[,...])



PARAMETERS



agent-name...

AOne or more MX agent names, separated by commas. Valid names are EDECNET_SMTP, JNET, LOCAL, LSV, MLF, ROUTER, SITE, SMTP, SMTP_SERVER, @UUCP, and X25_SMTP. If omitted, information about all agents is displayed.



DESCRIPTION

GFor each process running one of the MX agent programs, the process ID, >process name, MX status, and MX agent type is displayed. In a DVMScluster environment, the VMScluster node name for the process is 9also displayed. This command requires the SYSLCK privilege.

GThe status field indicates the action currently being performed by the lagent. Valid status descriptions are shown in Table MCP-5.

I                                                                         
Table MCP-5 MCP STATUS Descriptions
Unknown " Current status is not known.
 Reading Config. ( Reading the MX configuration file.
Idle 7 Process is idle, waiting for an entry to process.
 Enabling * Requesting single agent enable lock.
 Selecting 8 Searching in-memory queue for an entry to process.
 Searching 8 Searching in-memory queue for an entry to process.
 Locating J Initializing the in-memory queue by searching the MX queue file for , entries to be processed by that agent.
 Searching2 4 Searching in-memory queue for located entries.
 Processing % Processing the specified entry.
 Retrying / Retrying delivery of the specified entry.
 Inserting " Inserting a new queue entry.
 Search. for wait $ Searching for delayed entries.
 Waiting for 3 Idle, waiting to process the specified entry.
 Req update 1 Requesting other agents to update an entry.
 FLQ Cleanup + Performing MX queue file maintenance.
 FLQread wait 0 Waiting for a read from the MX queue file.
 Wlock wait " Waiting for entry work lock.
 Connected J SMTP Server has the specified number of incoming connections active.




QUALIFIERS



/NODE=(node[,...])

HSpecifies that the STATUS command should show only the specified agents running on the given nodes.



5

REJMAN Command Dictionary



B

REJMAN



"Executes the MX Rejection Manager.



Format



REJMAN [command]

      
Command QualifiersDefaults
 /DATABASE=file-spec



PARAMETERS



command

BAny REJMAN command except the input redirection operator (@). The =specified command is executed and control is returned to DCL immediately thereafter.



DESCRIPTION

GREJMAN was written to be used as a DCL "foreign" command. To 5use it this way, you must define a symbol as follows:

 

"
$ REJMAN :== $MX_EXE:REJMAN




@Defining the symbol in this way allows you to use the /DATABASE Hqualifier and specify "one-host" commands on the command line.

<By default, REJMAN loads in the current configuration file, 1MX_DIR:MX_REJECTION_DATABASE.MXCFG, when started.



/  
Note

FREJMAN requires the SYSLCK privilege to be able to lock the rejection 8database from being modified by other processes.



QUALIFIERS



/DATABASE=file-spec

FLoads the specified rejection database for editing. If not specified, Dthe default database, MX_DIR:MX_REJECTION_DATABASE.MXCFG, is loaded.
"
U

Command Input Redirection



)Execute REJMAN commands stored in a file.



Format



@ file-spec




PARAMETERS



file-spec

AName of the file containing REJMAN commands. If the file type is !omitted, the default type is MCP.



DESCRIPTION

DUse this command to have REJMAN take further command input from the Fspecified file. There is no built-in limit on the number of levels of Enesting of command files, so be careful when using input redirection from within a command file.

EThis command can only be used at the REJMAN command prompt, not as a F"one-shot" REJMAN command. To have a file be used for input @for an entire REJMAN session, use the following sequence of DCL commands.

 

"
!$ DEFINE/USER SYS$INPUT file-spec$ REJMAN



"
I

ADD EXCLUSION



1Adds an exclusion to heuristic junk mail filters.



Format

"

ADD EXCLUSION sender-pat

      
Command QualifiersDefaults
 /HEURISTIC=heuristic-name



PARAMETERS



sender-pat

GE-mail address or wildcard pattern to match the sender of the message, Eas it would appear in either the RFC822 From header or the SMTP MAIL FROM command.



DESCRIPTION

AThis command adds a new exception to one or all of the heuristic Hfilters. If the sender (from either the RFC822 From header, or the SMTP EMAIL FROM return path) of a message matches this address or pattern, Fthe message is excluded from the specified heuristic filter check (or 3all checks if the /HEURISTIC qualifier is omitted).



QUALIFIERS

"

/HEURISTIC=heuristic-name

GSpecifies the heuristic filter to which this exclusion applies. If not Gspecified, the exclusion is added to the global exclusion list for all heuristic filter checks.
!
I

ADD REJECTION



:Adds a rejection rule to the database for the SMTP server.



Format

-

ADD REJECTION sender-pat [rcpt-pat]

                  
Command QualifiersDefaults
 /ACCEPT[=accept-kwd]
 /ADDRESS=ip-addr-pat
/HEADER
/MESSAGE=rejection-message



PARAMETERS



sender-pat

GE-mail address or wildcard pattern to match the sender of the message, Aas it would appear in the SMTP MAIL FROM command. If the /HEADER Hqualifier is specified, this parameter is treated as a wildcard pattern Dto match an RFC822 header in the message, and the rcpt-pat ,parameter and other qualifiers are not used.

rcpt-pat

AE-mail address or wildcard pattern to match the recipient of the Emessage, as it would appear in the SMTP RCPT TO command. If omitted, @matching only occurs against the sender, and a match causes the Hrejection to happen immediately after receipt of the MAIL FROM command, %rather than on a per-recipient basis.

FThis parameter is not permitted if the /HEADER qualifier is specified.




DESCRIPTION

<This command adds a new rejection rule to the database. For Faddress-based rejection rules (those not specifying /HEADER), a match occurs for any of the following:
    J
  1. sender-pat is specified with no rcpt-pat, and the I address in the SMTP MAIL FROM command matches the specified address or I pattern. The sending system is notified of the rejection in the status * code returned for the MAIL FROM command.G
  2. sender-pat and rcpt-pat are both specified. In G this case, the SMTP MAIL FROM address must match sender-pat F and the RCPT TO address must match the rcpt-pat. The check G occurs on receipt of the RCPT TO command, and if a match occurs, the J sending SMTP system is notified of the rejection in the status returned E on the RCPT TO. Note that this may not prevent the delivery of the H message to other users who do not match the rcpt-pat pattern.
EIn both cases, the rule can be restricted by the use of the /ADDRESS Fqualifier; if specified, the sending SMTP system's numeric IP address Gmust match the address or pattern specified on that qualifier. You may Emodify the behavior of MX's SMTP server when a match occurs by using Fother qualifiers; see the qualifier descriptions for more information.

=Header-based rules are specified with the /HEADER qualifier. @Header-based rules are checked only after the entire message is Breceived by the SMTP server, and if a match occurs, the sender is Fnotified of the rejection after it transmits the termination sequence G(CRLF-dot-CRLF) for the message. Header-based rules affect delivery to Gall specified recipients of a message; the rcpt-pat parameter ?is not used. Other qualifiers are not allowed when the /HEADER qualifier is used.




QUALIFIERS



/ACCEPT[=accept-kwd]

DSpecifies that the message should be accepted rather than rejected. DThis qualifier can be used to provide exceptions to other rejection =rules; it applies only when both the sender-pat and =rcpt-pat parameters are specified. Valid values for accept-kwd are:?This qualifier cannot be used in combination with the /MESSAGE #qualifier or the /HEADER qualifier.

/ADDRESS=ip-addr-pat

FSpecifies either an IP address (in dotted-decimal form) or a wildcard Hpattern for matching an IP address. If specified, the IP address of the Hsending SMTP system is obtained for the incoming connection and matched Hagainst the specified address or pattern. This qualifier is not allowed when /HEADER is specified.

/HEADER

CModifies the type of rejection rule to be based on RFC822 headers, <rather than on SMTP envelope addresses. When specified, the Gsender-pat parameter is used for matching RFC822 headers that Emight be present in the incoming message, and no other parameters or qualifiers are allowed.#

/MESSAGE=rejection-message

GSpecifies the message emitted by the SMTP server which accompanies the FSMTP status code indicating that the MAIL FROM or RCPT TO command has Dbeen rejected. By default, a generic message is emitted, indicating Dthat rejection for the sender or recipient has been programmed. You Ccannot use this qualifier with either the /HEADER qualifier or the /ACCEPT qualifier.

B

ATTACH



ATransfers control to another process in the current process tree.



Format



ATTACH [process-name]

          
Command QualifiersDefaults
/IDENTIFICATION=process-id
/PARENT



PARAMETERS



process-name

BName of the process to which the terminal should be attached. The Gprocess must be in the current process tree. This parameter is omitted &if one of the qualifiers is specified.



DESCRIPTION

AThis command is similar to the DCL ATTACH command. It is used in Binteractive jobs to attach the terminal to another process in the !current process tree for the job.



QUALIFIERS

#

/IDENTIFICATION=process-id

CSpecifies the process by its process identification, a hexadecimal number.

/PARENT

>Specifies that the terminal should be attached to the current 2subprocess's immediate parent in the process tree.

A

CHECK



DChecks to see if an address would be blocked by the rejection rules.



Format

2

CHECK sender-address [recipient-address]

      
Command QualifiersDefaults
 /ADDRESS=ip-address



PARAMETERS



sender-address

DAn e-mail address as it would appear on an SMTP MAIL FROM: command, 'representing the sender of the message.

recipient-address

BAn e-mail address as it would appear on an SMTP RCPT TO: command, Frepresenting the message recipient. If not specified, only the sender address will be checked.



DESCRIPTION

CThis command simulates the check performed by the SMTP server on a Esender address, optionally combined with a recipient address and the numeric IP address of a host.

HCHECK will signal its success or failure in finding a matching rule. If Bsuccessful, the patterns in the rule are displayed in the message.




QUALIFIERS



/ADDRESS=ip-address

HSpecifies the IP address to be used in the rejection check. This should &be specified in dotted-decimal format.

F

DEFINE/KEY



HDefines an equivalence string and a set of attributes with a key on the terminal keyboard.



Format

0

DEFINE/KEY key-name equivalence-string

                              
Command QualifiersDefaults
/ECHO
/ERASE
 /IF_STATE
 /LOCK_STATE
/LOG
 /SET_STATE
 /TERMINATE



DESCRIPTION

CSee the DCL help entry for DEFINE/KEY for more information on this command.

HYou can have a set of keys defined automatically for use with REJMAN by Fplacing DEFINE/KEY commands in the file SYS$LOGIN:MX_MCP_KEYDEFS.INI. BNote that this is the same file that is used with the MCP program.

"
L

DELETE EXCLUSION



6Removes an exclusion from heuristic junk mail filters.



Format

%

DELETE EXCLUSION sender-pat

      
Command QualifiersDefaults
 /HEURISTIC=heuristic-name



PARAMETERS



sender-pat

GE-mail address or wildcard pattern to match the sender of the message, Eas it would appear in either the RFC822 From header or the SMTP MAIL FROM command.



DESCRIPTION

HThis command removes an entry from either the global exclusion list, or Gfrom the exclusion list for a specific heuristic filter. If the sender H(from either the RFC822 From header, or the SMTP MAIL FROM return path) Fof a message matches this address or pattern, the message is excluded @from the specified heuristic filter check (or all checks if the !/HEURISTIC qualifier is omitted).



QUALIFIERS

"

/HEURISTIC=heuristic-name

GSpecifies the heuristic filter to which this exclusion applies. If not Gspecified, the matching entry is removed from the the global exclusion %list for all heuristic filter checks.

L

DELETE REJECTION



+Removes a rejection rule from the database.



Format

0

DELETE REJECTION sender-pat [rcpt-pat]

          
Command QualifiersDefaults
 /ADDRESS=ip-addr-pat
/HEADER



DESCRIPTION

BThis command deletes a rule from the rejection database. Deletion Eoccurs when the specified parameters and qualifiers match the values used when the rule was added.



QUALIFIERS



/ADDRESS=ip-addr-pat

FSpecifies either an IP address (in dotted-decimal form) or a wildcard Gpattern for matching an IP address. This qualifier is not allowed when /HEADER is specified.

/HEADER

CModifies the type of selected rejection rule to be based on RFC822 0headers, rather than on SMTP envelope addresses.
+
M

DISABLE HEURISTIC



8Disables junk mail heuristic filters in the SMTP server.



Format

/

DISABLE HEURISTIC [heuristic-name...]

      
Command QualifiersDefaults
/ALL



PARAMETERS



heuristic-name

CA comma-separated list of one or more keywords that identifies the „heuristic filters to be disabled. See ENABLE HEURISTIC for the list of heuristic filter names.



DESCRIPTION

EThis command disables one or more of the heuristic junk mail filters.



QUALIFIERS

/ALL

FDisables all heuristic filters. No parameters are permitted when this qualifier is specified.
*
L

ENABLE HEURISTIC



7Enables junk mail heuristic filters in the SMTP server.



Format

.

ENABLE HEURISTIC [heuristic-name...]

          
Command QualifiersDefaults
/ALL
( /CONFIDENCE_LEVEL={DEFAULT|clevel}



PARAMETERS



heuristic-name

FA comma-separated list of one or more of the following keywords which &identify the heuristics to be enabled:



DESCRIPTION

DThis command enables one or more of the heuristic junk mail filters.



QUALIFIERS

/ALL

EEnables all heuristic filters. No parameters or other qualifiers are +permitted when this qualifier is specified.+

/CONFIDENCE_LEVEL={DEFAULT|clevel}

ESpecifies the confidence level to be associated with a match against >this filter. This is a local qualifier that must be specified #immediately after a heuristic name.

?The confidence level for a filter is a number representing the Clikelihood that a message matching that filter is junk mail. A low Aconfidence level indicates that the message is more likely to be Glegitimate; a high confidence level indicates that the message is more Blikely to be junk mail. Each message passed through the heuristic Cfilters is assigned the highest possible confidence level for each Gfilter it matches, until either all enabled filters are checked or the Dmessage is given a confidence level that is greater than the REJECT +level set with the SET HEURISTIICS command.

EIf the DEFAULT keyword is specified, the built-in default confidence Dlevel for the heuristic is set. Otherwise, specify a decimal number 8from 0 through 10 to set a non-default confidence level.


@

EXIT



4Saves changes to the database and exits the program.



Format



EXIT




DESCRIPTION

FThis command saves the changes made during the current REJMAN session and exits the program.

@

HELP



+Displays information about REJMAN commands.



Format



HELP [topic]




PARAMETERS



topic

HTopic, such as a REJMAN command, about which you want help. If omitted, *a list of available commands is displayed.



DESCRIPTION

CThis command displays descriptions and other information on REJMAN commands.

@

QUIT



)Exits the program without saving changes.



Format



QUIT




DESCRIPTION

HThis command causes the program to exit without saving the changes made Eduring the current session. You will be prompted for confirmation if you have made any changes.

A

PURGE



-Purges old rejection rules from the database.



Format



PURGE

          
Command QualifiersDefaults
 /BEFORE=date-time  See text.
 /[NO]LOG /LOG



DESCRIPTION

GThe PURGE command deletes rejection rules from the database considered D"old;" that is, they were last used by the SMTP server to Freject messages before a date in the past. By default, rules not used Cfor 30 days are purged from the database; you may override this by !specifying the /BEFORE qualifier.



QUALIFIERS



/BEFORE=date-time

FBy default, the PURGE command deletes records that have not been used Afor 30 days. You may override this cut-off date with the /BEFORE qualifier.

/LOG

FBy default, the PURGE command logs a message indicating the number of Arules purged from the database, along with the cut-off date when Hsuccessful. Specify /NOLOG to prevent this message from being issued on a successful PURGE.

@

SAVE



,Writes out the rejection database to a file.



Format



SAVE [file-spec]




PARAMETERS



file-spec

FName of the file to which the database should be written. If omitted, Gthe default is MX_DIR:MX_REJECTION_DATABASE.MXCFG, or the file pointed -to by the logical name MX_REJECTION_DATABASE.



DESCRIPTION

EThis command writes the rejection database to a file. To ensure that Ethe MX SMTP server uses the rejection database information, omit the Cfile specification to allow REJMAN to write the information to the default location.
"
J

SET HEURISTICS



=Modifies global settings for the heuristic junk mail filters.



Format



SET HEURISTICS

              
Command QualifiersDefaults
I /CONFIDENCE_LEVEL=[(ACCEPT=number,REJECT=number)]
 /[NO]INCLUDE_REASON  /NOINCLUDE_REASON
6 /REJECT_ACTION={DROP|FORWARD[=address]}



DESCRIPTION

FThis command modifies the global settings for the heuristic junk mail filter in the SMTP server.



QUALIFIERS



/CONFIDENCE_LEVEL

HSets the confidence levels for accepting and rejecting messages as junk Email. Each heuristic filter has a confidence level, representing the Blikelihood that a message matching that filter is junk mail. This Cqualifier is used to set the thresholds for accepting a message as 0legitimate and rejecting a message as junk mail.

EThis qualifier takes a list of keywords (ACCEPT, REJECT) that assign Cthe threshold values. Each keyword must be specified with a value, Ewhich is either a number from 0 to 10 or the keyword DEFAULT. If you Gspecify both the ACCEPT and REJECT keywords, you must enclose the list in parentheses.

The default settings are:

 

"
&/CONFIDENCE_LEVEL=(ACCEPT=0,REJECT=8) 


FA message is considered fully acceptable when its assigned confidence Flevel is less than or equal to the ACCEPT threshold; in that Gcase, the message is passed on to recipients with no further action. A Fmessage is considered junk mail when its assigned confidence level is Egreater than the REJECT threshold; in that case, the action 3specified by SET HEURISTICS/REJECT_ACTION is taken.

HMessages assigned confidence levels between the two thresholds ?are considered partially acceptable. They are passed on to the Grecipients with an additional header (X-Junk-Mail-Rating) warning them >that the message may be junk mail. A second additional header Hcontaining the reason for the warning may also be included based on the &SET HEURISTICS/INCLUDE_REASON setting.

/INCLUDE_REASON

EFor a message that is assigned a confidence level that falls between Fthe ACCEPT and REJECT thresholds, specifies that an additional header B(X-Junk-Mail-Reason) be included in the message to explain to the Hrecipient why the message was flagged with a warning indicating that it 5might be junk mail. The default is /NOINCLUDE_REASON.

/REJECT_ACTION

ESpecifies the action to take when the confidence level assigned to a Fmessage exceeds the REJECT threshold. This qualifier takes one of two Gkeyword values. The DROP keyword specifies that the SMTP server should Edrop the message by sending an error status back to the sending SMTP Asystem. The FORWARD keyword specifies that the message should be Gdiverted to a different address. You may specify an address as a value <for the FORWARD keyword; if omitted, the default address is (Postmaster on the local system.

HWhen the FORWARD keyword is specified, the message is silently diverted Hto the forwarding address, with headers added to the top of the message Eindicating the reason the message was rejected, the original sending Faddress, and the original recipients for the message. This setting is Fprovided so that the local postmaster or other responsible person can Gverify that any messages rejected by the heuristic filters are in fact Gjunk mail. In the case that a rejected message is actually legitimate, Cthe system manager can then forward the message on to its intended Drecipients and modify the heuristic filter configuration to prevent 0such messages from being rejected in the future.

+The default setting is /REJECT_ACTION=DROP.


@

SHOW



1Displays rejection entries and other information.



Format



SHOW keyword

          
Command QualifiersDefaults
 /COMMAND
 /OUTPUT=file-spec



PARAMETERS



keyword

?Specifies the information to be shown. Acceptable keywords are BDATABASE_FILE, HEURISTICS, KEY, REJECTIONS, and VERSION. You must specify one of these keywords.



DESCRIPTION

GSHOW DATABASE_FILE displays the name of the database file that you are modifying.

ESHOW KEY displays key definitions. Refer to the DCL SHOW KEY command for further information.

@SHOW REJECTIONS displays the entries in the rejection database, Finculding their reference counts, the date and time they were entered Gin the database, and the date and time they were last used by the SMTP server.

>SHOW VERSION displays the version of MX running on the system.




QUALIFIERS



/COMMAND

AFormats the output as REJMAN commands. This can be used with the C/OUTPUT qualifier to create a REJMAN command file to re-create the rejection database from scratch.

/OUTPUT=file-spec

EDirects the displayed information to the specified file. By default, Houtput is displayed on the current standard output device (based on the SYS$OUTPUT logical name).

A

SPAWN



Spawns a subprocess.



Format



SPAWN [dcl-command]




PARAMETERS



dcl-command

FA DCL command to be executed in the subprocess. If omitted, REJMAN is =suspended and the terminal is attached to the subprocess for Hinteractive entry of commands. To return to the process running REJMAN, 1use the DCL LOGOUT command to end the subprocess.



DESCRIPTION

GThis command creates a subprocess to execute one or more DCL commands. ESee the description of the DCL SPAWN command for further information.


 


 `
Index^ Contents