<COMMENT>

   File:	MGMT_GUIDE.SDML

   Abstract:	VAX DOCUMENT source for _Message Exchange Management Guide_

   Authors:	Matt Madison
		Hunter Goatley

Copyright (c) 2008, Matthew Madison.

All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

    * Redistributions of source code must retain the above
      copyright notice, this list of conditions and the following
      disclaimer.
    * Redistributions in binary form must reproduce the above
      copyright notice, this list of conditions and the following
      disclaimer in the documentation and/or other materials provided
      with the distribution.
    * Neither the name of the copyright owner nor the names of any
      other contributors may be used to endorse or promote products
      derived from this software without specific prior written
      permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

   Modified by:

	29-AUG-1993	Goatley		Updated for MX V4.0.
	14-APR-1993	Goatley		Updated for MX V3.3.
	26-FEB-1993	Goatley		Added MX_UUCP_REWRITE section.
					Added MX_PROTOCOL_PREFIX docs.
	15-FEB-1993	Goatley		Updated for MX v3.2.
	28-MAR-1994	Goatley		Updated for MX V4.0.
	 3-JUN-1994	Goatley		Updated for MX V4.1.
    	14-JAN-1997 	Madison	    	Add MLF setting.
    	17-FEB-1997 	Madison	    	Add spam settings.
    	07-APR-1997 	Madison	    	More new stuff.
    	03-MAY-1997 	Madison	    	Even more new stuff.
    	08-MAY-1997 	Madison	    	Log file defspec change.
    	22-JUN-1997 	Madison	    	SMTP server log file change.
    	    	    	    	    	SMTP reject notifications.
    	28-SEP-1997 	Madison	    	Add REJMAN commands.
	 3-OCT-1997	Goatley		Add DEFLIST qualifiers.
	15-OCT-1997	Goatley		Added SPAWN, ATTACH, DEFINE/KEY.
	21-NOV-1997	Goatley		Added SET LOCAL/QP_DECODE.
    	19-APR-1998 	Madison	    	Added SET LOCAL/DISABLE_EXQUOTA.
    	24-APR-1998 	Madison	    	SET ROUTER/ACCOUNTING, SET SMTP/RBL.
    	14-JUN-1998 	Madison	    	SMTP relays, heuristic filters.
    	01-SEP-1998 	Madison	    	Holding queues.
    	11-OCT-1998 	Madison	    	More revisions for V5.1.
    	30-JAN-2000 	Madison	    	Holding queue changes for V5.2.
    	26-NOV-2000 	Madison	    	More V5.2 changes.
    	22-DEC-2000 	Madison	    	More V5.2 changes.
    	13-JAN-2001 	Madison	    	Even more V5.2 changes.
        14-FEB-2002     Madison         V5.3 changes.
        03-Feb-2008     Madison         Cleanup for V6.0 open-source release.

<ENDCOMMENT>
<INCLUDE>(SYMBOLS.SDML)
<FRONT_MATTER>(MGMT_GUIDE_1)

<TITLE_PAGE>
<TITLE>(<REFERENCE>(mgmtguide))
<ABSTRACT>(<REFERENCE>(RELMONTH))

<P>
This manual describes the management and operation of
Message Exchange, electronic mail software for VMS systems.
<ENDABSTRACT>
<REVISION_INFO>(This is a revised manual.)
<REVISION_INFO>(Operating System and Version:\OpenVMS Alpha [tbd] or later)
<REVISION_INFO>(\OpenVMS Industry Standard 64 [tbd] or later)
<REVISION_INFO>(Software Version:\Message Exchange <REFERENCE>(VER))
<ENDTITLE_PAGE>(Matthew Madison<LINE>Santa Cruz, California)

<INCLUDE>(COPYRIGHT.SDML)

<CONTENTS_FILE>

<PREFACE>(9\MGMT_GUIDE_2)

<P>
This guide describes the management and operation of Message Exchange (MX).

<head1>(Intended Audience\MGMT_GUIDE_3)
<P>
This manual is intended for use by the system manager or any individual
responsible for installing and maintaining MX.  The reader should be
generally familiar with VMS system concepts, electronic mail systems and
networking terminology.

<head1>(Document Structure\MGMT_GUIDE_4)
<P>
This guide consists of two parts.  Part I contains nine chapters which
contain information on management and operation of the various components of
MX.  Part II is the command dictionary for the MX Control Program (MCP).
<table>
<table_setup>(2\10)
<table_row>(Chapter 1\Contains information about how Message Exchange operates.)
<table_row>(Chapter 2\Describes how to use the MXCONFIG procedure.)
<table_row>(Chapter 3\Describes how to manage the Router functions.)
<table_row>(Chapter 4\Describes how to manage the message delivery agents.)
<table_row>(Chapter 5\Describes how to manage the message entry agents.)
<table_row>(Chapter 6\Describes how to manage the message queue.)
<table_row>(Chapter 7\Describes some miscellaneous MX utilities.)
<table_row>(Chapter 8\Describes the tools available for troubleshooting MX.)
<table_row>(Chapter 9\Describes the MX startup process.)
<endtable>

<head1>(Related Documents\MGMT_GUIDE_5)
<P>
You can find additional information in the following documents:
<list>(unnumbered)
<le><reference>(instguide) describes the installation of MX.
<le><reference>(userguide) describes MX features available to general users.
<le><reference>(progguide) describes the programmable customization features
<le><reference>(mlfguide) describes the MX Mailing List/File Server.
<le><reference>(relnotes) contain information and updates not included
in this manual.  The release notes are part of the software distribution kit.
<le><reference>(rfc821) describes the SMTP protocol.
<le><reference>(rfc822) describes the format of headers and addresses
used by Internet hosts.
<le><reference>(rfc1123) provides additional information on SMTP support
for Internet hosts.
<endlist>
<ENDPREFACE>
<ENDFRONT_MATTER>
<PART>


<CHAPTER>(Overview of Message Exchange Operation\MGMT_GUIDE_6)
<P>
This chapter briefly describes how MX operates.

<HEAD1>(What is a Message?\MGMT_GUIDE_7)
<P>
Electronic mail messages are usually divided up into three parts:

<list>(unnumbered)
<le>The <newterm>(envelope).  Much like an envelope used for mail in the
real world, an electronic mail envelope includes a return address and
destination information.  Unlike real mail, however, one message can
have multiple destinations.  In addition, addresses on the envelope can
be changed as they pass through a system.

<le>The <newterm>(headers).  Message headers include information about
the message that the recipient will see when he or she reads the message.
This information includes the date the message was sent, the subject
of the message, who sent it and who will receive it, and which systems
the message passed through on its way to the recipient.

<le>The <newterm>(body).  This is the message text itself, as entered
by the person (or other entity) that sent the message.
<endlist>

<P>
There are several standards for the format of each part of a message.
MX uses the Internet RFC 822 format for message headers and body, and
Internet RFC 821 format for envelope information.  When sending messages
to non-Internet sites, MX will convert the message format as needed to
comply with the standards required by the destination system.
<reference>(msgparts) is an example of a message broken down into its
parts.
<figure>(Message parts\msgparts)
<line_art>

Envelope:

    <user1@host1.org>       Return address
    <user2@host2.org>       Recipient #1
    <user3@host3.org>       Recipient #2

Headers:

    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:

    Just a quick note to let you know I'm alive.
    Have a nice day.

<endline_art>
<endfigure>

<head1>(What is an Address?\MGMT_GUIDE_9)
<P>
Much like the address on a real envelope, an electronic mail address
indicates where a message should be delivered, or where it came from.
MX uses the Internet RFC 822 format for addresses.  RFC 822 specifies
a very rich syntax for addresses, but most are of the form:
<syntax>
                           local-part@domain
<endsyntax>
<cp>Where <keyword>(domain) usually identifies a system and
<keyword>(local-part) identifies the user on that system.

<SUBHEAD1>(Envelope Addresses\MGMT_GUIDE_10)
<P>
Envelope addresses are kept by MX in a special format, the
route-address, which adheres to Internet RFC 821.  Users cannot
generally use route-addresses when addressing mail; they are used
internally by MX and other mail systems for tracking the route a
message has taken to get from source to destination, or for forcing a
particular route to be taken for a message.

<P>
A route-address has the form
<syntax>
                          <local-part@domain>
                                  or
               <@domain[,@domain...]:local-part@domain>
<endsyntax>
<cp>This form of addressing is discouraged on the Internet, but is used
when messages are gatewayed between multiple mail networks.

<head1>(MX Components\MGMT_GUIDE_11)
<P>
Message Exchange consists of several parts:

<list>(unnumbered)
<le>A <newterm>(message queue), where all messages are stored during
processing by MX.

<le><newterm>(Message entry agents).  These programs or processes take
messages in from users or from other networked hosts and enter them in the
message queue for processing.

<le>The <newterm>(Router).  This is the <quote>(hub) of MX processing.  All
incoming messages have their envelope information processed by the
Router to determine how they should be delivered.

<le><newterm>(Message delivery agents).  These programs or processes take
messages that have been processed by the router and deliver them either to
local users or to other networked hosts.

<le>The <newterm>(Mailing List/File Server) (MLF) agent.  This special process
handles all mailing list and file server requests.
<endlist>

<HEAD2>(The Message Queue\MGMT_GUIDE_13)
<P>
All MX messages are stored in a directory called the message queue
(sometimes called the <newterm>(file queue)).  This is the directory pointed
to by the
<x>(Logical names<xs>MX_FLQ_DIR)
logical name MX_FLQ_DIR.

Besides the files comprising the messages themselves, the queue
directory also contains a file called MX_SYSTEM_QUEUE.FLQ_CTL. This
file, called the <newterm>(queue control file), is a sequential file
that contains information about the state of each message, who is
processing it, etc.  All MX processes access their queue entries
through this control file.


<P>
The size of the queue control file determines the maximum number of entries
that can be in the queue at any given time.  The larger the file, the more
entries that can be in the queue.


<P>
Because the message queue is shareable cluster-wide, a user on any
node in a VMScluster can send messages over a network, even if there is

no direct network connection (via TCP/IP or DECnet) on the
particular node to the target network.<FOOTNOTE>(1\
When following the MX clustering guidelines described in
<reference>(instguide).)


<HEAD2>(Message Entry Agents\MGMT_GUIDE_14)
<P>
Messages are entered into MX by users from VMS Mail through the MX% protocol
prefix.  This invokes routines in image MX_EXE:MX_MAILSHR.EXE, which create the
necessary files in the message queue for processing by the Router.

<P>
Messages coming in from other hosts are handled by

<list>(unnumbered)
<le>an SMTP server, for messages coming in over TCP/IP;
<le>a DECnet-SMTP server, for messages coming in via SMTP-over-DECnet;
<le>the MX_SITE_IN program, for messages coming in from a
locally-created network interface.
<endlist>

<P>
Messages are also entered into the queue by the Mailing List/File
Server (MLF) agent, in response to a mailing list or file server
request.

<HEAD2>(The Router\MGMT_GUIDE_15)
<P>
The Router is responsible for taking the envelope information from a
message and determining where the message should be sent based on the
addresses listed in the envelope.

<P>
Each recipient address in the envelope is processed in two or three
phases:

<list>(numbered)
<le>In the <emphasis>(rewrite) phase, the address is checked against
a list of rewriting rules.  If it matches one of the rules, the rule
is applied and the original address is replaced.

<le>In the <emphasis>(path identification) phase, the <emphasis>(next
hop) domain of the address is identified and that domain is checked
against the domain-path mapping list.  This identifies the delivery
agent that will be called on to deliver the message to the recipient.

<le>If the recipient is on the local system, a third phase is entered,
which checks to see if the <emphasis>(local-part) of the address is an
alias for another address, a mailing list name, or file server name.
<endlist>

<P>
The Router is also responsible for maintaining the message queue. It
cleans out completed or cancelled entries.

<HEAD2>(Delivery Agents\MGMT_GUIDE_16)
<P>
The Local delivery agent delivers mail to local users or to other
hosts over DECnet using VMS Mail.  It also identifies local users who
have used SET FORWARD to direct their mail elsewhere and resends
messages to their forwarding addresses.

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

<list>(unnumbered)
<le>The SMTP delivery agent sends messages using the Simple Mail
Transfer Protocol over TCP/IP.

<le>The DECNET_SMTP delivery agent sends messages using the Simple Mail
Transfer Protocol over DECnet.

<le>The SITE delivery agent passes messages to a locally-created network
interface package.

<endlist>

<P>
Each delivery agent is responsible for converting MX-format messages
into the format required for the particular network or network
interface package.

<HEAD2>(MLF Agent\MGMT_GUIDE_17)
<P>
The Mailing List/File Server (MLF) agent is a special form of delivery
agent that handles mailing list and file server requests.  It doesn't
actually deliver messages to a network directly.  What it does is
create new messages based on the list or server requests and sends the
new messages back to the Router for processing and eventual delivery.




<Chapter>(Configuring MX with MXCONFIG\MGMT_GUIDE_18)
<p>This chapter describes the MXCONFIG procedure, MX_DIR:MXCONFIG.COM.

<HEAD1>(Why Use MXCONFIG?\MGMT_GUIDE_19)
<P>
Configuring MX by hand can be a complicated and error-prone process, due
to the number of options available.   Based on a question-and-answer
script, MXCONFIG creates the MX startup information for its logical names
and agent invocation, as well as a command file that will generate an MX
configuration database.  Configurations created with MXCONFIG should
be adequate for most Internet sites; it can also be
used as a base that can be tailored using the MX Control Program
(MCP), if needed.

<head1>(Using MXCONFIG\MGMT_GUIDE_20)
<p>When you execute MXCONFIG, it displays a menu of configuration
options:
<interactive>

                  Message Exchange Configuration Procedure

Main Menu

    1. Configure MX message queue logical names.
    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:
<endinteractive>
<P>To completely reconfigure MX, start with menu option 1, then
select each of the other options in order as you complete each
section.  Each section displays information about the items being
configured, then asks you to answer some questions.  Read the
explanations carefully before answering.
<P>When you are finished with your configuration changes, select
option 5 from the main menu to exit from the configuration procedure.
You will be asked whether you would like to save the configuration 
changes before the procedure exits.

<chapter>(Managing the Router\MGMT_GUIDE_21)
<p>This chapter describes the MCP commands used to configure and control
the Router.

<head1>(Rewrite Rules\MGMT_GUIDE_22)
<p>Address-rewriting rules, or <emphasis>(rewrite rules) for short, are
<x>(rewrite rules)<x>(address-rewriting rules)
checked by the Router for every recipient address on every envelope of
every message that passes through MX. A rewrite rule consists of a
pattern and a result. If an address matches the pattern, the rule is
applied and the address rewritten per the rule's result.  The purpose
of this is to provide a general means of altering envelope addresses,
primarily for handling multi-gateway cases where DEFINE PATH/ROUTE is
insufficient.

<p>
Be careful, since the rule processor treats the addresses as ordinary
text strings and does not understand the syntax of RFC 821 addresses.  
Because they were designed mainly for handling domain aliases, rewrite
patterns are matched from right to left.

<P>
The rewrite rule list is searched only once per address, until a
matching 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.

<P>
An example of an application for rewrite rules is the mapping of an
artificial domain name, such as
<emphasis>(host)<emphasis>(.dnet\bold), into an address for delivery
through VMS MAIL over DECnet:

<interactive>
<s>(MCP> )<U>(DEFINE REWRITE_RULE "<{user}@{host}.dnet>" -)
<s>(_MCP> )<u>(                   "<""{host}::{user}""@local.host.name>")
<endinteractive>

<P>
The pattern matching routine treats the variable references in the
first string as wildcards; everything between the left angle bracket
and the at sign is copied into the {user} variable, and everything
between the at sign and the string <emphasis>(.dnet>\bold) is copied
into the {host} variable.  The variable names have no special
significance to the pattern matching routine.

<HEAD2>(Regular Expressions in Rewrite Rules\regexp_rewrites)
<P>
For more sophisticated pattern matching, MX supports the use of
UNIX-style regular expressions in rewrite rules.  Specify the
/REGEX qualifier on the DEFINE REWRITE_RULE command to have the
rule invoke the regular expression parser.  The example rule
show above could be specified as:
<INTERACTIVE>
<s>(MCP> )<U>(DEFINE REWRITE_RULE/REGEX "<([[:username:]]+)@([[:domain:]]+)<BACKSLASH>.dnet>" -)
<s>(_MCP> )<U>(                         "<""<BACKSLASH>2::<BACKSLASH>1""@local.host.name>")
<ENDINTERACTIVE>
<P>
When using regular expressions, use parentheses to enclose subexpressions
that you would like to include in the rewritten address.  Up to 9 such
subexpressions can be used; to instantiate them in the rewritten address,
use a backslash followed by a digit (1-9).
<P>
MX's regular expression support includes two character classes,
<QUOTE>([:username:]) and <QUOTE>([:domain:]), in addition to the standard
classes.  These additional classes match those characters
permitted in the username portion and domain name portion of SMTP addresses,
respectively. See <REFERENCE>(REGEX_DOC) for further information on
regular expressions.

<head1>(Defining Delivery Paths\MGMT_GUIDE_DEFPATH)
<p>The first step the Router takes in determining a delivery path is to
identify the next hop the message should take.  The next hop is
<x>(next hop)<x>(delivery path)
determined by looking at the address and selecting either the first domain in
the route path at the beginning of the address, or if there is no route path,
the destination domain.  The second step is to search the list of defined
domain/path mappings to determine the delivery path, and possibly a routing
host for that domain.
<p>The MCP DEFINE PATH command is used to create a domain/path mapping.
<x>(DEFINE PATH)<x>(MCP commands<xs>DEFINE PATH)
A mapping consists of a domain pattern (possibly containing VMS
wildcard characters) and the name of the delivery path to be used if
the next hop matches the domain pattern.  Possible paths are
DECNET_SMTP, HOLDING_QUEUE=<EMPHASIS>(n), LOCAL, SITE, and SMTP.

<p>For example, a typical path list for an Internet host might be created
with the commands:
<interactive>
<s>(MCP> )<U>(DEFINE PATH myhost.mycompany.ORG   LOCAL)
<s>(MCP> )<U>(DEFINE PATH myhost                 LOCAL  ! abbreviation)
<s>(MCP> )<U>(DEFINE PATH [1.2.3.4]              LOCAL  ! numeric address)
<s>(MCP> )<U>(DEFINE PATH *                      SMTP)
<endinteractive>

<p>The path list is searched sequentially until a match is made.  The
first three rules catch any locally-addressed messages.  The next two
rules provide transparent routing of addresses in the UUCP
<quote>(fake domain) through an Internet gateway. The
last rule, which would match any other domain name, routes all other
messages off-system via SMTP.  Notice that abbreviations or nicknames
for the local host must have LOCAL path definitions to be recognized
by MX.

<head1>(Alias Translation\altran)
<p>The third phase of Router address processing is the identification and
<x>(Alias)
translation of local aliases.  The system manager or postmaster can
define aliases on the local system that translate to any local or remote
address with the MCP DEFINE ALIAS command.  If an address, after passing
through the first two Router phases, is identified as a local address,
the Router searches the alias list.  If the local part of the original 
address matches one of the aliases, the original address is discarded and
the alias address is substituted in its place and is passed through
the other address processing phases.
<p>Note that alias processing is totally transparent to the sender
as well as the recipient of a message.  No message headers are changed
or added to indicate that the message is being forwarded via an alias
address.  In addition, aliases are kept in a simple list that is
searched sequentially, 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.

<p>Also performed during this phase is <quote>(percent-dehacking) of
<x>(Percent-hack)
addresses.  MX supports the <quote>(percent-sign hack) that allows users
to route messages through the local system by specifying an address of
the form <quote>(user%host1@host2).  If the local part of the address
is found to contain a percent sign, the percent sign is converted to
an at sign, the original address is discarded, and the new address is
substituted as for aliases.  While this form of routed addressing is
not recommended, it is sometimes required when the local host is
acting as a gateway between two networks.  You can disable the
percent-dehacking function with the MCP command SET ROUTER/NOPERCENT_HACK.

<head1>(Controlling the Router Process\MGMT_GUIDE_25)
<p>The Router process will respond to shutdown and reset signals sent
by the MCP SHUTDOWN and RESET commands, respectively.  Using these
commands is the only way that the Router can be shut down or reset
without possibly losing messages.
<P>You can control Router functions, such as creation of an accounting
log, with the MCP SET ROUTER command.


<HEAD1>(Logging Router Events\LOGROUTER)
<P>Major events in the Router process, such as startup, shutdown, and
configuration resets, are automatically logged to the Router's log file,
MX_ROUTER_DIR:MX_ROUTER_nodename.LOG_<EMPHASIS>(process-id).
These events may also be logged
to an operator console by defining the logical name
<x>(Logical names<xs>MX_EVENT_OPER_CLASS) MX_EVENT_OPER_CLASS:
<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_EVENT_OPER_CLASS class-name)
<ENDINTERACTIVE>
<P>where <emphasis>(class-name) can be any recognized OPCOM operator class,
such as NETWORK.
<p>This logical name must be defined <emphasis>(before\bold) MX is started
in order to have any effect.   Its definition affects all MX processing agents.



<chapter>(Managing the Delivery Agents\MGMT_GUIDE_38)
<p>This chapter describes some of the MCP commands used to configure
and control the various MX delivery agents.

<head1>(Local Delivery Options\MGMT_GUIDE_39)
<p>The local delivery agent can be configured to place message header
lines at either the beginning of the message text, the end of the message
text, or both, when delivering locally through VMS Mail.
<p>
In addition, you can control whether accounting information is generated,
the delivery retry interval, and the maximum retry count.  By
default, unsuccessful deliveries into VMS Mail are retried every half hour up
to 96 times total (giving a two-day period) before being returned to
sender.
<p>The MCP SET LOCAL command
can be used to alter any of these settings; refer to the command
description for further information.

<head1>(SMTP and DECNET_SMTP Delivery Options\MGMT_GUIDE_40)
<p>As with the local delivery agent, you can alter the accounting
setting, the retry interval,
and the maximum retry count for SMTP and DECNET_SMTP deliveries.
However,
the SMTP agent differentiates between failed deliveries due to domain name
lookup failures and other kinds of failed deliveries, and you can set a
different maximum retry count for DNS lookup failures.  The MCP SET SMTP and
SET DECNET_SMTP commands are used to alter the settings for
the three delivery agents.
The defaults are 30 minutes for retry interval, 12
DNS failures maximum (for SMTP only), and 96 general failures maximum.
<p>Refer to the command
descriptions for further information.
<head2>(Internet <quote>(Mail Exchanger) Support\MGMT_GUIDE_41)
<p>Some of the supported TCP/IP packages include domain name resolvers that
provide access only to host name-to-address mapping information.
However, not all
Internet domain names map directly to addresses.  Domain names are also
used to identify hosts on other networks to which electronic
mail can be sent via some other Internet-connected gateway host, called a
<newterm>(mail exchanger).
<x>(Mail exchanger)
<P>Mail exchangers are recorded in the Internet Domain Name System (DNS)
using mail exchanger resource records (MXRRs).
The initial list of DNS
servers to be asked for MXRR information is controlled by the NETLIB software.
Refer to the NETLIB documentation for further information.

<HEAD2>(Character Set Conversion\cconv_delivery)
<P>
The Local Delivery agent performs character conversion when formatting
the VMS MAIL From: and Subject: lines from the contents of the RFC822
message headers, and can also perform conversion of non-MIME message
bodies, or MIME messages with a Content-Type of text/plain.  This
conversion is the inverse of the conversion performed by the VMS MAIL
interface; see <REFERENCE>(cconv) for more information.

<head2>(Default SMTP Router\MGMT_GUIDE_42)
<p>When the local system uses host tables instead of Domain Name Service,
you may want to establish a default router for SMTP messages.
 The SMTP delivery agent
<x>(SMTP default router)
will automatically forward to the default router all messages addressed
to users on hosts whose names are not found either in the Domain Name
System or in the local host table provided by your TCP/IP package.
<p>A default router is established in MCP with the SET SMTP/DEFAULT_ROUTER
command.
<p>Before you use a default router, you should ensure that:
<list>(unnumbered)
<le>The host name for the system you are using as a default router is
known to your system's TCP/IP (i.e., is in your system's host tables).
<le>The default router you select <quote>(knows) more about the
Internet than your host, or in turn can forward to another host that
has access to more domain name information.
<le>You have the consent of the people managing the system you intend
to use as a default router.  This is especially important if you
expect the traffic between your system and the default router to be
heavy.
<endlist>

<HEAD2>(SMTP Lock Files\smtplockfile)
<P>To prevent SMTP delivery agents from getting tied up with delivering
messages to sites that are unreachable, they create <quote>(lock files)
to track failures with specific domains and hosts that they have failed
to reach.  These files are created in MX_SMTP_LOCK_DIR:, which by default
is located at MX_ROOT:[SMTP.LOCK].
<P>Before an SMTP agent tries to contact a mail server, it first checks
to see if a lock file exists for that server.  If so, it compares the
time that file was last modified against the SMTP retry interval.  If
the retry interval has not been exceeded, it immediately returns the
message being processed to the queue for a later attempt.  If no lock
file exists, or the lock file is older than the retry interval, the
SMTP agent attempts to contact the mail server.  If the server is
unreachable, the SMTP agent creates a lock file to prevent other
attempts to reach that server until the retry interval has elapsed.
<P>Lock files are used for both domain names as well as the individual
IP addresses that the SMTP agent tries to reach for each domain.  The
lock file directory is automatically cleaned periodically during the
message queue cleanup process invoked by either the Router or the
FLQ Manager agent.
<HEAD3>(Excluding Hosts from Locks\lockexcl)
<P>Occasionally, there may be mail servers that you need to exclude
from the lock file checking; for example, a local mail server that
your system sends many messages to, but is subject to occasional
recahability problems that causes excessive backlogs in the MX
message queue.  You can exclude these hosts from lock file checks
by defining the logical name MX_SMTP_LOCK_EXCLUSIONS (in
<X>(logical names<xs>MX_SMTP_LOCK_EXCLUSIONS)
executive mode).  You should define this logical name with
both the domain names as well as the IP addresses of the hosts
you need to exclude; wildcards are permitted.
<P>For example, if you need to exclude all of the hosts in
domain <quote>(mycompany.com), all of which are on the IP
network <quote>(10.12.100.0), you would define the logical
name as follows:
<INTERACTIVE>
<S>($ ) <U>(DEFINE/SYSTEM/EXEC MX_SMTP_LOCK_EXCLUSIONS -)
<S>(_$ )<U>(                   "*.mycompany.com",-)
<S>(_$ )<U>(                   "10.12.100.*")
<ENDINTERACTIVE>
<P>This will prevent the SMTP agents from locking out any
mail server under this domain (and also on this network) from
being locked out.
<P>You can prevent the SMTP agents from creating any lock
files by defining MX_SMTP_LOCK_EXCLUSIONS as <quote>(*).
However, this is not recommended.

<head1>(SITE Delivery Options\sitedelopt)
<p>The SITE delivery agent includes support for retry on error.  The
MCP SET SITE command can be used to alter the retry interval and maximum
retry count.  Refer to the SET SITE command description for further information.


<head1>(Shutdowns and Resets\MGMT_GUIDE_47)
<X>(Shutting down MX)
<p>Each of the delivery agents will respond to shutdown and reset
signals as sent by the MCP SHUTDOWN and RESET commands, respectively.
Using these commands is the only guaranteed way of cleanly shutting down
and resetting the delivery agents, without loss of messages in progress.

<P>The MCP SHUTDOWN command can be forced to wait for the completion
of a shutdown by using the /WAIT qualifier.  This qualifier is recommended
when including an MX shutdown sequence in your system's SYSHUTDWN.COM
procedure.

<P>
There may be times when it is necessary to prevent local users from
using VMS Mail to send mail via MX.  To do so, define the
executive-mode system logical name MX_SHUTDOWN:
<x>(Logical names<xs>MX_SHUTDOWN)

<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_SHUTDOWN TRUE)
<ENDINTERACTIVE>

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


<HEAD1>(Logging Delivery Agent Events\LOGAGENT)
<P>Major events in the delivery agents, such as startup, shutdown, and
configuration 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
<x>(Logical names<xs>MX_EVENT_OPER_CLASS) MX_EVENT_OPER_CLASS:
<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_EVENT_OPER_CLASS class-name)
<ENDINTERACTIVE>
<P>where <emphasis>(class-name) can be any recognized OPCOM operator class,
such as NETWORK.
<p>This logical name must be defined <emphasis>(before\bold) MX is started
in order to have any effect.  Its definition affects all MX processing agents.



<Chapter>(Managing Message Entry Agents\MGMT_GUIDE_48)
<p>This chapter describes the options available with the MX message
entry agents.
<head1>(Local Message Entry\lclmsge)
<p>The VMS MAIL interface (MX_MAILSHR) is used for local message entry.
<x>(MX_MAILSHR)  It is controlled through the definition of system-wide
logical names.


<P>
<X>(VMS MAIL<XS>restricting usage)
Use of MX through VMS Mail can be restricted by defining the
executive-mode logical MX_RESTRICT_USAGE in the system logical
name table:
<x>(Logical names<xs>MX_RESTRICT_USAGE)

<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_RESTRICT_USAGE TRUE)
<ENDINTERACTIVE>

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

<INTERACTIVE>
<S>($ )<U>(set default sys$system:)
<S>($ )<U>(run authorize)
<S>(UAF> )<U>(ADD/IDENTIFIER MX_MAIL_ACCESS)
<S>(Identifier MX_MAIL_ACCESS value: %X8001000D added to rights data base)
<S>(UAF> )<U>(GRANT/IDENTIFIER MX_MAIL_ACCESS GOATHUNTER)
<S>(Identifier MX_MAIL_ACCESS granted to GOATHUNTER)
<S>(UAF> )
<ENDINTERACTIVE>

<P>
Users not holding the identifier and trying to send mail through MX
will see an error message stating that they are not authorized to send
mail using MX.

<HEAD2>(System-wide MX Aliases for Outgoing Addresses\syswidemxalias)
<P>
MX supports the use of personal and system-wide alias databases for
defining aliases for frequently-used addresses for outgoing mail.  The
MXALIAS utility, described in the <REFERENCE>(userguide), is used to
maintain the database file.

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

<INTERACTIVE>
<S>($ )<U>(set file/prot=w:re mx_dir:mx_global_alias.dat)
<S>($ )<U>(define/system/exec mx_global_alias_database mx_dir:mx_global_alias.dat)
<ENDINTERACTIVE>

<P>
You will also need to add the DEFINE command to your system startup.


<head2>(VMS MAIL Protocol Prefix\prtclpref)
<p>MX by default uses the foreign protocol prefix MX% when
<x>(VMS MAIL<xs>foreign protocol)
<x>(VMS MAIL<xs>protocol prefix)
interfacing with VMS Mail.  You can define alternate foreign protocol prefixes
for use with MX, to provide a migration path for users from other mail systems
to MX.  MX will correctly handle the following prefixes: SMTP%, WINS%, IN%,
IHMF%, VN%,
ST%, INET%,
and UUCP%.
To set up one of these alternate prefixes
in VMS Mail, define the logical name MAIL$PROTOCOL_prefix:
<x>(Logical names<xs>MAIL$PROTOCOL_prefix)
<interactive>
<s>($ )<U>(DEFINE/SYSTEM/EXEC MAIL$PROTOCOL_prefix MX_MAILSHR)
<endinteractive>
<cp>where <keyword>(prefix) is one of the above-mentioned prefixes, without
the trailing percent sign.
<p>Note that incoming mail from MX will always bear the MX% prefix.

If you wish to use another prefix for incoming mail, you can define
the logical name MX_PROTOCOL_PREFIX:

<x>(Logical names<xs>MX_PROTOCOL_PREFIX)
<INTERACTIVE>
<s>($ )<U>(DEFINE/SYSTEM/EXEC MX_PROTOCOL_PREFIX prefix%)
<endinteractive>
<CP>
where <KEYWORD>(prefix) is one of the above-mentioned prefixes, with
the trailing percent sign.  The default prefix MX% is the recommended
prefix.


<head2>(Default Host Names\defhostnames)
<p>By 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 address.
For sites that require more control over how addresses are
formatted, additional logical names may be defined.
<P>
These logical names are not automatically defined by MX;
you must define them yourself (e.g., in your system startup
procedure).  The must be defined in executive mode, but
may reside in the process, job, group, or system logical
name table.  The logical names and their descriptions are
in <reference>(hostlognamtab).
<TABLE>(Address Formatting Logical Names\hostlognamtab)
<table_setup>(2\15)
<table_heads>(Logical name\Description)
<x>(Logical names<xs>MX_ENVELOPE_FROM_HOST)
<TABLE_ROW>(MX_ENVELOPE_FROM_HOST\Host name to be used
when formatting envelope return addresses (equivalent
to the RFC821 MAIL FROM).)
<x>(Logical names<xs>MX_FROM_HOST)
<TABLE_ROW>(MX_FROM_HOST\Host name to be used
when formatting the From: header.)
<x>(Logical names<xs>MX_FROM_HOST)
<TABLE_ROW>(MX_TO_HOST\Host name to be used
when on a To: or Cc: address.)
<ENDTABLE>
<P>
You can also affect address formatting by installing
a SITE address conversion callout.  See the
<reference>(progguide) for more information on
address conversion callouts.

<head2>(Character Set Conversion\cconv)
<P>MX_MAILSHR performs character conversion of the sender's VMS MAIL
personal name and the VMS MAIL Subject: line from the local, native
character set to an Internet standard character set for mail messages.
The message body is similarly converted (by the Router agent).
<P>
<x>(character set)
By default, MX assumes that the local character set is ISO Latin-1
(ISO-8859-1), a widely used international standard.  If you use the DEC
Multinational Character Set (DEC-MCS), and cannot configure your
terminals to use ISO Latin-1 instead, MX can automatically translate
between DEC-MCS and ISO Latin-1 for you.  You can activate this
translation support by defining the following logical name
logical name:
<x>(Logical names<xs>MX_LOCAL_CHARSET_DEC_MCS)
<INTERACTIVE>
<s>($ )<U>(DEFINE/SYSTEM/EXEC MX_LOCAL_CHARSET_DEC_MCS any-value)
<endinteractive>
<CP>
The value of the equivalence string is unimportant; the existence of
this logical name will identify the local character set as DEC MCS.
Note that there is not a 1-to-1 mapping of all of the 8-bit characters
in these two character sets.
<P>
If you use any other character set on the local system, or you wish
to use a different network character set, you must install a custom character
conversion callout module.  See <reference>(progguide) for further
information about this customization.

<head1>(SMTP_SERVER\smtpsvopt)
<P>This section describes the logical names used to configured
the SMTP server.
<HEAD2>(SMTP Server Threads\smtpsvthrd)
<p>The SMTP server is a detached, multi-threaded process.  You can specify
how many threads the server should handle simultaneously by defining
<x>(Logical names<xs>MX_SMTP_SERVER_THREADS)
a logical name:
<interactive>
<s>($ )<U>(DEFINE/SYSTEM/EXEC MX_SMTP_SERVER_THREADS n)
<endinteractive>
<p>The value of <emphasis>(n) should range from 1 to 32.  The default is
4.  The SMTP server may require larger process quotas/limits if more than
four threads are allowed.
<P>You can set the number of threads used by the SMTP server
permanently by configuring this setting through the MXCONFIG.COM
procedure.

<HEAD2>(Limiting <QUOTE>(Outside) Thread Usage\smtpoutside)
<P>If you have configured local IP networks (see <REFERENCE>(inside_networks)),
the MX SMTP server will limit the number of threads it uses to
service clients sending messages from <quote>(outside) networks.
This feature helps prevent local POP client users from getting
get locked out of sending messages when there is heavy message
traffic coming in from outside your network.
<P>By default, the SMTP server limits the number of <quote>(outside)
clients it will service at one time to 75% of the total number of
threads configured.  You may override this default by defining
the following
<x>(Logical names<xs>MX_SMTP_SERVER_MAX_OUTSIDE)
logical name:
<interactive>
<s>($ )<U>(DEFINE/SYSTEM/EXEC MX_SMTP_SERVER_MAX_OUTSIDE n)
<endinteractive>
<CP>where <EMPHASIS>(n) represents the maximum number of threads that
the server may use to service <quote>(outside) clients.  This number
should range from 1 to the maximum number of configured threads.

<HEAD2>(Setting the SMTP Listener Port\smtpsvport)
<P>By default, the SMTP server listens for incoming TCP connections on the
default SMTP port (25).  You can change this by defining the following
<x>(Logical names<xs>MX_SMTP_PORT)
logical name:
<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_SMTP_PORT port-number)
<ENDINTERACTIVE>
<CP>This should only be necessary for unusual configurations, such as
having multiple SMTP servers running simultaneously on one system.

<head1>(DECNET_SMTP Network Object\dnsmtpsvopt)
<p>You must create a DECnet object called DECSMTP for establishing
SMTP-over-DECnet connections.  To do this, either use your mailer account
or create a dedicated server account for use with the DECnet object (a
dedicated server account is recommended).
Using the AUTHORIZE utility, set a password for the this account and set
the account /NOPWDLIFETIME.  Also be sure the account has network access
enabled.
<interactive>
<s>(UAF> )<u>(MODIFY <emphasis>(account)/PASSWORD=<emphasis>(some-password)/NOPWDLIFETIME/network)
<endinteractive>
<p>
A DECnet object needs to be created to handle the incoming SMTP-over-DECnet
connections and to map the DECSMTP object name to a DECnet object number.
Choose an unused DECnet object number.  To see what object numbers
are currently in use, use the command:
<interactive>
<s>($ )<u>(MCR NCP SHOW KNOWN OBJECT)
<endinteractive>
<p>
Assign the object name DECSMTP to an unused object number; the number used
<emphasis>(must) be identical on all nodes on your network that use
SMTP-over-DECnet (this example uses 254).  In NCP, use these commands:
<INTERACTIVE>
<S>(NCP> )<U>(PURGE OBJECT DECSMTP ALL)
<s>(NCP> )<u>(DEFINE OBJECT DECSMTP NUMBER 254 PROXY NONE FILE -)
<s>(_NCP> )<u>(   MX_EXE:DNSMTP_SERVER.EXE USER <emphasis>(server-acct) PASSWORD <emphasis>(some-password))
<S>(NCP> )<U>(SET OBJECT DECSMTP ALL)
<ENDINTERACTIVE>
<p>You do not need to specify the FILE, USER, or PASSWORD parameters if
you do not intend to accept incoming SMTP connections over DECnet.
Be sure to use both the DEFINE and SET commands of NCP, and be sure that
the password in the DECnet database matches the password you set for the
server account in AUTHORIZE.
<subhead1>(Using Proxies\usinprox)
<p>Instead of storing the username and password for the server account in
the DECnet database, you could grant access using DECnet proxies.  Proxies
give you more control over who on the network has access to the object, and
eliminate the need for storing the password to the server account in the
DECnet object database.
<p>To enable proxy access to the DECSMTP object, use the following commands
in NCP:
<INTERACTIVE>
<S>(NCP> )<U>(PURGE OBJECT DECSMTP ALL)
<s>(NCP> )<u>(DEFINE OBJECT DECSMTP NUMBER 254 PROXY INCOMING FILE -)
<s>(_NCP> )<u>(   MX_EXE:DNSMTP_SERVER.EXE)
<S>(NCP> )<U>(SET OBJECT DECSMTP ALL)
<ENDINTERACTIVE>
<p>Then 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:
<interactive>
<s>(UAF> )<u>(ADD/PROXY <emphasis>(remote::mailer) <emphasis>(server-acct)/DEFAULT)
<endinteractive>
<p>For <keyword>(remote::mailer) substitute the DECnet node of the remote system
and the username of the mailer account on that system.  For 
<keyword>(server-acct) substitute the name of the server account you set up
for use with the DECnet-SMTP object.

<head1>(Message Entry Agent Shutdowns\MGMT_GUIDE_49)
<p>The two message entry mechanisms that do not get shut down with the
rest 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 deactivated by
de-installing the MX_MAILSHR image:
<interactive>
<s>($ )<u>(INSTALL REMOVE MX_MAILSHR)
<endinteractive>
<p>The SMTP-over-DECnet server gets shut down automatically when you shut down
DECnet, or can be manually removed by eliminating the DECSMTP object from the
DECnet database:
<interactive>
<s>($ )<u>(MCR NCP CLEAR OBJECT DECSMTP ALL)
<endinteractive>


<CHAPTER>(Managing the Message Queue\qutil)
<P>
This chapter describes the various commands needed to control how the message
queue operates.


<HEAD1>(Establishing the Queue Size\qsizeset)
<P>
The maximum number of queue entries that can be present in the MX
message queue at any one time is determined by the size, in blocks, of
the MX message queue file.  Each entry in the queue requires one
block, with 10 additional blocks used to store a bitmap of entries in
use. This means, for example, that a queue file that is 510 blocks in
size will allow 500 entries to be present in the queue.  The upper
ceiling on the maximum entries is 131,072.

<P>
Most sites that process several thousand mail messages a day can
probably work well with a queue file of about 5,000 blocks.  If you
are not short on disk space, creating a

131,072-block

file will eliminate the need to ever modify the queue file size.

<HEAD1>(Running the MX FLQ Manager\qflqmgrproc)
<P>
As 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.

<P>
You have the option of running a separate MX FLQ
Manager process, whose sole job is to purge the queue of finished
entries and cancel or ready any in-progress entries leftover from
system crashes, disconnected processes, etc.  Running a separate FLQ
manager frees the MX Router to route messages, instead of splitting
its time between routing and maintaining the queue.  This means that
the MX Router has more time for routing messages and queue maintenance
isn't delayed while the MX Router is routing.

<P>
While the MX FLQ Manager can be run on multiple nodes in a cluster,
only one manager is ever actively maintaining the queue.  Running the
manager on multiple nodes can provide failover backup in case of a
node crash, 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.

<P>
Sites that do not process many messages per day will probably not
benefit from running the MX FLQ Manager process.


<head1>(Queue Cleanup Logicals\qclnlognams)
<p>The Router process

(or the MX FLQ Manager process)

automatically handles cleanup of the message
queue.  The time between cleanup events can be controlled with logical
names, as described in <reference>(flqlnm).

<table>(FLQ Manager/Router queue-related logicals\flqlnm)
<table_setup>(3\18\7)
<table_heads>(Logical\Default value\Description)

<x>(Logical names<xs>MX_FLQ_MGR_WAKEUP_INTERVAL)
<TABLE_ROW>(MX_FLQ_MGR_WAKEUP_INTERVAL\2 min.\Amount of time FLQ
Manager sleeps before checking for entries to purge)
<x>(Logical names<xs>MX_ROUTER_WAKEUP_INTERVAL)
<TABLE_ROW>(MX_ROUTER_WAKEUP_INTERVAL\10 min.\Amount of time MX Router
sleeps before checking for entries to purge)

<x>(Logical names<xs>MX_FLQ_CHECK_WAIT)
<table_row>(MX_FLQ_CHECK_WAIT\10 min.\Amount of time between checks for other
queue-related events)
<x>(Logical names<xs>MX_FLQ_PURGE_WAIT)
<table_row>(MX_FLQ_PURGE_WAIT\15 min.\Amount of time a queue entry should
remain in queue after it has been processed)
<endtable>

<P>
To alter one of these values, use the DEFINE command to set the
logical to a new time (using VMS delta-time format) and send a reset
signal to the Router

and/or FLQ Manager processes:

<interactive>
<s>($ )<u>(DEFINE/SYSTEM MX_FLQ_PURGE_WAIT "0 00:10:00")
<s>($ )<u>(MCP RESET ROUTER,FLQ)
<endinteractive>


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

<P>
If you want this change to be permanent and survive a system reboot,
you should add this logical name definition to your system startup
procedure before MX is started.


<HEAD1>(Automatic Purging of Finished Queue Entries\MGMT_GUIDE_AUTOPURGE)
<P>
Finished queue entries are left in the queue for 15 minutes, by
default, before they are purged.  It is not necessary to leave the
entries in the queue once they have been marked <QUOTE>(FINished.)  If you
prefer to not leave them around, you can enable automatic purging of
FIN entries and their related files.  Use the MXCONFIG.COM command
procedure, option 1, to configure the message queue logical names.
<P>
Even when autopurging is enabled, it is still necessary for the MX FLQ
Manager or MX Router process to occasionally scan the queue for
CANCELed entries.  However, a dedicated MX FLQ Manager process is not
as beneficial as it is when autopurging is not enabled.


<head1>(The MCP QUEUE Commands\MGMT_GUIDE_51)
<P>MCP includes a suite of commands for queue
management to be used by privileged users.  These commands are documented in
the MCP command dictionary.


<head2>(Interpreting MCP QUEUE SHOW Output\MGMT_GUIDE_52)
<p>When there are messages in the queue, MCP QUEUE SHOW displays the following
information about each entry:
<interactive>
Entry Status EntSize Source  Agent  Entry Status EntSize
----- ------ ------- ------ ------- ----- ------ -------
 2980 INPROG     229 LOCAL  <usr01@myhost.mycompany.com>
                            SMTP     2981 READY      229
                                    (waiting until 15-NOV-1991 15:07:21.75)
10859 READY   65120 LOCAL  <FileServ-Mgr@myhost.mycompany.com>
      (Waiting until 15-NOV-1991 18:00:00.00)
<endinteractive>
<p>The fields of the display contain the following information:
<x>(Queue status)
<list>(unnumbered)
<le>The first <emphasis>(Entry\bold) field is the queue entry number for the
base message, which can range from 1 to 131,071.

<le>The first <emphasis>(Status\bold) field describes the status of
the base message and can be one of INPROG,
READY, FINISH, or CANCLD.
<list>(unnumbered)
<le>INPROG stands for <quote>(in progress) and is used when the base
entry is being processed by the Router, or when one of its related
entries is ready or in progress.
<le>READY is used when the base entry is ready for processing by the Router.
<le>FINISH indicates that processing of
the base entry has completed.  Finished entries remain in the queue for
a short time before being removed (see <reference>(flqlnm)).  They
are not normally displayed; the /ALL qualifier on the MCP QUEUE SHOW
command can be used to force the display of these entries.
<le>CANCLD indicates that processing
of the entry is terminated before completion, such as when CTRL/C
is pressed during entry of a message in VMS MAIL.  Cancelled entries
also remain in the queue for a short time before removal, and are only
displayed when MCP QUEUE SHOW/ALL is used.
<endlist>
<le>The <emphasis>(EntSize\bold) field displays the total size of the message entry.
The size is calculated as the total number of bytes in the body of
the message multiplied by the number of intended recipients of the
message.  Headers are not counted when computing the size of the message.
<LE>The <emphasis>(Source\bold) field describes the origin of the
base message.  It can have the value LOCAL, SMTP, DNSMTP (for
SMTP-over-DECnet), SITE, or MAIL.

To the right of the source
display is the address of the user who originated the message.
<ENDLIST>
<p>If a message is being processed by one of the MX delivery agents,
the base queue entry will be immediately followed by indented entries
that begin with the <emphasis>(Agent\bold) field.
The <emphasis>(Agent\bold) field identifies the delivery agent that
is working on the entry.  Possible values are LOCAL,
SMTP, SITE, HOLD<emphasis>(n), and DNSMTP (for SMTP-over-DECnet).
<p>The second <emphasis>(Entry\bold), <emphasis>(Status\bold), and
<emphasis>(Size\bold) fields provide information about the
queue entry used by the delivery agent.  This agent-specific entry
refers back to the base entry for the message headers and text, and
the base entry has pointers to the agent-specific entries related to it.
When an agent-specific entry is finished, the reference to it in the
base entry is removed; when no agent-specific entries are left, the
base entry is marked FINISHED.

<HEAD2>(Forcing a Message to <QUOTE>(Bounce)\forced_bounce)
<P>
Occasionally, messages that can never be delivered will remain
queued for multiple delivery attempts.  When this occurs, you can
force the message to be <quote>(bounced) back to the sender by 
using the command QUEUE READY/FINAL.  This causes the delivery agent
to make one final attempt to deliver a message; when that fails,
it will be returned to sender.
<P>For example, to force a  final delivery attempt of the SMTP
entry shown in <REFERENCE>(MGMT_GUIDE_52), you would enter:
<INTERACTIVE>
<S>(MCP> )<U>(QUEUE READY/FINAL 2981)
<ENDINTERACTIVE>

<HEAD2>(Interpreting MCP QUEUE STATISTICS Output\MGMT_GUIDE_QUESTAT)
<P>
The MCP command QUEUE STATISTICS displays the following entry
statistics:


<INTERACTIVE>
<S>(MCP> )<U>(QUEUE STATISTICS)
<S>(Total entries: 16/502  (3%)   Highest entry used: 24  (4%))
<S>(MCP> )
<ENDINTERACTIVE>


<P>
The first number after <QUOTE>(Total entries:) is the current number of
entries in the queue.  The second number is the maximum number of
entries allowed by the queue file size.  The percentage of entries
used is also shown.

<P>
The <QUOTE>(Highest entry used:) is the largest entry number ever used
during the life of the queue file.

The percentage of the queue in
use at that time is also shown.

This value can be used to
determine whether or not the selected queue file size is sufficiently
large.  The MCP command QUEUE EXTEND can be used to increase the size
of the queue file.


<CHAPTER>(Configuring MX for Part-Time Internet Connections\dialupchap)
<P>This chapter describes how to configure MX to use <newterm>(holding queues)
for messages that get delivered over a TCP/IP network path that is not
available all the time.
<HEAD1>(Environment for Part-Time Connections\dialupsys)
<P>
MX supports a messaging environment consisting of:
<LIST>(unnumbered)
<LE>A <newterm>(server) system, located at a main office or
Internet Service Provider, that has a permanent TCP/IP connection; and
<LE>one or more <newterm>(client) systems, located at remote offices,
which periodically connect to the server system to pick up and deliver
mail.
<ENDLIST>
<P>
MX can act as either a client or server system; when configured as
as a server, MX can service up to 32 clients with part-time network
links.
The client systems <emphasis>(must) have static IP addresses assigned
to their domain names, or there must be an automatic assignment in the
DNS between each client's domain name and its dynamic IP address.

<HEAD1>(Configuring MX as a Part-Time Client\clientdialup)
<P>
To configure MX as a part-time client, use MCP to configure the delivery
path to the server:
<INTERACTIVE>
<S>(MCP> )<U>(DEFINE PATH * HOLDING_QUEUE=1/ROUTE=server-name)
<ENDINTERACTIVE>
<CP>
If you have already used MXCONFIG.COM to create your MX configuration
database, you may need to use the MODIFY PATH command to configure
this path change.
<P>This path configuration causes MX to hold all messages that are
not delivered through other, more specific, paths.
<P>If your client system creates the network path to the server,
you should execute the following command to start the holding queue agent
when the path is established:
<INTERACTIVE>
<S>($ )<U>(@SYS$STARTUP:MX_STARTUP HOLD1)
<ENDINTERACTIVE>
<CP>
The agent will then attempt to deliver all messages in the holding queue
to the server.  You may also use this command if the server system creates
the dial-up connection, but this may not be necessary if the server system
supports the SMTP ETRN extension (documented in Internet RFC 1985).  The
MX SMTP server supports ETRN and can automatically start the holding queue
agent when requested to do so by the server.

<HEAD1>(Configuring MX as a Server for Part-Time Clients\serverdialup)
<P>
The configuration for MX as a server also uses holding queues, but
defines paths for the specific host(s) or domain(s) at the client site:
<INTERACTIVE>(WIDE)
<S>(MCP> )<U>(DEFINE PATH client.host.name HOLDING_QUEUE=n/ROUTE=client.host.name)
<S>(MCP> )<U>(DEFINE PATH client.domain HOLDING_QUEUE=n/ROUTE=client.host.name)
<ENDINTERACTIVE>
<CP>
The value of <emphasis>(n) can be 1 through 32, representing one of the 32
available holding queues.  If the name defined in the DEFINE PATH command does
not match the client's actual Internet host name, you <emphasis>(must) specify
the /ROUTE qualifier to set the host name to which messages will be delivered.
In addition, all /ROUTE values for a single holding queue <emphasis>(must) be
identical.
<P>
To start the delivery agent for one of the holding queues, use the command:
<INTERACTIVE>
<S>($ )<U>(@SYS$STARTUP:MX_STARTUP HOLD<emphasis>(n))
<ENDINTERACTIVE>
<CP>where <emphasis>(n) is the number 1 through 32, representing the number
of the holding queue for a particular client system.  If a client system
is also running MX, and is configured to start its holding queue agent
when the network path is established, the ETRN support in the MX
SMTP server will be used to automatically start the holding queue agent
for their system.
<HEAD1>(ETRN Support\etrnsupport)
<P>
When both the client and the server systems run MX or another mailer that
supports the RFC 1985 ETRN extension to SMTP, only one of the two systems has to
be set up to start its delivery agent when the dial-up connection is active;
the SMTP ETRN command will cause the other system to start delivering messages
in the opposite direction.
<P>A parameter is sent on the ETRN command; this parameter can identify the
host or domain for which messages should be delivered, or it can be a special
<quote>(queue name,) a private identifier used by the client and server systems
to identify the holding queue agent that should be started.  By default, MX
holding queue agents will send the following ETRN commands:
<INTERACTIVE>
<U>(ETRN mx-host-name)
<U>(ETRN #ip-host-name)
<ENDINTERACTIVE>
<P>Where <emphasis>(mx-host-name) is the value of the logical name MX_NODE_NAME, and
<emphasis>(ip-host-name) is the local system's TCP/IP host name (either from the logical
name MX_INET_HOST, or from your TCP/IP package's configured host name).  In the second
case, the pound sign (<quote>(#)) indicates that <emphasis>(ip-host-name) is a queue
identifier.
<P>
If the system at the other end of the connection is running MX, and has PATH definitions
with /ROUTE qualifiers that specify the same host name as the <emphasis>(ip-host-name)
appearing in the ETRN command, then the remote system will automatically start the
appropriate holding queue agent for that system.  The holding queue agent will also
be started if the <EMPHASIS>(mx-host-name) appearing in the first ETRN command matches
one of PATH definitions.
<P>You can override the default ETRN behavior for a particular holding queue agent
with the following logical names:
<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_HOLD<emphasis>(n)_REQUEST_DELIVERY FALSE)
<ENDINTERACTIVE>
<CP>This logical name prevents the holding queue agent from sending any ETRN commands
at all; use this when the remote system does not support ETRN or if you need to
control the holding queue agents manually at both ends of the connection.
<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_HOLD<emphasis>(n)_HOST_NAME "name"[,...])
<ENDINTERACTIVE>
<CP>This logical names overrides the parameters sent on the ETRN command.
Multiple <emphasis>(name)s may be specified; enclose each in quotation marks,
and separate them with commas.  The value of each <emphasis>(name) is passed
to the remote system exactly as entered; you may use the <quote>(@) or
<quote>(#) prefix character to specify a domain name or a queue identifier
(see RFC 1985 for more information).  Use this logical name when the remote
system supports ETRN but is <emphasis>(not) 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.
<HEAD1>(Example Configuration\dialupexample)
<P>
This example shows the commands used to configure a client servicing the
domain <quote>(mxclient.com), with host name <quote>(mailer.mxclient.com),
and a server with the host name <quote>(mailhub.mxserver.com).
<P>
Client configuration:
<INTERACTIVE>(WIDE)
<S>(MCP> )<U>(DEFINE PATH <quote>(mxclient.com) LOCAL)
<S>(MCP> )<U>(DEFINE PATH <quote>(mailer.mxclient.com) LOCAL)
<S>(MCP> )<U>(DEFINE PATH * HOLDING_QUEUE=1/ROUTE=<Quote>(mailhub.mxserver.com))
<ENDINTERACTIVE>
<P>
Server configuration:
<INTERACTIVE>(WIDE)
<S>(MCP> )<U>(DEFINE PATH <quote>(mxserver.com) LOCAL)
<S>(MCP> )<U>(DEFINE PATH <quote>(mailhub.mxserver.com) LOCAL)
<S>(MCP> )<U>(DEFINE PATH <quote>(mxclient.com) HOLDING_QUEUE=1/ROUTE=<quote>(mailer.mxclient.com))
<S>(MCP> )<U>(DEFINE PATH <quote>(mailer.mxclient.com) HOLDING_QUEUE=1/ROUTE=<quote>(mailer.mxclient.com))
<S>(MCP> )<U>(DEFINE PATH * SMTP)
<ENDINTERACTIVE>

<chapter>(Reducing or Eliminating <quote>(Junk) E-Mail\junkmailchap)
<p>This chapter describes the facilities in MX for preventing
unwanted <quote>(junk) e-mail messages (also called <quote>(spam))
from being processed.
<HEAD1>(What is <quote>(junk) E-Mail?\whatisspam)
<P>The Internet has grown explosively since its humble beginnings
as a tool for researchers wishing to exchange information.  The
designers of the early Internet electronic mail systems and
standards kept SMTP simple (in fact, the S in SMTP stands for
<quote>(Simple)), operating under the assumption that Internet
users were, for the most part, well-behaved.
<P>Due to the explosive growth, there are now many more people
using the Internet that are not well-behaved, exploiting the
openness of SMTP and the low cost
of generating immense e-mail distribution lists either to annoy
or to send unsolicited advertisements to the huge number of
people who currently use Internet e-mail.
<P>This use of e-mail, while costing almost nothing to the sender,
can place a heavy burden -- in terms of network and system
resources -- on the sites that receive these unsolicited
messages.  System managers wishing to reduce the number of
unwanted <quote>(junk) messages can configure MX to block
them from being received locally as well as prevent their
systems from being used as a <quote>(relay) point, sometimes
employed by unscrupulous <quote>(spammers) that have had
their own systems blocked from direct delivery by other sites.
<P>You can get more information about junk e-mail on the
World Wide Web from <emphasis>(http://spam.abuse.net/spam).

<HEAD1>(MX Filtering Features\mxfilters)
<P>
MX contains several features to help curb junk e-mail:
<LIST>(UNNUMBERED)
<LE>The MCP command SET SMTP/VALIDATE_SENDER_DOMAIN, which
causes the SMTP server to validate the sender's domain
name on incoming messages;
<LE>The MCP command SET SMTP/NORELAY, which rejects mail
that does not originate at your site and is not destined
for your site;
<LE>The REJMAN utility, which manages a database of rejection
criteria that you can populate with address and header patterns
that have been used by spammers.
<LE>Heuristic junk mail filters, also managed through the
REJMAN utility, which filter potential junk mail based on
the characteristics and/or contents of message headers in
various combinations.
<ENDLIST>
<HEAD1>(Sender Validation\sendervalidate)
<P>
Spammers often hide their identity by using a false return
address on their messages.  In many cases, the return address
contains a domain name that does not actually exist in
the Domain Name System (DNS).  You can have the SMTP server
validate the domain name appearing in SMTP MAIL FROM commands
(which specify the return address for SMTP messages) to ensure
that it exists in the DNS with the following MCP command:
<INTERACTIVE>
<S>(MCP> )<U>(SET SMTP/VALIDATE_SENDER_DOMAIN)
<ENDINTERACTIVE>
<P>
This feature should only be enabled if you use the Internet and
the Domain Name System.  You should also ensure that all of your
legitimate users that might send mail via SMTP to your system (such as
PC users with POP mail clients) have their systems properly configured
to send valid domain names as part of their return addresses.
<P>
Reliable DNS service is also helpful when enabling this feature; if
the SMTP server cannot resolve a domain name due to communication
problems with the DNS server, the validity check is <emphasis>(not)
performed.

<HEAD1>(Disabling the SMTP Relay Function\disablingrelay)
<P>
In some cases, junk e-mail senders who are unsuccessful in
getting messages delivered directly from their own systems,
or who wish to obscure the source of the junk messages, take
advantage of the <quote>(relay) function available in most
SMTP servers.  By default, most SMTP servers accept messages
coming from any source and will attempt to deliver those
messages to any destination, even if both the source of the
message and its intended recipients are remote.  This
is called <emphasis>(relaying).  The MX SMTP server allows
relaying by default; you can disable the relay function
if you wish to prevent your system from being used as
a relay point for junk e-mail:
<INTERACTIVE>
<S>(MCP> )<U>(SET SMTP/NORELAY_ALLOWED)
<ENDINTERACTIVE>
<P>Once relaying is disabled, the SMTP server checks
the envelope FROM address (also called the Return-Path)
of each incoming message to see if it is
local or remote.  It also checks each recipient address.
If the envelope FROM address is remote and a recipient
address is remote, delivery to the remote recipient is
refused by the server.
<P>The SMTP server uses the following tests to determine
whether or not an envelope address (either FROM or
recipient) is local or remote:
<LIST>(numbered)
<LE>The host name in the address is compared against the
MX host name.  If both names are the same, or if the
address being checked is the envelope FROM address
and both hosts share the same parent domain, the address is
considered local.
<LE>If the previous check did not classify the address
as local, it is repeated using the TCP/IP host name.
<LE>The virtual domain address rewriter is called,
if present, to see if the host name is on the virtual domain
list.
<LE>If none of the above checks passes, the address is passed
through the message routing rules (rewrite rules and path checks).
If the resulting path is LOCAL, the address is considered local.
<LE>If none of the above checks classified the address
as local, the host name is compared against the
<emphasis>(local domains) list, which you configure
with the DEFINE LOCAL_DOMAIN command.
<ENDLIST>
<P>
You may need to use the DEFINE LOCAL_DOMAIN command
if your host acts as a mail gateway for other systems.  For example,
if your system is part of the domain <emphasis>(mycompany.com)
but also acts as a gateway for the domain <emphasis>(theircompany.com),
you would define the following local domains:
<INTERACTIVE>
<S>(MCP> )<U>(DEFINE LOCAL_DOMAIN theircompany.com)
<S>(MCP> )<U>(DEFINE LOCAL_DOMAIN *.theircompany.com)
<ENDINTERACTIVE>
<P>These commands will cause the SMTP server to treat any
address of the form <emphasis>(user@)<emphasis>(theircompany.com\bold)
or <emphasis>(user@somehost.)<emphasis>(theircompany.com\bold) as
being <quote>(local) for the purposes of relay-rejection testing.

<HEAD2>(Identifying Inside Networks and Hosts\inside_networks)
<P>You can further strengthen the anti-relay checks by using
the DEFINE INSIDE_NETWORK_ADDRESS command to create
a list of IP network and/or host addresses that are considered
to be <quote>(inside) your local network.  Creating this list
prevents an outside system from using your system 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).
<P>
If your system is acting as a relay between other hosts on your
network(s) and the Internet, or you have POP or IMAP mail clients
that send their messages through your system,
you should add your network(s) to the list.  For example, if
your local network is 10.10.10.0, set up with a 24-bit subnetwork
mask, you would specify
<INTERACTIVE>
<S>(MCP> )<U>(DEFINE INSIDE_NETWORK_ADDRESS 10.10.10.0/NETMASK=255.255.255.0)
<ENDINTERACTIVE>
<CP>Any SMTP connection coming from a system on the 10.10.10.0 network
would be allowed to specify a local domain in the SMTP MAIL FROM
command in combination with a list of recipients that are outside
your domain; all other systems would be considered <quote>(outside),
and would be unable to specify a list of outside recipients even when
sepcifying a local domain in the SMTP MAIL FROM.
<P>If there were another mailer for your network (such as another
system in the Domain Name System list of mail exchanger [MX] records for
your domain) at the address 10.10.20.37, you would also specify
<INTERACTIVE>
<S>(MCP> )<U>(DEFINE INSIDE_NETWORK_ADDRESS 10.10.20.37)
<ENDINTERACTIVE>
<CP>By omitting the /NETMASK qualifier, the address is assumed to
be a host rather than a network.
<P>If your system is the only mailer for your domain, and you
do not have any POP or IMAP mail clients, you should specify
<INTERACTIVE>
<S>(MCP> )<U>(DEFINE INSIDE_NETWORK_ADDRESS 127.0.0.1)
<ENDINTERACTIVE>
<CP>to enable the inside-address checks and prevent any other system
from using a local e-mail address in the SMTP MAIL FROM in order
to relay to outside hosts.

<P>The DEFINE INSIDE_NETWORK_ADDRESS command has a /REJECT qualifier
that allows you to set up specific exceptions to the list for
individual hosts 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 <quote>(inside), you could specify
<INTERACTIVE>
<S>(MCP> )<U>(DEFINE INSIDE_NETWORK_ADDRESS 10.10.10.100 /REJECT)
<ENDINTERACTIVE>
<CP>to eliminate that host from the <quote>(inside) list.
<P>Note that the list of addresses is kept in order based on the
length of the network mask, from longest (host addresses) to
shortest.  The list is search sequentially from the beginning
for a match against the sending host's IP address.

<HEAD2>(Disabling the <QUOTE>(Percent Hack)\disablepcthack)
<P>
To fully secure your SMTP server against relaying, you should
also ensure that the MX Router has the percent-hack feature
disabled:
<INTERACTIVE>
<S>(MCP> )<U>(SET ROUTER/NOPERCENT_HACK)
<ENDINTERACTIVE>
<CP>
This will protect your system from being used as a relay when
presented with a local address that include a percent-sign in
the username (a technique used for routing e-mail in the early
days of the Internet).
<P>
To prevent your system from accepting <EMPHASIS>(any) percent-hacked
address, regardless of whether or not the domain-part of the address
is local, use:
<INTERACTIVE>
<S>(MCP> )<U>(SET SMTP/NOPERCENT_HACK)
<ENDINTERACTIVE>
<CP>
With this setting, your system will refuse all percent-hacked
addresses.  This setting is necessary when your system accepts
messages from outside sources and forwards them to other mailers
that do not reject percent-hacked addresses.

<P>
Only combining all of the steps in this section can you ensure
that your SMTP server is fully secured against relay attacks
from junk mail senders.

<HEAD1>(Realtime Blackhole List\rblsection)
<P>Several organizations maintain lists of known junk mail
abusers and open relays, called Realtime Blackhole Lists (RBLs).
These lists are typically made available through the Domain Name
System so that SMTP servers can easily screen out messages coming
from systems known to be sources or relay points for junk e-mail.
<P>You can configure
MX to perform an RBL domain name system check for every
host connecting to the SMTP server.  If the connecting host is
found in the RBL, the SMTP server will refuse any message it
tries to send.
<P>Use the following MCP command to enable RBL checking:
<INTERACTIVE>
<S>(MCP> )<U>(SET SMTP/RBL_CHECK=(rbl-domain,...))
<ENDINTERACTIVE>
<P>
RBL checking is disabled by default.  Consult your RBL
provider for information on the DNS domain or domains it
uses for its black-hole lists.
You can configure the SMTP server to check multiple RBLs by
specifying a comma-separated list of RBL domains.

<HEAD1>(Establishing Rejection Criteria with REJMAN\rejmansection)
<P>The REJMAN utility lets you create and manage a database
containing criteria by which MX's SMTP server will reject
incoming messages as junk e-mail that you do not want to
be processed.  See <REFERENCE>(REJMAN_cmd) for information on
how to invoke this utility.
<P>REJMAN provides commands for rejecting messages based on
envelope contents (combinations of return address, recipient
address, and the TCP/IP address of the sending host) as
well as on headers contained in the message.

<HEAD2>(Address-Based Rejections\spamfilter)
<P>
The REJMAN ADD REJECTION command can be used to configure
the SMTP server to reject incoming messages with specific
return addresses or matching specified patterns, or being
sent from particular hosts.  Messages matching the rejection
criteria are refused by the SMTP server before the message
contents are sent -- reducing network load as well
as the processing load on your system.
<P>If your users are being bombarded with unwanted e-mail,
review the unwanted messages for the Return-Path: header
and the Received: headers (you should ensure that your
SET LOCAL settings do not prevent those headers from being
included in delivered messages).  You can program a rejection
rule into the SMTP server based on the Return-Path with:
<INTERACTIVE>
<S>(REJMAN> )<U>(ADD REJECTION sender-address)
<ENDINTERACTIVE>
<P>For example, if some junk e-mail had a Return-Path address
of <emphasis>(<spammer@spamhost.com>), you would use the
command:
<INTERACTIVE>
<S>(REJMAN> )<U>(ADD REJECTION "spammer@spamhost.com")
<ENDINTERACTIVE>
<P>If the Return-Path has different usernames, but the
same host name, you could use a wildcard pattern:
<INTERACTIVE>
<S>(REJMAN> )<U>(ADD REJECTION "*@spamhost.com")
<ENDINTERACTIVE>
<P>to reject all messages coming from <emphasis>(spamhost.com).
<P>If a large number of junk messages were all sent to your
host from another single host or network, they would all have
Received: headers that follow this pattern:
<INTERACTIVE>(WIDE)
Received: from <emphasis>(spam-source.com) by <emphasis>(yourhost.com) with SMTP...
<ENDINTERACTIVE>
<P>You can block incoming messages sent by a particular host or on hosts
from a particular network using the /ADDRESS qualifier on the
DEFINE REJECTION command.  For example, if <emphasis>(spam-source.com) has
an IP address of 10.0.0.1, you could use the command
<INTERACTIVE>
<S>(REJMAN> )<U>(ADD REJECTION "*@*"/ADDRESS=10.0.0.1)
<ENDINTERACTIVE>
<P>to have the SMTP server refuse all messages that were sent or
relayed through that particular host.  You must know the IP address
of the host in order to use the /ADDRESS qualifier.  Address specifications
may also contain wildcards so you can block entire networks.
<P>
Once you have added one or more rejection rules to the database,
you must use MCP to reset the SMTP server to have the new rules take effect:
<INTERACTIVE>
<S>(MCP> )<U>(RESET SMTP_SERVER)
<ENDINTERACTIVE>
<NOTE>
Exercise caution when establishing rejection rules.  An incorrect
rule could block legitimate messages from reaching their intended
destinations.
<ENDNOTE>
<P>The ADD REJECTION command has more options for narrowing the scope
of a rejection based on recipient addresses, for setting the text of
the message returned when a rejection occurs, and for forwarding messages
that would have been rejected to a different address to collect evidence
of junk e-mail.  It also includes support for using UNIX-style regular
expressions for address matching, rather than VMS wildcards.
See <REFERENCE>(rejman_cmd_add_rej) for more information.
<HEAD2>(Header-based Rejections\headerrejects)
<P>
As spammers have become more sophisticated, junk e-mail messages have
started looking more and more like legitimate messages, with perfectly
valid envelope information.  Such messages, however, often contain
RFC822 message headers that can be used to identify them as junk.
To block such messages, REJMAN provides for the addition of header-based
rejection rules, with ADD REJECTION/HEADER:
<INTERACTIVE>
<S>(REJMAN> )<U>(ADD REJECTION/HEADER header-text-pattern)
<ENDINTERACTIVE>
<P>
For example, some types of junk e-mail messages, advertising
<quote>(get rich quick) schemes contain Subject: headers
that begin and end with a string of dollar signs, as in:
<INTERACTIVE>
Subject:  $$ MAKE MONEY FAST $$
<ENDINTERACTIVE>
<P>Since it is unlikely that a legitimate message will contain
a Subject: header that begins and ends with dollar signs, you
might want to add the following header-based rejection to the
REJMAN database:
<INTERACTIVE>
<S>(REJMAN> )<U>(ADD REJECTION/HEADER "Subject: $$*$$")
<ENDINTERACTIVE>
<P>This will cause the SMTP server to reject any message containing
a header that matches this pattern.
<NOTE>
As with address-based rejections, you should be careful when creating
header-based rejection rules, to prevent the unwanted rejection of
legitimate e-mail messages.
<ENDNOTE>
<P>By default, header rejections match using VMS-style wildcards
(<QUOTE>(*) and <QUOTE>(%)).  Use a backslash to match one of these
characters, rather than having it interpreted it as a wildcard.
You can also use UNIX-style regular expressions instead of VMS
wildcard pattern matching by using the /REGEX qualifier on the
ADD REJECTION command, for more sophisticated matching rules.

<P>For header-based rejections, the SMTP server receives the
entire text of an incoming message before it can identify an
unwanted message and return 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.
<P>Rejections based on header information can be redirected
to other addresses (with the /FORWARD_TO qualifier).  Unlike address-based
rejection rules, however, you cannot modify the message returned
to the sending system when a header-based rejection occurs.

<HEAD2>(Tracking Rejections\rejtracking)
<P>
Tracking information is stored in the REJMAN database for each
rejection rule.  This information includes:
<LIST>(UNNUMBERED)
<LE>the date and time you added a rule to the database;
<LE>the date and time the SMTP server last rejected a message based on the rule; and
<LE>a count of the number of times the rule has been used to reject a message
<ENDLIST>
<P>This information is mainly for your use, so you can gauge the effectiveness
of the rejection rules you have entered.  The SMTP server periodically updates
the statistics in the database, and updates the database when it is reset or
shut down.

<HEAD2>(Purging Old Rules\rejpurging)
<P>Since particular patterns of junk e-mail envelope and header characteristics
tend to last only for a short time, REJMAN includes a PURGE command to allow you
to delete rules from the database that have not been used recently:
<INTERACTIVE>
<S>(REJMAN> )<U>(PURGE [/BEFORE=date-time])
<ENDINTERACTIVE>
<P>Unless you specify the /BEFORE qualifier, the PURGE command will remove
rules from the database that have not been used to reject messages for 30
days or more.
<P>Periodically using the PURGE command helps keep the database from growing
too large, reducing the overhead involved in performing junk e-mail checks.

<HEAD1>(Heuristic Filters\heuristicsdesc)
<P>Senders of junk e-mail use various techniques to disguise the source of
their messages, and change their source addresses frequently.  This makes
it difficult to keep rejection rules up-to-date.  In spite of these changes
in addresses, most junk e-mail messages exhibit certain characteristics
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.
<P>
The filters are called <quote>(heuristic) because they determine only the
<emphasis>(probability) that a message may be junk e-mail, based on rules
created from empirical observation of thousands of junk e-mail messages.
It is possible for legitimate, non-junk e-mail to match one or more
of these filters, too.  Because of this, the heuristic filters come
with configuration options for forwarding matching messages to a
mailbox (typically the local Postmaster or system manager) for further
review, and for creating exceptions to the filters based on the sender's
address.

<P>The REJMAN utility is used to configure the heuristic filters, using
the commands described on the following pages:
<LIST>(UNNUMBERED)
<LE>ENABLE HEURISTIC, <REFERENCE>(rejman_cmd_enable_heuristic)
<LE>DISABLE HEURISTIC, <REFERENCE>(rejman_cmd_disable_heuristic)
<LE>SET HEURISTICS, <REFERENCE>(rejman_cmd_set_heur)
<LE>ADD EXCLUSION, <REFERENCE>(rejman_cmd_add_excl)
<LE>DELETE EXCLUSION, <REFERENCE>(rejman_cmd_del_excl)
<ENDLIST>
<CP>The REJMAN SHOW HEURISTICS command displays the current settings for
the heuristic filters.

<HEAD2>(Confidence Levels\heurcldesc)
<P>The heuristic filters provided by MX are listed in <REFERENCE>(heur_table).
Each filter is assigned a <NEWTERM>(confidence level) (CL) that represents,
on a scale from zero to ten, the probability that a message matching the
filter is junk mail.  The default CL for each filter is
shown in the table; you can change these values when configuring the
heuristic filters.

<P>When a message is received by the SMTP server, its headers
are checked against each heuristic filter, and the message is assigned
the highest CL found for all matching filters.  When no
filters match, the assigned CL is zero.
<P>The message's assigned CL is the checked against two
configurable threshold values, the <newterm>(accept) threshold and
the <newterm>(reject) threshold.
<LIST>(unnumbered)
<LE>If the assigned CL is <emphasis>(less than or equal to) the
     <emphasis>(accept\bold) threshold, the message is classified
     as legitimate mail, and no further action is taken.
<LE>If the assigned CL is <emphasis>(greater than) the
     <emphasis>(reject\bold) threshold, the message is classified
     as junk mail, and is rejected.
<LE>If the assigned CL is <emphasis>(between) the two thresholds,
     it is classified as <quote>(probable) junk; it is not rejected,
     but additional headers are inserted into the message to
     warn the recipient about its classification.
<ENDLIST>

<TABLE>(Heuristic Filters\heur_table)
<TABLE_SETUP>(3\25\10)
<TABLE_HEADS>(Filter name\Default CL\Description)
<TABLE_ROW>(FROM_TO_SENDER_SAME\10\Matches when the SMTP MAIL FROM: address matches both
                                the From: and To: addresses in the RFC822 headers.)
<TABLE_ROW>(INVALID_AOL_ADDRESS\10\Matches when the RFC822 From: or To: headers contain
    	    	    	    	an invalid address for AOL.COM (username too long or
                                containing invalid characers).)
<TABLE_ROW>(INVALID_FROM\2\Matches when the From: header cannot be parsed.)
<TABLE_ROW>(INVALID_HOTMAIL_ADDRESS\10\Matches when the RFC822 From: or To: headers contain
                                an invalid address for HOTMAIL.COM.)
<TABLE_ROW>(INVALID_TO\2\Matches when the To: header cannot be parsed.)
<TABLE_ROW>(MSGID_HAS_FROM\10\Matches when the Message-ID: header contains the RFC822 From: address.)
<TABLE_ROW>(MSGID_HAS_TO\10\Matches when the Message-ID: header contains the RFC822 To: address.)
<TABLE_ROW>(NULL_FROM\8\Matches when there is no RFC822 From: header in the message, or the header
                                is present but empty.)
<TABLE_ROW>(NULL_MSGID\10\Matches when the RFC822 Message-ID: header contains a null message ID.)
<TABLE_ROW>(NULL_TO\6\Matches when there is no RFC822 To: header in the message, or the header
                                is present but empty.)
<TABLE_ROW>(NUMERIC_ADDRESS\7\Matches when the username part of the From: or To: address contains
                                only digits.  Exceptions are provided for domains known to use
                                all-numeric usernames, such as MCIMAIL.COM.)
<TABLE_ROW>(PRECEDENCE_BULK\4\Matches when the message contains a Precedence: header containing
                                the word <QUOTE>(bulk).)
<TABLE_ROW>(RECEIVED_AFTER_FROM\4\Matches when a Received: header is found after the From: header.
                                This is usually an indication that the sender did not include
                                a From: header in the original message, or that the sender forged
                                the misplaced header.)
<TABLE_ROW>(RECEIVED_ALL_ZEROS\10\Matches when a Received: header is found after the From: header,
                               <EMPHASIS>(and) that Received: header contains the string
                               <QUOTE>(000.000.000.000).)
<TABLE_ROW>(UIDL_AUTH_SENDER\10\Matches when the message contains an X-UIDL: header <EMPHASIS>(and) a
                               Comments: header that contains the string <QUOTE>(authenticated
                               sender is).)
<TABLE_ROW>(X_UIDL\8\Matches when the message contains an X-UIDL: header.  This header is normally
                               used internally by some POP servers and clients to uniquely identify
                               messages in mailboxes, and should not generally be found in outbound
                               messages.)
<ENDTABLE>

<HEAD2>(Rejection Actions\heurrejactiondesc)
<P>
When a message's confidence level exceeds the rejection threshold,
the SMTP server applies the <newterm>(rejection action) that you configure.
This action can either be REJECT, which causes the SMTP server to refuse
the message, or FORWARD, which causes the SMTP server to accept the message,
but forward it either to the local Postmaster or to an address you specify.
<P>
By setting the rejection action to FORWARD, you can review messages that
have been rejected by the filters and recover those messages that may have
been misclassified.  Each forwarded message will contain additional headers
listing the original sender and recipients, plus a header that indicates
the filter that caused the message to be rejected.  If a legitimate message
was misclassified, you can use the REJMAN ADD EXCLUSION command to prevent
future messages from the same originating address from being rejected.

<HEAD2>(Junk Mail Warnings\junkmailwarndesc)
<P>For a message that is identified as possible junk mail but is not rejected,
the SMTP server inserts one or two headers to warn the recipient(s) that
the message was identified as junk mail.  The first header is:
<INTERACTIVE>
     X-Junk-Mail-Rating: {LOW, MEDIUM, or HIGH}
<ENDINTERACTIVE>
<CP>LOW 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
filtering, the addition of this header should make it simple for them
to set their own policy regarding junk mail that is sent to them.
<P>You may configure the SMTP server to include an additional header that
identifies the filter that caused the message to be classified as junk
mail.  The REJMAN command that turns on this additional header is
SET HEURISTICS/INCLUDE_REASON.

<HEAD1>(Logging SMTP Server Rejections\logreject)
<P>You can have the SMTP server notify you when it rejects a message
due to sender validation, REJMAN rules, or heuristic checks by defining the
logical name MX_SMTP_REJECTION_EVENT_CLASS:
<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_SMTP_REJECTION_EVENT_CLASS opcom-class-name)
<ENDINTERACTIVE>
<P>
If 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 incoming message
based on DNS validation of the sender address, or based on the rejection rules
you have added to the REJMAN database.

<HEAD1>(Debugging Rejection Rules and Heuristic Filters\debugreject)
<P>
The SMTP server contains some additional logging code for debugging REJMAN
rejection rules and heuristic filters.  You can enable this debug logging
with the following logical name definition:
<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_ANTI_SPAM_DEBUG level)
<ENDINTERACTIVE>
<CP>
where <EMPHASIS>(level) is an integer value greater than zero that specifies
how much information should be included in the debug log.  Basic information
is included when the debug level is 1; more detail is included when the debug
level is 2 or higher.
<P>After defining this logical name, you must use MCP to RESET the SMTP server.
To turn off debug logging, you should DEASSIGN the logical name and RESET the
SMTP server.  That will close the log file so you can examine the debug output.

<HEAD1>(Reducing Junk Mail Postings on Mailing Lists\listjunk)
<P>
Mailing lists can be configured to ignore postings that are suspected to be
junk mail, by using the /IGNORE qualifier on the DEFINE LIST and MODIFY LIST
commands.  This qualifier takes two keywords, JUNK_MAIL, and MISSING_LIST_ADDRESS.
<P>
When a list posting matches one of the specified /IGNORE criteria, it is simply
discarded, without being forwarded to the list subscribers or owners.
<HEAD2>(Ignoring Heuristically-Determined Junk Mail\listheur)
<P>
When the heuristic junk mail detector in the SMTP server identifies, but does
not reject, a message as possible junk mail, it adds the header <quote>(X-Junk-Mail-Rating:)
to the message.  This header contains a rating of LOW, MEDIUM, or HIGH which indicates
the confidence level of the detection.
<P>While you may wish to let such messages pass to individual users, and let
them determine for themselves whether or not to discard the messages they receive,
you may also want to be stricter about letting such messages become mailing
list postings -- especially for public mailing lists with a large number of
subscribers.  To cause the mailing list processor to ignore messages tagged by
the heuristic junk mail detector, specify
<INTERACTIVE>
<U>(  /IGNORE=JUNK_MAIL[=level])
<ENDINTERACTIVE>
<CP>when creating or modifying the mailing list in MCP.  If you do not
specify a value for <EMPHASIS>(level), MEDIUM is assumed by default; this
rejects all messages tagged with either a MEDIUM or HIGH confidence of
being junk mail.
<HEAD2>(Ignoring Messages Without the List Address\listnoaddr)
<P>
When users post messages to a mailing list, they generally do so directly,
so the address of the list appears in either the RFC822
<QUOTE>(To:) or <QUOTE>(CC:) header.  Since many junk-mail generators do
not include the intended recipient in either of those headers, you may
wish to have the list processor ignore messages that do not directly
include the mailing list's address.  To do this, specify /IGNORE=MISSING_LIST_ADDRESS
when defining or modifying the list.

<HEAD1>(Using SMTP Authentication to Bypass Junk Mail Checking\smtpauthuse)
<P>
Some sites have <quote>(roaming) users that need access to the mail system
from outside the site's network; such users have dial-up accounts with Internet
Service Providers that assign addresses on an <quote>(outside) network.
Mail sent by such users would normally be subject to all anti-relay and
anti-junk-mail checking by the MX SMTP server, and would typically be rejected.
<P>Roaming users that have e-mail client programs
that implement the SMTP service extension for authentication (RFC2554) can
authenticate to the MX SMTP server with a username and password, which will
allow them to send messages that bypass all relay and junk mail checking.
<HEAD2>(Authentication Mechanisms Supported\authmechs)
<P>
MX supports authentication using the usernames and passwords in the
VMS user authorization file through the PLAIN authentication mehchanism
(RFC2222).  MX also supports the non-standard LOGIN authentication mechanism,
for compatibility with some clients that use it; it is similar to the PLAIN
mechanism.
<P>Use the following command to enable PLAIN and LOGIN authentication support:
<INTERACTIVE>
<S>(MCP> )<U>(SET SMTP/AUTHENTICATION=PLAIN)
<ENDINTERACTIVE>
<NOTE>
The PLAIN and LOGIN authentication mechanisms do not encrypt the password
that is provided by the client; they are sent to the server in the equivalent
of plain text.
<ENDNOTE>

<P>
The MX SMTP server also implements the CRAM-MD5 authentication mechanism (RFC2195),
using a private authentication database.  To enable the CRAM-MD5 extension,
use the following command:
<INTERACTIVE>
<S>(MCP> )<U>(SET SMTP/AUTHENTICATION=CRAM_MD5)
<ENDINTERACTIVE>
<CP>
With the CRAM-MD5 mechanism, passwords are one-way hashed before being sent
to the server.
<P>
You can enable both extensions, if desired, by specifying a comma-separated
list of keywords to the /AUTHENTICATION qualifier.
<NOTE>
The SMTP server only advertises its authentication support to clients
that are not identified as being on the INSIDE_NETWORK_ADDRESS list.
<ENDNOTE>
<P>Advertising authentication support causes some mail clients to require
the user to enter a username and password, even if they are not needed to
send messages.  Since the authentication support only activates features
that are needed by clients on outside networks, MX only advertises authentication
support to those clients.  This may change in a future release of MX.
<HEAD2>(Managing the SMTP Authentication Database\authmgmt)
The hashing algorithm used by the CRAM-MD5 authentication mechanism is not compatible
with the VMS user authorization system, so MX has its own database for
storing the usernames and passwords used by the SMTP server.  This database
is kept in the file MX_DIR:MX_USERAUTH_DB.DAT by default.  You may specify
an alternate location for the database by defining a logical name:
<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_USERUATH_DB file-spec)
<ENDINTERACTIVE>
<P>Use the MCP CREATE USER_DATABASE_FILE command to create an empty copy of
the authentication database:
<INTERACTIVE>
<S>(MCP> )<U>(CREATE USER_DATABASE_FILE)
<ENDINTERACTIVE>
<P>This file is created with file protection that allows read and write access
only to SYSTEM and OWNER.  <NOTE>Do <emphasis>(not) change this
default file protection!  Only privileged users and programs should have any
access to the authentication database!<ENDNOTE>
<P>Once the database file is created, you can use the ADD USER, MODIFY USER, and
REMOVE USER commands to manage the usernames and passwords in the database.  For
example:
<INTERACTIVE>
<S>(MCP> )<U>(ADD USER "SmtpUser"/PASSWORD="SmtpUserPassword")
<ENDINTERACTIVE>
<P>Usernames may be up to 16 characters long, and are case-sensitive.  Only letters,
digits, and underscores are allowed in usernames.  Passwords may be up to 64
characters in length, and may contain any characters (although only printable characters
are recommended); passwords are also case-sensitive.
<HEAD2>(How Authentication Works\howauthworks)
<P>
When a compatible client connects to the SMTP server, it sends the SMTP EHLO (extended
hello) command to find the extensions supported by the server.  The SMTP server lists
the AUTH extension in its reply; this informs the client that it may use the AUTH command
to begin an authentication sequence.
<P>When the client sends its authentication request using the AUTH command, the SMTP
server uses the CRAM-MD5 mechanism to decode the authentication request and compares the
result against the password against the one stored in the database.  CRAM-MD5 uses a
hash algorithm that prevents the username and password from being <quote>(sniffed) by
a third party that might be monitoring the connection.
<P>If the username and password are validated, any messages sent by the client are
treated as though they came from a host on the INSIDE_NETWORK_ADDRESS list, and will
not be checked for relaying as long as the sender's domain name is a local domain.
In addition, no rejection rule or heuristic junk mail checks will be performed on
the messages sent by the authenticated user.
<P>Authentication failures are logged to the SMTP server log file, and are also
<x>(logical names<XS>MX_SMTP_AUTHFAIL_EVENT_CLASS)
logged to OPCOM if the MX_SMTP_AUTHFAIL_EVENT_CLASS logical name is defined.
<HEAD2>(PLAIN Authentication Features\sysuaf_features)
<P>By default, the PLAIN/LOGIN authentication mechanism uses the usernames
and passwords in the VMS system authorization file (SYSUAF) for authenticating
clients.  Alternative authentication sources may be used by installing an
authentication callout module.  The <REFERENCE>(progguide) has more information
on writing and installing an SMTP authentication callout module.
<HEAD2>(Limiting SMTP Authentication Access to Certain Users\authrights)
<P>When using the default SYSUAF authentication mechanism for PLAIN/LOGIN,
you may specify a VMS rights identifier that must be held by authenticating
users for authentication to be completed, through a logical name defined
in executive mode in the system logical name table:
<x>(logical names<XS>MX_SMTP_AUTH_IDENTIFIER)
<INTERACTIVE>
<S>($ )<U>(DEFINE/SYSTEM/EXEC MX_SMTP_AUTH_IDENTIFIER identifier-name)
<ENDINTERACTIVE>
<CP>When this logical name is defined, only those users who have been granted
the specified identifier will be able to authenticate successfully to the SMTP server.
<P>Note that this logical name is used only with the default SYSUAF
mechanism for LOGIN/PLAIN SMTP authentication.  It does not apply when an
authentication callout is installed or when the private SMTP authentication database
is used with the CRAM-MD5 authentication mechanism.

<HEAD2>(Intrusion Detection and Evasion\smtpauthsecurity)
<P>To help prevent password-guessing attacks on the system, the SMTP
server implements intrusion detection and evasion measures. Some of
the features described in the following sections apply to all authentication
mechanisms; some only apply when the default SYSUAF mechanism is used with
PLAIN/LOGIN authentication.
<HEAD3>(Authentication Retry Timers\authretry)
<P>When an authentication attempt fails, the
authentication failure response to the client is delayed based on the
LGI_RETRY_TMO system parameter, the same timer used for normal login
password failures.
<P>This timer is used for all authentication mechanisms.
<HEAD3>(Authentication Retry Limits\retrylimits)
<P>The SMTP server automatically disconnects the client when the
number of authentication failures in a single SMTP session exceeds
the count set by the LGI_RETRY_LIM system paramter, the same limit used
for normal login retry limiting.
<P>This limit applies for all authentication mechanisms.
<HEAD3>(Intrusion Evasion\vmsevasion)
<P>When using the default SYSUAF mechanism for PLAIN/LOGIN authentication, the
SMTP server tracks attempts to authenticate using invalid passwords, and implements
intruder evasion measures similar to those used by VMS for normal logins.  <reference>(intrutbl)
lists the system parameters that the SMTP server uses for breakin tracking and evasion.
Breakins are tracked by a combination of username and client IP address.
<TABLE>(Intrusion Detection and Evasion Parameters\intrutbl)
<TABLE_SETUP>(2\20)
<TABLE_HEADS>(System Parameter\Description)
<TABLE_ROW>(LGI_BRK_LIM\Limit on the number of failures for a single username/IP address
combination before evasion measures begin.  When evasion is started, even a valid password
provided by the client is treated as an authentication failure.)
<TABLE_ROW>(LGI_BRK_TMO\Amount of time since the last authentication failure that must
pass before a suspect is cleared from the intrusion list.)
<TABLE_ROW>(LGI_HID_TIM\Amount of time that evasive action persists after an intruder
is detected.)
<ENDTABLE>
<P>These parameters are used only for the default SYSUAF mechanism for PLAIN/LOGIN
authentication.   They are not used if an authentication callout is installed (although
the callout module may use them, if it is written to do so), nor are they used with
the private CRAM-MD5 SMTP authentication database.


<chapter>(Other Miscellaneous Utilities\MGMT_GUIDE_53)
<p>This chapter describes other utilities available with MX.
<head1>(The MLFAKE Utility\MGMT_GUIDE_54)
<X>(MLFAKE utility)
<X>(Utilities<XS>MLFAKE)
<p>For those times when you need to act on behalf of one of your users
to sign off or subscribe to a mailing list, the MLFAKE utility may
come in handy:
<syntax>
 $ MLFAKE  :== $MX_EXE:MLFAKE
 $ MLFAKE  listname  hostname  [command] [arguments]
     /LISTSERV[=lsvname]
     /REQUEST=reqaddress
     /FROM=fromuser
<endsyntax>
<p>Specify the name of the mailing list and its host (with no @ in between).
If you omit <keyword>(command), it defaults to SIGNOFF.  If the command
requires additional arguments, you should specify them after
<keyword>(command) (in which case you must specify the command). If the mailing
list is managed by an L-Soft LISTSERV, use the /LISTSERV qualifier; otherwise
the request will go to the -Request address for the list (the Internet
convention).  You can override this altogether by specifying the request
address with the /REQUEST qualifier.  Finally, you must specify who the
request is supposed to be from with the /FROM qualifier.
<p>For example:
<interactive>
<s>($ )<u>(MLFAKE/FROM=someuser MX-List LISTS.WKU.EDU)
<s>($ )<u>(MLFAKE/FROM=someuser/REQUEST="FileServ" -)
<s>(_$)<u>(         "" WKU.EDU SEND MX040.BLURB)
<endinteractive>
<p>The first example is for an Internet-type mailing list.  The message will
be constructed with <quote>(someuser) as the originator and
MX-List-Request@lists.wku.edu as the destination, with the message reading
SIGNOFF.  The second example shows how MLFAKE
can be used with file servers by specifying the destination user with the
/REQUEST qualifier and omitting the <keyword>(listname) argument (which
is ignored when /REQUEST is specified).
<P>MLFAKE requires SYSPRV privilege.  SYSLCK privilege is not required,
but will speed processing of the message. <emphasis>(DO NOT install
the MLFAKE image with these privileges!\bold) Only <emphasis>(trusted)
users should have access to this utility, since it can be used to fake a
mail message from any other user.

<HEAD1>(The MAILQUEUE Utility\MGMT_GUIDE_55)
<X>(MAILQUEUE utility)
<X>(Utilities<XS>MAILQUEUE)
<p>MAILQUEUE is a program that scans the message queue for entries still
in progress.  It can be used by non-privileged users to view only those
entries which were sent by them.  When used from an account with SYSPRV
privilege turned on, it lists all pending queue entries.
<p>MAILQUEUE resides in the MX_EXE: directory and is designed to be
executed as a DCL foreign command:
<interactive>
<s>($ )<u>(MAILQ*UEUE :== $MX_EXE:MAILQUEUE)
<S>($ )<U>(MAILQ)
<endinteractive>
<p>If there are no delayed messages, MAILQUEUE returns the message

<interactive>
%MAILQ-I-MQNONE, no MX mail messages queued on local system
<endinteractive>


<p>Otherwise, the MAILQUEUE display will resemble the following:
<interactive>

Entry: 9872, Origin: [SMTP] <SOMEUSER@yoyodyne.com>
  Status: IN-PROGRESS
  Local entry #9874, status: READY
      Waiting for retry until: 15-NOV-1991 16:46:44.12
      Recipient #1: SOMEUSER, Route=myhost.mycompany.com
      Error count=93
      Last error: %MAIL-E-OPENOUT, error opening !AS as output

Entry: 10859, Origin: [Local] <FileServ@myhost.mycompany.com>
  Status: READY, waiting until 15-NOV-1991 18:00:00.00
    Recipient #1: <SOMEUSER@somecompany.com>
<endinteractive>


<HEAD1>(The MX_DECODE Utility\MGMT_GUIDE_MX_DECODE)
<X>(MX_DECODE utility)
<X>(Utilities<XS>MX_DECODE)
<P>
The MX_DECODE utility will decode MIME-compliant mail messages with
contents encoded as BASE64 or QUOTED-PRINTABLE.  If the content
type of the message is APPLICATION/VMS-RMS, it will also automatically
restore the file's original RMS attributes.
The MX Local agent automatically decodes VMS-RMS and QUOTED-PRINTABLE
when they are received.  MX_DECODE is provided for use in decoding
messages delivered by other mailers, as well as
for use with the MX Site agent, so that messages destined for MX Site
may sent using SEND/FOREIGN.

<P>
MX_DECODE should be executed using a foreign command:

<INTERACTIVE>
<S>($ )<U>(MX_DECODE :== $MX_EXE:MX_DECODE.EXE)
<S>($ )<U>(MX_DECODE MAIL_MESSAGE.BASE64 XYZ.xxx)
<ENDINTERACTIVE>

<P>
It accepts two required parameters: the input file and the output
file.

By default,

in order to decode the file properly, the input file must
include the MIME RFC822 headers before the encoded body.  The headers
are used only to find the stored VMS file attributes. If the file
has a content type of APPLICATION/VMS-RMS, the resulting
decoded output file will retain all of the VMS file attributes of the
original file.  Otherwise, the format of the resulting file will
either be fixed-length, 512-byte records (for binary BASE64-encoded
messages) or a text file (for QUOTED-PRINTABLE and BASE64-encoded
text messages).


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



<chapter>(Troubleshooting MX\MGMT_GUIDE_56)
<p>This chapter contains information on MX useful for debugging
MX components.
<head1>(Queue Files Used by MX Components\MGMT_GUIDE_57)
<x>(Queue files)
<p>As has already been discussed, each MX component uses files in the
message queue when processing messages.  Each queue entry has at least
one file associated with it, usually containing envelope information.
The files created by MX are stored in a directory tree under the
MX_FLQ_DIR: directory.  The files are named
<emphasis>(n).<emphasis>(type), where <emphasis>(n) is the queue entry
number and <emphasis>(type) is a file type indicating the type of
information is in the file.

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

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

<head2>(File Types\MGMT_GUIDE_58)
<x>(Queue file types)
<p>The following list describes the file types used for queue files,
the agents that write them, and the agents that read them.
<p><emphasis>(SRC_INFO\bold).  This is the envelope information written
<x>(SRC_INFO file)
on message entry.  This file contains TLV records indicating the source
of the message, the originating address, and the recipient addresses.
Written by: MX_MAILSHR,
DNSMTP_SERVER,
SMTP_SERVER, MX_SITE_IN.  Read by: MX_ROUTER.
<p><emphasis>(HDR_INFO\bold).  This file contains the message headers,
<x>(HDR_INFO file)
in TLV format.  The headers are only used during address conversion when
gatewaying mail into UUCP or for making return-address determinations
on local delivery of mail.
Written on message entry by: MX_MAILSHR,
DNSMTP_SERVER, 
SMTP_SERVER,
MX_SITE_IN.  Read by: MX_LOCAL, 
MX_SMTP, MX_SITE, MX_MLF, MX_DNSMTP.
<p><emphasis>(MSG_TEXT\bold).  This file contains the text of the
<x>(MSG_TEXT file)
body of the message, in plain ASCII.  Written on message entry by: MX_MAILSHR,
DNSMTP_SERVER, SMTP_SERVER, MX_SITE_IN.  Read on message delivery
by: MX_LOCAL, MX_SMTP, MX_SITE, MX_MLF, MX_DNSMTP.
<p><emphasis>(DNSMTP_INFO, LOCAL_INFO, SMTP_INFO,
SITE_INFO, MLF_INFO\bold).  These
<x>(LOCAL_INFO file)<x>(SMTP_INFO file)
<X>(MLF_INFO file)<x>(SITE_INFO file)<x>(DNSMTP_INFO file)
files contain envelope information used by the delivery agents.  Written
by: MX_ROUTER.  Read by:
MX_DNSMTP,
MX_LOCAL, MX_SMTP, MX_SITE,
MX_MLF
(respectively).
<p>Note that the SRC_INFO, HDR_INFO, and MSG_TEXT files remain attached
to the original (base) queue entry.  When the queue entries for the delivery
agents are created, a back link to the original queue entry is entered
so the delivery agents can gain access to the headers and message text.
In addition, forward links to the delivery agent entries are kept in the
original queue entry, which are zeroed out as each delivery agent finishes
its processing.  When all forward links are zeroed, the original queue
entry is changed to FINISH status.
<head1>(Process Names\MGMT_GUIDE_59)
<p>
The MX_START.COM command procedure assigns a specific process name to
each of the MX detached processes.  To determine whether an agent is
running or not, use the MCP command STATUS or examine the SHOW SYSTEM
output for the following
<x>(Process names)
process names:
<table>
<table_setup>(2\15)
<table_row>(MX Router\The Router)
<TABLE_ROW>(MX FLQ Manager\The MX queue manager)
<table_row>(MX SMTP\SMTP delivery agent)
<table_row>(MX DNSMTP\SMTP-over-DECnet delivery agent)
<table_row>(SMTP Server\SMTP server)
<table_row>(MX Local\Local delivery agent)
<table_row>(MX MLF\Mailing list/file server)
<table_row>(MX Site Agent\Site-specific interface agent)
<table_row>(MX->SITE\Subprocess created by site interface)
<endtable>
<p>Note that the subprocesses are not created until at least one message
is processed by the corresponding delivery agent.
<head1>(Debug/Trace Output\MGMT_GUIDE_60)
<x>(Debugging)
<p>Each of the delivery agents has debug/trace code that can be enabled
to provide information on message processing.  Tracing is enabled by
defining a system-wide logical name, and disabled by deassigning that logical.
Debugging can be enabled or disabled <quote>(on
the fly): the process being debugged will automatically start logging
trace information for each entry processed after the logical name is
defined.
<x>(Trace logs)
<p>The trace log file, by default, is created in the same directory used
for the agent's main log file, with a file type of .LOG_<EMPHASIS>(process-id)
(for the SMTP server, the default file type is .LOG_<EMPHASIS>(process-id)_<EMPHASIS>(thread-id)).
Trace output can be redirected by defining a system-wide logical name.
The logical names
used for debugging are outlined in <reference>(dbgtable).
<p>There is no debugging code available in the MX_MAILSHR/MX_MAILSHRP (the
VMS MAIL interface) or in
MX_SITE_IN.
<table>(Debug/Trace logical names\dbgtable)
<table_attributes>(WIDE)
<table_setup>(4\15\20\20)
<table_heads>(Agent\Enabling logical\Trace file\Default directory)
<x>(Logical names<xs>MX_LOCAL_DEBUG)
<table_row>(Local\MX_LOCAL_DEBUG\MX_LOCAL_LOG\MX_LOCAL_DIR:)
<x>(Logical names<xs>MX_MLF_DEBUG)
<table_row>(ML/FS\MX_MLF_DEBUG\MX_MLF_LOG\MX_MLF_DIR:)
<x>(Logical names<xs>MX_ROUTER_DEBUG)
<table_row>(Router\MX_ROUTER_DEBUG\MX_ROUTER_LOG\MX_ROUTER_DIR:)
<x>(Logical names<xs>MX_FLQ_DEBUG)
<table_row>(Router/file queue\MX_FLQ_DEBUG\MX_FLQ_LOG\MX_ROUTER_DIR:)
<x>(Logical names<xs>MX_SMTP_DEBUG)
<table_row>(SMTP out\MX_SMTP_DEBUG\MX_SMTP_LOG\MX_SMTP_DIR:)
<x>(Logical names<xs>MX_SMTP_SERVER_DEBUG)
<table_row>(SMTP server\MX_SMTP_SERVER_DEBUG\SMTP_SERVER_LOG\MX_SMTP_DIR:)
<x>(Logical names<xs>MX_DNSMTP_DEBUG)
<table_row>(SMTP-over-DECnet out\MX_DNSMTP_DEBUG\MX_DNSMTP_LOG\MX_DNSMTP_DIR:)
<x>(Logical names<xs>MX_DNSMTP_SERVER_DEBUG)
<table_row>(SMTP-over-DECnet server\MX_DNSMTP_SERVER_DEBUG\DNSMTP_SERVER_LOG\MX_DNSMTP_DIR:)
<x>(Logical names<xs>MX_SITE_DEBUG)
<table_row>(Site Agent\MX_SITE_DEBUG\MX_SITE_LOG\MX_SITE_DIR:)
<endtable>


<chapter>(The MX Startup Process\mxstartup)
<p>This chapter describes the command procedures
<x>(startup command procedures)
and files used by MX when it is started.
<head1>(Startup Command Procedures\startcmdprocs)
<p>Typically, MX is started up by executing the command procedure
<x>(MX_STARTUP.COM)
SYS$STARTUP:MX_STARTUP.COM.  This file is created at installation time simply
to make MX easy to start; all it does is execute MX___STARTUP.COM, which
<x>(MX___STARTUP.COM)
is located in the directory that eventually becomes the equivalence name
for the logical name MX_EXE.  MX___STARTUP.COM contains the commands for setting
up the MX logical names and invoking MX_START.COM, also located in
<X>(MX_START.COM)
the MX_EXE directory, to start the MX processing agents.
<p>Individual MX components can be started by passing their names (one or
more, separated with commas and with no intervening blanks) as arguments
to SYS$STARTUP:MX_STARTUP.COM.  <reference>(compnamtab) lists the components
that the startup command procedures recognize.
<x>(startup components)
<x>(component names)
<table>(Component names for use with MX_STARTUP.COM\compnamtab)
<table_setup>(2\15)
<table_heads>(Name\Description)
<table_row>(LOGICALS\Defines MX logical names and installs the MX shareable
libraries.)
<table_row>(NETLIB\Executes NETLIB's startup command procedure. (Prerequisite
for ROUTER, SMTP, and SMTP_SERVER if using TCP/IP with MX.))
<table_row>(ROUTER\Starts the Router process.)
<table_row>(LOCAL\Starts the local delivery agent.)
<table_row>(SMTP\Starts the SMTP-over-TCP/IP delivery agent.)
<table_row>(SMTP_SERVER\Starts the SMTP server (for TCP/IP).)
<table_row>(DNSMTP\Starts the SMTP-over-DECnet delivery agent.)
<table_row>(SITE\Starts the SITE interface.)
<table_row>(MLF\Starts the mailing list/file server.)
<endtable>
<head1>(Startup Data Files\stardata)
<p>MX___STARTUP.COM uses two data files, both located in the MX root directory
(MX_DIR:).  MX_LOGICALS.DAT contains logical name definitions, some of which
can be customized or altered after MX is installed.  MX_STARTUP_INFO.DAT
contains information on which of the MX components are installed, and on
which nodes they should be run.
<P>Do not edit these files directly.  Use the MXCONFIG.COM procedure provided
in the MX root directory to make any changes to the standard MX
logical names and agent startup information.

<part>
<part_page>
<title>(MCP Command Dictionary)
<endpart_page>(RENUMBER)
<COMMAND_SECTION>(MCP Commands\MCP)
<SET_TEMPLATE_COMMAND>(COMMAND\DOUBLERUNNINGHEADS)

<COMMAND>(MCP\\MGMT_GUIDE_61)
<x>(MX Control Program)
<OVERVIEW>
Executes the MX Control Program.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(MCP)
<FPARMS>([command])
<QUAL_LIST>
<QPAIR>(/[NO]FILE=file-spec\/FILE=MX_DIR:MX_CONFIG.MXCFG)
<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>([command])
<PARAMDEF>
Any MCP command except the input redirection operator (@).  The specified
command is executed and control is returned to DCL immediately thereafter.
<ENDPARAMDEFLIST>

<DESCRIPTION>
MCP was written to be used as a DCL <quote>(foreign) command.  To
use it as a foreign command, you must define a symbol as follows:
<interactive>
<s>($ )<u>(MCP :== $MX_EXE:MCP)
<endinteractive>
<P>Defining the symbol in this way allows you to use the /FILE qualifier
and specify <quote>(one-shot) commands on the command line.
<p>By default, MCP loads in the current configuration file,
MX_DIR:MX_CONFIG.MXCFG, when started.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/[NO]FILE=file-spec)
<QUALDEF>
Loads the specified MX configuration file for editing.  If not specified,
MX_DIR:MX_CONFIG.MXCFG is loaded.  The default file type is MXCFG.
If /NOFILE is specified, MCP is started without loading any configuration
information.
<ENDQUALDEFLIST>

<COMMAND>(@ (Redirect Command Input)\\MGMT_GUIDE_62)
<x>(MCP commands<xs>@)
<OVERVIEW>
Executes MCP commands read from a file.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(@)
<FPARMS>(file-spec)
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(file-spec)
<PARAMDEF>
Name of the file containing MCP commands.  If omitted, the default file
type is MCP.
<ENDPARAMDEFLIST>
<DESCRIPTION>
Use this command to have MCP take further command input from the specified
file.  There is no built-in limit on the number of levels of nesting of
command files, so be careful when using input redirection from within
a command file.
<P>This command can only be used at the MCP command prompt, not as a
<quote>(one-shot) MCP command.  To have a file be used for input for an
entire MCP session, use the following sequence of DCL commands.
<interactive>
<s>($ )<u>(DEFINE/USER SYS$INPUT file-spec)
<s>($ )<u>(MCP)
<endinteractive>
<ENDDESCRIPTION>

<COMMAND>(ADD USER\\mcp_cmd_add_user)
<x>(MCP commands<xs>ADD USER)
<OVERVIEW>
Adds a user to the SMTP authentication database.
<ENDOVERVIEW>
<FORMAT>
<FCMD>(ADD USER)
<FPARMS>(username)
<ENDFORMAT>
<QUAL_LIST>
<QPAIR>(/PASSWORD=password-text\/PASSWORD=<QUOTE>(PASSWORD))
<ENDQUAL_LIST>

<PARAMDEFLIST>
<PARAMITEM>(username)
<PARAMDEF>
A username to be added to the database.  Usernames may be up to
16 characters in length, and are case-sensitive.  To add a lowercase
or mixed-case username, surround it with quotation marks.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command adds a username to the authentication database
used by the SMTP server.  Any SMTP client that authenticates to the
SMTP server with a valid username and password can send messages via
the SMTP server as if they were connected to an <quote>(inside) network,
even if they are currently not at an address on the INSIDE_NETWORK_ADDRESS list;
all anti-junk-mail and anti-relay checking is disabled.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/PASSWORD=password-text)
<QUALDEF>
Specifies a password for this username.  Passwords can contain any characters,
and are case-sensitive.  They may be up to 64 characters in length.  If you do
not specify a password on the ADD USER command, a default password, <QUOTE>(PASSWORD) (in upper case), is
assigned.
<ENDQUALDEFLIST>

<COMMAND>(ATTACH\\mcp_cmd_attach)
<x>(MCP commands<xs>ATTACH)
<OVERVIEW>
Transfers control to another process in the current process tree.
<ENDOVERVIEW>
<FORMAT>
<FCMD>(ATTACH)
<FPARMS>([process-name])
<ENDFORMAT>
<QUAL_LIST>
<QPAIR>(/IDENTIFICATION=process-id\)
<QPAIR>(/PARENT\)
<ENDQUAL_LIST>

<PARAMDEFLIST>
<PARAMITEM>(process-name)
<PARAMDEF>
Name of the process to which the terminal should be attached.
The process must be in the current process tree.  This parameter
is omitted if one of the qualifiers is specified.
<ENDPARAMDEFLIST>
<DESCRIPTION>
This command is similar to the DCL ATTACH command.  It is used
in interactive jobs to attach the terminal to another process in
the current process tree for the job.
<ENDDESCRIPTION>
<QUALDEFLIST>
<QUALITEM>(/IDENTIFICATION=process-id)
<QUALDEF>
Specifies the process by its process identification, a hexadecimal
number.
<QUALITEM>(/PARENT)
<QUALDEF>
Specifies that the terminal should be attached to the current
subprocess's immediate parent in the process tree.
<ENDQUALDEFLIST>


<COMMAND>(CREATE USER_DATABASE_FILE\\mcp_cmd_credb)
<x>(MCP commands<xs>CREATE USER_DATABASE_FILE)
<OVERVIEW>
Creates a new version of the SMTP authentication database.
<ENDOVERVIEW>
<FORMAT>
<FCMD>(CREATE USER_DATABASE_FILE)
<FPARMS>([file-spec])
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(file-spec)
<PARAMDEF>
Name of the file to be created.  If omitted, a new version of
the main authentication database file, MX_DIR:MX_USERAUTH_DB.DAT,
is created.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command should typically be used only once, to create the SMTP
authentication database for use by the SMTP server and the MCP ADD USER,
MODIFY USER, and REMOVE USER commands.
<ENDDESCRIPTION>

<COMMAND>(DEFINE/KEY\\mcp_cmd_defkey)
<x>(MCP commands<xs>DEFINE/KEY)
<OVERVIEW>
Defines an equivalence string and a set of attributes with a key
on the terminal keyboard.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(DEFINE/KEY)
<FPARMS>(key-name  equivalence-string)
<ENDFORMAT>
<QUAL_LIST>
<QPAIR>(/ECHO\)
<QPAIR>(/ERASE\)
<QPAIR>(/IF_STATE\)
<QPAIR>(/LOCK_STATE\)
<QPAIR>(/LOG\)
<QPAIR>(/SET_STATE\)
<QPAIR>(/TERMINATE\)
<ENDQUAL_LIST>

<DESCRIPTION>
See the DCL help entry for DEFINE/KEY for more information on
this command.
<P>
You can have a set of keys defined automatically for use with
MCP by placing DEFINE/KEY commands in the file
SYS$LOGIN:MX_MCP_KEYDEFS.INI.  Note that this is the same file
that is used with the REJMAN program.
<ENDDESCRIPTION>

<COMMAND>(DEFINE ALIAS\\MGMT_GUIDE_63)
<x>(MCP commands<xs>DEFINE ALIAS)
<OVERVIEW>
Defines a local alias for transparent mail forwarding.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(DEFINE ALIAS)
<FPARMS>(local-name  fwd-address[,...])
<ENDFORMAT>
<PARAMDEFLIST>
<PARAMITEM>(local-name)
<PARAMDEF>
A 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.
<PARAMITEM>(fwd-address)
<PARAMDEF>
A valid E-mail address, which will be substituted for the matching local
alias address.  Multiple addresses may be given; use commas to
separate the addresses.  The maximum character length for all
addresses is 255 characters, including commas.
<ENDPARAMDEFLIST>

<DESCRIPTION>
An alias can be used to cause mail messages to be forwarded
automatically to another address.  Unlike forwarding using the SET
FORWARD command in VMS Mail, no <quote>(Resent) headers are added to
the message.  In addition, alias-based forwarding is performed by the
MX routing agent rather than the local delivery agent, thus affording
a small savings in message queue space and processing time.  Due to
the lack of notification, however, it is recommended that aliases be
used sparingly.
<ENDDESCRIPTION>

<COMMAND>(DEFINE FILE_SERVER\\MGMT_GUIDE_64)
<x>(MCP commands<xs>DEFINE FILE_SERVER)<x>(File server)

<OVERVIEW>
Creates a file server.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(DEFINE FILE_SERVER)
<FPARMS>(name)
<QUAL_LIST>
<QPAIR>(/BEGIN_SEND_PERIOD=hh:mm\)
<QPAIR>(/[NO]DELAY_THRESHOLD=size\)

<QPAIR>(/[NO]DESCRIPTION=text\/NODESCRIPTION)

<QPAIR>(/END_SEND_PERIOD=hh:mm\)
<QPAIR>(/[NO]HOST_LIMIT=hostlim\)
<QPAIR>(/[NO]MAILING_LIST=listname\)
<QPAIR>(/MANAGER=address\)
<QPAIR>(/ROOT=rootspec\)
<QPAIR>(/[NO]SERVER_LIMIT=servlim\)
<QPAIR>(/[NO]USER_LIMIT=userlim\)
<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(name)
<PARAMDEF>
Local name to be used for the file server, up to 32 characters in length.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command is used to establish or remove an MX mail-based file server
on the local system.  The server can be set up to distribute groups of files
called <quote>(packages) using E-mail as the distribution medium.  The
file server responds to commands placed, one per line, in the text of a
mail message sent to the file server username.  The commands the file
server responds to are HELP, LIST, SENDME,

QUIT, and ADDRESS.

<P>The 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 addition, the file name of each of the files in the package must also
match the package name.  Each package must also have a file
called package-name.DESCRIPTION in the top-level root directory that contains
a description of the package and the files in the package.

<P>
The .DESCRIPTION files may be placed in the package subdirectories, if
desired, but they cannot exist in both the root and the
subdirectories.

<p>The SENDME command takes one argument, the name of a package or an
individual file.  If a package name is specified, all files in the package
directory are sent to the requesting user.  Otherwise, just the specified
file is sent.
<p>The LIST command can take a wildcard pattern as an argument (if omitted,
it defaults to <quote>(*)).  The contents of the description files of
all packages whose names match the wildcard pattern are placed in a file
and sent to the requesting user.
<p>The HELP command causes the file server to send the file
FILESERV_HELP.TXT from the top-level root directory to the requesting user.  A
sample help file is provided with MX, which the system manager can modify
to provide site-specific information.

<P>
The QUIT command causes the file server to ignore any remaining lines
in the message.  It can be used to prevent the unintentional parsing
of mail signatures.
<P>
The ADDRESS command takes a valid RFC822-compliant address.  It causes
all file server replies to be redirected to the given address instead
of the Reply-To or From addresses.

<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/BEGIN_SEND_PERIOD=hh:mm)
<QUALDEF>
Identifies the time of day when the file server can begin sending files that
exceed the delay threshold size.  Defaults to 17:00.
<QUALITEM>(/[NO]DELAY_THRESHOLD=size)
<QUALDEF>
Use /DELAY_THRESHOLD to establish the maximum size, in bytes, a file can be
to be sent at any time during the day.  Files exceeding <emphasis>(size)
are sent only during the sending period established by /BEGIN_SEND_PERIOD
and /END_SEND_PERIOD.  Use /NODELAY_THRESHOLD to remove size restrictions.


<QUALITEM>(/[NO]DESCRIPTION=text)
<QUALDEF>
This qualifier defines a brief description for the file server.
This description is added to the file server address in the
X-FileServer header on outgoing server messages.


<qualitem>(/END_SEND_PERIOD=hh:mm)
<QUALDEF>
Identifies the time of day when the file server should stop sending files
that exceed the delay threshold size.  Defaults to 09:00.
<QUALITEM>(/[NO]HOST_LIMIT=hostlim)
<QUALDEF>
Specifies that a maximum of <emphasis>(hostlim) bytes may be sent per
day to any single host.
<QUALITEM>(/[NO]MAILING_LIST=list-name)
<QUALDEF>
Specifies a mailing list to be linked to the file server.  Only those
users who are subscribed to the specified list may have access to the
file server.  The specified list must exist on the local system in
order for this qualifier to have any effect.
<QUALITEM>(/MANAGER=address)
<QUALDEF>
When establishing a file server, you can provide an E-mail address to
which all error messages and mail that bounces back to the file server can
be forwarded.  The local alias <emphasis>(name)-Mgr will be created to
direct those error messages to the /MANAGER address.
If you omit the /MANAGER qualifier, bounced mail will be
directed to the Postmaster.
<QUALITEM>(/ROOT=rootspec)
<QUALDEF>
You must specify a location (either a rooted logical or a device plus root
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 DISK:[FILE_SERVER.] (note the final
dot before the bracket, indicating it is a root specification).
<QUALITEM>(/[NO]SERVER_LIMIT=servlim)
<QUALDEF>
Specifies that a maximum of <emphasis>(servlim) bytes may be sent per
day from the server.
<QUALITEM>(/[NO]USER_LIMIT=userlim)
<QUALDEF>
Specifies that a maximum of <emphasis>(userlim) bytes may be sent per
day to any one user.
<ENDQUALDEFLIST>


<COMMAND>(DEFINE INSIDE_NETWORK_ADDRESS\\cmd_def_ins_net_add)
<x>(MCP commands<xs>DEFINE INSIDE_NETWORK_ADDRESS)

<OVERVIEW>
Defines an <quote>(inside) network address for SMTP relay determination.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(DEFINE INSIDE_NETWORK_ADDRESS)
<FPARMS>(ip-address)
<QUAL_LIST>
<QPAIR>(/NETMASK=ip-netmask\/NETMASK=255.255.255.255)
<QPAIR>(/[NO]REJECT\/NOREJECT)
<QPAIR>(/[NO]RELAY_ALLOWED\/NORELAY_ALLOWED)
<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(ip-address)
<PARAMDEF>
IP address of the network or host to be added to the list, in
dotted-decimal form.  The address is assumed to be for a host unless
the /NETMASK qualifier is specified.
<ENDPARAMDEFLIST>

<DESCRIPTION>
 This command establishes an IP address or
network that is in one of the local domains, is permitted to use your SMTP
server as a relay, or to reject a particular host or network from being
considered as part of your local domain.
<P>
 Inside network address definitions are only used with the SMTP server
is set to disallow relays with SET SMTP/NORELAY_ALLOWED.  When at least
one inside address is defined, messages coming in via SMTP are allowed
to have recipients outside of the local domain(s) only if the sending
system's IP address is on the inside network address list.
<P>
 By default, the SMTP server will still reject a message that contains
non-local addresses for both the sender and the receiver, even from
hosts on the inside network address list.  You can ease that restriction
with the /RELAY_ALLOWED qualifier.

<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/NETMASK=ip-netmask)
<QUALDEF>
 Specifies the network mask to be applied to the address, in dotted-decimal
form.  The default is 255.255.255.255, which indicates that the IP address
is for a host, not a network.
<QUALITEM>(/[NO]REJECT)
<QUALDEF>
 Indicates whether relay is to be rejected from the specified
host or network.  This qualifier can be used to reject SMTP relay
from particular hosts or subnetworks that are below a parent network
that is already on the inside network address list.
<QUALITEM>(/[NO]RELAY_ALLOWED)
<QUALDEF>
 Indicates that the host(s) should be allowed full relay permission; that
is, messages sent from the host(s) are allowed to contain non-local addresses
for both sender and receiver.
<P>
 This qualifier is useful when your system is acting as a central mail hub,
and there are hosts on your local network that automatically forward messages
for their local users to hosts outside your domain via an alias.  When such
messages are sent back to your system (as the mail hub), they will contain
non-local addresses for both the sender and the recipient.
<ENDQUALDEFLIST>

<COMMAND>(DEFINE LIST\\MGMT_GUIDE_65)
<x>(MCP commands<xs>DEFINE LIST)<x>(Mailing lists)

<OVERVIEW>
Creates a mailing list.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(DEFINE LIST)
<FPARMS>(list-name)
<ENDFORMAT>
<QUAL_LIST>(Command Qualifiers\Defaults\WIDE)
<QPAIR>(/[NO]ADD_MESSAGE=fspec\/NOADD_MESSAGE)
<QPAIR>(/[NO]ARCHIVE=fspec\/NOARCHIVE)
<QPAIR>(/[NO]CASE_SENSITIVE\/CASE_SENSITIVE)
<QPAIR>(/[NO]CC_POST_ERRORS\/NOCC_POST_ERRORS)
<QPAIR>(/[NO]CONFIRMATION_MESSAGE=fspec\/NOCONFIRMATION_MESSAGE)
<QPAIR>(/[NO]DESCRIPTION=text\/NODESCRIPTION)
<QPAIR>(/[NO]DIGEST\/NODIGEST)
<QPAIR>(/ERRORS_TO=address\See text)
<QPAIR>(/[NO]FORWARD_MESSAGE=fspec\/NOFORWARD_MESSAGE)
<QPAIR>(/[NO]HIDE_ERRORS_TO\/HIDE_ERRORS_TO)
<QPAIR>(/[NO]HOSTNAME=hostname\/NOHOSTNAME)
<QPAIR>(/IGNORE[=(keyword,[...])]\See text)
<QPAIR>(/[NO]LIST_HEADERS=(keyword[,...])\/NOLIST_HEADERS)
<QPAIR>(/[NO]MAXIMUM_MESSAGE_SIZE=limit\/NOMAXIMUM_MESSAGE_SIZE)
<QPAIR>(/[NO]MODERATOR=(address[,...])\/NOMODERATOR)
<QPAIR>(/[NO]NOTIFY=(keyword,[...])]\/NONOTIFY)
<QPAIR>(/OWNER=(address[,...])\)
<QPAIR>(/PRIVATE\/NOPRIVATE)
<QPAIR>(/PROTECTION=prot-spec\See text)
<QPAIR>(/[NO]RECIPIENT_MAXIMUM={DEFAULT<VBAR>n}\/RECIPIENT_MAXIMUM=DEFAULT)
<QPAIR>(/[NO]REMOVE_MESSAGE=fspec\/NOREMOVE_MESSAGE)
<QPAIR>(/REPLY_TO=(kwd[,...])\/REPLY_TO=SENDER)
<QPAIR>(/[NO]REQUEST_CONFIRMATION[=INTERVAL=delta-time]\/NOREQUEST_CONFIRMATION)
<QPAIR>(/[NO]RETURN_ADDRESS=address\See text)
<QPAIR>(/SETTINGS=(kwd[,...])\/SETTINGS=DEFAULT)
<QPAIR>(/STRIP_HEADERS=keyword\See text)
<QPAIR>(/SUBJECT_PREFIX=string\/NOSUBJECT_PREFIX)
<QPAIR>(/[NO]TEXT_ONLY\/NOTEXT_ONLY)
<QPAIR>(/XHEADERS=(string[,...])\/NOXHEADERS)
<ENDQUAL_LIST>

<PARAMDEFLIST>
<PARAMITEM>(list-name)
<PARAMDEF>
Local name to be used for the mailing list, up to 32 characters in length.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command is used to establish a mailing list.
When a message is sent to the mailing list
address, the mailing list processor forwards a copy 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.
<p>Mailing lists are fully described in <reference>(mlfguide).
<ENDDESCRIPTION>

<QUALDEFLIST>
<qualitem>(/[NO]ADD_MESSAGE=fspec)
<QUALDEF>
Specifies the name of a file to be sent to a user subscribing to the
list.  If omitted, the device and directory default to MX_MLIST_DIR:
(MX_ROOT:[MLF.MAILING_LISTS]), and the file type defaults to TXT.
<p>The default for this qualifier is /NOADD_MESSAGE, which causes the
global add message, MX_MLIST_DIR:MLIST_ADD_MESSAGE.TXT, to be sent when
a user subscribes to the list.  See <reference>(mlfguide) for more information
about notification messages.

<QUALITEM>(/[NO]ARCHIVE=fspec)
<QUALDEF>
Specify /ARCHIVE to have the mailing list messages placed in an archive
file automatically by the mailing list processor.  For <emphasis>(fspec)
you must provide at least a device/directory specification.  If the
file name is omitted, the mailing list name is used as the file name for
the archive file.  If the file type is omitted, <emphasis>(yyyy)-<emphasis>(mm)
is used as the file type, where <emphasis>(yyyy) is the current year and
<emphasis>(mm) is the number of the current month at the time a message
is added to the archive.


<QUALITEM>(/[NO]CASE_SENSITIVE)
<QUALDEF>
This qualifier enables or disables case-sensitivity with regard to
mailing list subscribers.  By default, MX treats the left-hand side of
subscriber addresses in a case-sensitive manner with regard to SIGNOFF
and SET commands.  If a list is defined /NOCASE_SENSITIVE, then the
case of subscriber addresses will be ignored.

<QUALITEM>(/[NO]CC_POST_ERRORS)
<QUALDEF>
This qualifier enables or disables copying mailing post failure
messages to the /ERRORS_TO address.  By default, if a message cannot
be forwarded to a list, an error message is sent back to the sender of
the message.  If /CC_POST_ERRORS is set, those error messages are
also sent to the /ERRORS_TO address. This lets the list owner see
attempted posts from non-subscribers and other posting failures.

<qualitem>(/[NO]CONFIRMATION_MESSAGE=fspec)
<QUALDEF>
Specifies the name of a file to be sent to a potential subscriber
when the list is set for subscription confirmation requests.
If omitted, the device and directory default to MX_MLIST_DIR:
(MX_ROOT:[MLF.MAILING_LISTS]), and the file type defaults to TXT.
<p>The default for this qualifier is /NOCONFIRMATION_MESSAGE, which causes the
global confirmation message, MX_MLIST_DIR:MLIST_CONFIRM_MESSAGE.TXT, to be sent for
any confirmation requests.  See <reference>(mlfguide) for more information
about confirmation messages.

<QUALITEM>(/[NO]DESCRIPTION=text)
<QUALDEF>
This qualifier defines a brief description for the mailing list.
This description is added to the mailing list address in the X-ListName
header on list messages.


<QUALITEM>(/[NO]DIGEST)
<QUALDEF>
This qualifier enable or disables digest support for the list.
A list marked /DIGEST can support the DIGEST flag for subscribers.
Mail sent to the "-digest" form of the list address will be forwarded
only to those subscribers marked as digest subscribers.


<QUALITEM>(/ERRORS_TO=address)
<QUALDEF>
This qualifier is used to direct error messages and mail returned to the
mailing list processor to the specified address.  If not specified, the
address of the the first specified owner of the mailing list is used.
<qualitem>(/[NO]FORWARD_MESSAGE=fspec)
<QUALDEF>
Specifies the name of a file to be sent to a user subscribing to the
list when the list does not have W:E access set.  The message should
notify the user that the subscription request was forwarded to the
list owner.
If omitted, the device and directory default to MX_MLIST_DIR:
(MX_ROOT:[MLF.MAILING_LISTS]), and the file type defaults to TXT.
<p>The default for this qualifier is /NOFORWARD_MESSAGE, which causes the
global forward-to-owner message, MX_MLIST_DIR:MLIST_FORWARD_MESSAGE.TXT,
to be sent when a user tries to subscribe.  See <reference>(mlfguide) for
more information about notification messages.

<QUALITEM>(/[NO]HIDE_ERRORS_TO)
<QUALDEF>
Controls how the mailing list processor formats the envelope FROM address
and Errors-To: header.  When a list is set /HIDE_ERRORS_TO (the default),
the address specified with the /ERRORS_TO qualifier (or the first /OWNER
address, if /ERRORS_TO is not specified) is replaced automatically
in outbound list postings by the alias <quote>(owner-<emphasis>(listname)).
Setting /NOHIDE_ERRORS_TO prevents this substitution, using the errors-to
address explicitly.

<QUALITEM>(/[NO]HOSTNAME=hostname)
<QUALDEF>
 The /HOSTNAME qualifier specifies the host name to be used for the
mailing list's address.  By default, the local MX host name is used.
An alternative host name can be used when the MX installation is being
used to provide mail service for multiple domains.  You must configure
MX to route the host name via the LOCAL path.

<QUALITEM>(/IGNORE[=(keyword,...)])
<QUALDEF>
 The /IGNORE qualifier instructs MLF to ignore postings to the mailing list
if they match the specified criteria.  The criteria keywords are
MISSING_LIST_ADDRESS and JUNK_MAIL.  These keywords are negatable.  By default,
no postings are ignored.
<P>
 Specifying the MISSING_LIST_ADDRESS criterion causes MLF to ignore
postings to the list that do not explicitly include the list's address in either
the To: or CC: header of the message.  This keyword does not take a value.
MLF performs address rewriting and alias translation on the header addresses,
so a locally-defined rewrite rule or alias that results in the mailing
list address is considered valid.
<P>
 Specifying the JUNK_MAIL criterion causes MLF to ignore postings that
contain the X-Junk-Mail-Rating: header that is inserted by the heuristic
junk-mail filter in the SMTP server.  This keyword takes a value: LOW,
MEDIUM, or HIGH, corresponding to the confidence level of the likelihood
that the message is junk mail, as entered in the
X-Junk-Mail-Rating: header by the SMTP server.  Only those messages with
the specified or higher rating are ignored; i.e., if MEDIUM is specified
as the keyword value, only those messages with MEDIUM or HIGH ratings are
ignored.

<QUALITEM>(/[NO]MAXIMUM_MESSAGE_SIZE=limit)
<QUALDEF>
The /MAXIMUM_MESSAGE_SIZE qualifier instructs MLF to reject any messages
posted to the list whose message contents (excluding headers) exceeds
<EMPHASIS>(limit) Kbytes.  Disabled by default.  Specifying zero for
<EMPHASIS>(limit) has the same effect as specifying /NOMAXIMUM_MESSAGE_SIZE.

<QUALITEM>(/[NO]LIST_HEADERS=(keyword[=value][,...]))
<QUALDEF>
The /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.

<P>
There are three valid keywords: SUBSCRIBE, UNSUBSCRIBE, and HELP.
All three accept values that are used in the creation of the actual headers,
which will be added to each message posted to the mailing list.  However,
only HELP requires a value.  If the value is omitted for SUBSCRIBE and
UNSUBSCRIBE, the proper URLs for those actions will be automatically generated
by MLF.
<P>
The List-* headers are currently a proposed Internet standard.  The
actual headers generated are X-List-Subscribe, X-List-Unsubscribe,
and X-List-Help.
<P>
Clients that support these headers (both X-List-* and List-*) will provide
click buttons to perform the specified actions (usually "mailto" URLs).
<p>
See <reference>(mlfguide) for more information on mailing list
headers.

<QUALITEM>(/[NO]MODERATOR=(address[,...]))
<QUALDEF>
This qualifier is for future use.  Moderated mailing lists are currently
not supported.

<QUALITEM>(/[NO]NOTIFY=(keyword[,...]))
<QUALDEF>
This qualifier specifies owner notification options.  Valid keywords
are ALL, ADD, REMOVE, REQUEST, and SET; descriptions are given in
<REFERENCE>(notify_kwds).  If you specify ALL, no other
keywords are allowed.  By default, no owner notifications are sent.
<TABLE>(Owner Notification Types\notify_kwds)
<TABLE_SETUP>(2\10)
<TABLE_HEADS>(Keyword\Description)
<TABLE_ROW>(ALL\Notifications sent for all events listed below.)
<TABLE_ROW>(ADD\Notification sent to owner(s) when an address is successfully
added to the list.)
<TABLE_ROW>(REMOVE\Notification sent to owner(s) when an address is
successfully removed from the list.)
<TABLE_ROW>(REQUEST\Notification sent to owner(s) when a subscription
confirmation request is sent or expired.)
<TABLE_ROW>(SET\Notification sent to owner(s) when a subscriber's
settings have been changed with a SET or MODIFY mailing list request.)
<ENDTABLE>

<QUALITEM>(/OWNER=(address[,...]))
<QUALDEF>
This qualifier specifies the addresses of one or more owners of the mailing
list.  Each mailing list must have at least one owner, who is responsible
for handling subscription requests not handled automatically by the
mailing list processor and problems with or questions about the list.


<QUALITEM>(/[NO]PRIVATE)
<QUALDEF>
This qualifier specifies that the list is private and should not be
displayed in response to DIRECTORY commands sent to the MXserver or
-Request addresses.  The list protection is not affected by this
qualifier.


<QUALITEM>(/PROTECTION=prot-spec)
<QUALDEF>
This qualifier determines the protection of the mailing list.  The
protection specification, <emphasis>(prot-spec), is identical to
a VMS file protection specification, and defaults to
(S:RWED,O:RWED,G:RWED,W:RWE).  The four protection classes are described
in <reference>(protab1) and the four protection types are described
in <reference>(protab2).
<table>(Mailing list protection classes\protab1)
<table_setup>(2\10)
<table_heads>(Class\Description)
<table_row>(SYSTEM\any address matching one of the addresses on the system
user list (see DEFINE SYSTEM_USERS))
<table_row>(OWNER\any address matching one of the owner addresses specified on
the /OWNER qualifier)
<table_row>(GROUP\any address matching one the addresses on the subscriber
list for the mailing list)
<table_row>(WORLD\any other address)
<endtable>
<P>Just as with VMS file protections, the SYSTEM and
OWNER classes are implicitly granted C (control) access, allowing them to
use the ADD and REMOVE commands to add and remove addresses from the
mailing list.
<table>(Mailing list protection codes\protab2)
<table_setup>(2\10)
<table_heads>(Code\Description)
<table_row>(R (Read)\allows the use of the REVIEW command)
<table_row>(W (Write)\allows the user to post messages to the list)
<table_row>(E (Enroll)\allows the automatic handling of the SUBSCRIBE command)
<table_row>(D (Delete)\allows the automatic handling of the SIGNOFF command)
<endtable>
<p>Note that protection code E (enroll) is only meaningful when used with the
WORLD class and that protection code D (delete) is only meaningful when used
with the GROUP class.
<p>Some typical GROUP and WORLD protection specifications are shown in
<reference>(protab3).  In most cases, you would also want to give SYSTEM
and OWNER users RWED access.
<table>(Typical protection codes\protab3)
<table_setup>(2\15)
<table_row>((G:RWED,W:RWE)\Public list.  Anyone can subscribe, sign off,
and review the list; anyone can post to the list.)
<table_row>((G:RWED,W:E)\Semi-public list.  Anyone can subscribe and
sign off the list, but only subscribers can review or post to the list.)
<table_row>((G:W,W)\Private list.  Only subscribers can post to the list,
and all subscription requests are screened by the owners of the mailing
list.)
<table_row>((G,W)\One-way list.  Only the owners can post to the list,
and they also screen all the subscription requests.)
<endtable>
<NOTE>
Since electronic mail can readily be forged, you should not depend on
this protection scheme for absolute security of your mailing lists.
The mailing list processor attempts no authentication of addresses when
it receives messages.
<ENDNOTE>

<QUALITEM>(/[NO]RECIPIENT_MAXIMUM={DEFAULT<VBAR>n})
<QUALDEF>
Specifies the maximum number of recipients to be entered per outbound
mailing list message for the list being defined.  The default setting,
/RECIPIENT_MAXIMUM=DEFAULT,
causes this setting to be taken from the SET MLF/RECIPIENT_MAXIMUM
setting.  Specifying /NORECIPIENT_MAXIMUM causes a single outbound
message to be created for each list posting, with all recipients listed.
You may also specify a postive integer for <emphasis>(n), which
instructs MLF to enter no more than <emphasis>(n) recipients in
a single message.  If the mailing list has more than <emphasis>(n)
subscribers, each list posting will cause multiple, duplicate messages
to be generated, each with no more than <emphasis>(n) recipients.

<qualitem>(/[NO]REMOVE_MESSAGE=fspec)
<QUALDEF>
Specifies 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:
(MX_ROOT:[MLF.MAILING_LISTS]), and the file type defaults to TXT.
<p>The default for this qualifier is /NOREMOVE_MESSAGE, which causes the
global remove message, MX_MLIST_DIR:MLIST_REMOVE_MESSAGE.TXT, to be sent when
a user signs off the list.  See <reference>(mlfguide) for more information
about notification messages.
<QUALITEM>(/REPLY_TO=(kwd[,...]))
<QUALDEF>
Specifies how the mailing list processor should handle Reply-To
headers. Available reply-to types are SENDER and LIST, which may be
combined. The default is SENDER, which prevents the mailing list
processor from modifying the headers. If LIST is specified, a Reply-To
header is added to list messages to re-direct replies to the mailing
list, eliminating any existing Reply-To header in the original
message.  If LIST and SENDER are both specified, a Reply-To header
containing both the mailing list address and the original Reply-To
address is added to list messages (using the From address if no
Reply-To header existed in the original message).


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

<QUALITEM>(/[NO]REQUEST_CONFIRMATION[=INTERVAL=delta-time])
<QUALDEF>
Controls whether or not subscription requests should be confirmed.
When /REQUEST_CONFIRMATION is specified, SUBSCRIBE and ADD requests
will generate a special subscription confirmation message that is
sent to the potential subscriber.  If the user replies within the
timeout interval, the subscription process is completed normally.  Otherwise, the
subscription request is dropped.  Confirmations are disabled by
default.
<P>The default timeout interval for confirmation requests is
three days (72 hours).  You can change the timeout by specifying
the INTERVAL keyword with a VMS delta-time value.

<QUALITEM>(/[NO]RETURN_ADDRESS=address)
<QUALDEF>
This qualifier is used to specify an alternate address to be used as
the <QUOTE>(Reply-To:) address when /REPLY_TO=LIST is specified.
This qualifier is most useful when multiple lists should have a common
return address.  For example, it can be used to redirect replies to a
<QUOTE>(-Digest) list back to the non-digest address.

<QUALITEM>(/SETTINGS=(keyword[,...]))
<QUALDEF>
The /SETTINGS qualifier is used to override the default subscriber settings for
a list.  The valid keywords are MAIL, REPRO, CONCEAL, DIGEST, POST, and their
"NO" forms.
<P>
A special keyword, DEFAULT, can be used to reset the settings
to the MLF default for a mailing list.  The default settings for a list
are MAIL, REPRO, NOCONCEAL, NODIGEST, and POST.

<QUALITEM>(/STRIP_HEADERS=keyword)
<QUALDEF>
This qualifier is used to strip certain RFC822 headers from messages
posted to a mailing list.


<P>
The following keywords are supported:

<LIST>(UNNUMBERED)
<LE>	RECEIVED and NORECEIVED
<LE>	OTHER and NOOTHER
<ENDLIST>


<CP>When /STRIP_HEADERS=RECEIVED is set, the <QUOTE>(Received:) headers are
stripped from the incoming message before it is mailed out to the list
subscribers, thereby reducing the total number of <QUOTE>(Received:)
headers in the final message.  


<P>
When /STRIP_HEADERS=OTHER is set, all <QUOTE>(other) headers are stripped
from posts.  The <QUOTE>(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 /STRIP_HEADERS=OTHER handily
gets around potential problems with subscribers using the DOS package
Pegasus Mail, which will send message receipt messages back to a list.
Note that this may not be a viable setting for a mailing list that is
gatewayed to a newsgroup, depending on the gateway software, since
headers used by the gateway may be omitted.
<p>
See <reference>(mlfguide) for more information on mailing list
headers.

<QUALITEM>(/[NO]SUBJECT_PREFIX="string")
<QUALDEF>
The /SUBJECT_PREFIX qualifier can be used to add a prefix to the
Subject line of messages posted to the list.  By default, no prefix is
added.  When the list is set to /REPLY_TO=(SENDER), a short prefix
string may be supplied to help subscribers recognize mailing list
messages.  The given string is bracketed by square brackets ([]) when
it is prefixed to the subject lines.  The maximum length for the
prefix string is 32 characters.  Prefix strings should be kept short
to avoid generating extremely long subject lines.

<QUALITEM>(/[NO]TEXT_ONLY)
<QUALDEF>
Controls whether or not the mailing list processor should accept only
plain-text messages for list postings.  If /TEXT_ONLY is specified,
the mailing list processor examines the Content-Type: header on all
list postings, if present, and ensures that the specified content
type is <quote>(text/plain).  Messages with no Content-Type: header
are assumed to be plain-text. Rejected postings are returned to
sender with an error message indicating that the list is configured
to accept text messages only.

<P>
By default, no content type checking is performed on list postings.

<QUALITEM>(/[NO]XHEADERS=("string"[,...]))
<QUALDEF>
The /XHEADERS qualifier can be used to add additional site-specific headers
to mailing list posts.  For example, you can use /XHEADERS to add additional
non-standard "X-List-" headers such as "X-List-Archives".  The format of the
header string is: "Keyword: text".  For example, "Precedence: Bulk", which
is a non-standard header used by some mailers.
<P>
Extreme care should be taken when adding additional headers to mailing lists
to ensure that duplicate headers or improperly formatted headers
(those that don't comply with RFC 822) aren't added to mailing list posts.
<p>
See <reference>(mlfguide) for more information on mailing list
headers.


<ENDQUALDEFLIST>

<COMMAND>(DEFINE LOCAL_DOMAIN\\deflcldom)
<x>(MCP commands<xs>DEFINE LOCAL_DOMAIN)<x>(SMTP local domains)
<OVERVIEW>
Defines a host name or wildcard pattern as a <quote>(local) domain
for the SMTP server.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(DEFINE LOCAL_DOMAIN)
<FPARMS>(name-or-pattern)
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(name-or-pattern)
<PARAMDEF>
A host name or a string containing VMS-style wildcard
characters against which an SMTP host name should be matched.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command is used in conjunction with the SMTP server's
/NORELAY setting to establish domains that the SMTP server
considers local, to prevent messages to or from these
domains from being refused.  When relaying in the SMTP server
is disabled, it refuses to deliver messages to remote mailboxes
when the originating mailbox is also remote.  By default, the
SMTP server considers any mailbox resolving to a LOCAL path,
or with a host name sharing the same parent domain as the
MX host name or TCP/IP host name, as being local.  If your
system is acting as a gateway for hosts in other domains, and
you disable SMTP relaying, you should list the names of those
other hosts, or a wildcard pattern that will match those
names, in a DEFINE LOCAL_DOMAIN command, to ensure that
messages coming from or going to those hosts will not be
refused.
<P>
You may specify multiple local domains by using multiple
DEFINE LOCAL_DOMAIN commands.  Only one name or wildcard
pattern is accepted per command.  Use the REMOVE LOCAL_DOMAIN
command to delete domains from the local-domain list.
<ENDDESCRIPTION>

<COMMAND>(DEFINE PATH\\MGMT_GUIDE_66)
<x>(MCP commands<xs>DEFINE PATH)<x>(Domain/path mapping)

<OVERVIEW>
Defines a mapping between a domain name and a distribution path.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(DEFINE PATH)
<FPARMS>(domain-name  path-name)
<QUAL_LIST>
<QPAIR>(/ROUTE=host-name[@port-number]\)
<ENDQUAL_LIST>
<ENDFORMAT>
<PARAMDEFLIST>
<PARAMITEM>(domain-name)
<PARAMDEF>
A domain name or pattern containing VMS wildcards.
<PARAMITEM>(path-name)
<PARAMDEF>
One of the supported MX path names: LOCAL, SMTP, SITE,
DECNET_SMTP, or HOLDING_QUEUE=<EMPHASIS>(n).
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command is used to associate a domain name and a distribution path.
The Router uses this information to determine which distribution path should
be used when routing mail messages.  Each DEFINE PATH command adds a path
definition to the list.  The list is automatically sorted based on the length
of the path and the presence of wildcards.
The Router searches this list
until the domain name of the address it is trying to 
route to matches the domain name or wildcard pattern of the path definition.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/ROUTE=host-name[@port-number])
<QUALDEF>
Specifies the name of a host that will route messages for the specified domain.
For SMTP and HOLDING_QUEUE paths, this host name <emphasis>(must) directly
resolve to an IP address; it cannot be the name that has only MX information
in the Domain Name System.
<P>For SMTP and HOLDING_QUEUE paths, you may specify a TCP port number to
be used instead of the default SMTP port (25) when connecting to the specified
host by appending an at-sign <QUOTE>(@) and the port number (as a decimal integer)
to the host name on this qualifier.
<endqualdeflist>

<COMMAND>(DEFINE REWRITE_RULE\\MGMT_GUIDE_67)
<x>(MCP commands<xs>DEFINE REWRITE_RULE)<X>(rewrite rules)

<OVERVIEW>
Defines an address-rewriting rule for use by the Router.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(DEFINE REWRITE_RULE)
<FPARMS>(pattern result)
<ENDFORMAT>
<QUAL_LIST>
<QPAIR>(/REGEX\)
<ENDQUAL_LIST>

<PARAMDEFLIST>
<PARAMITEM>(pattern)
<PARAMDEF>
An RFC 821-compliant address string, possibly with the addition of one
or more substitution strings, or a regular expression (if the /REGEX
qualifier is specified).  The address string must include the opening
and closing angle brackets.  Any address matching <emphasis>(pattern)
will be rewritten by the Router based on the <emphasis>(result) string.
<PARAMITEM>(result)
<PARAMDEF>
An RFC 821-compliant address string, possibly with the addition of one
or more substitution strings or (if the /REGEX qualifier is specified)
subexpression references.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command is used to provide the Router with rules for transforming
some addresses into other forms.  The <emphasis>(pattern) string is
an address string that must be matched to have the transformation apply.
For example:
<interactive>
<s>(MCP> )<u>(DEFINE REWRITE_RULE "<{user}@{host}.DECnet.mycompany.com>" -)
<s>(_MCP> )<u>(                    "<""{host}::{user}""@myhost.mycompany.com>")
<endinteractive>
<p>The strings <quote>({user}) and <quote>({host}) are called
<newterm>(substitution strings).  They are identified by the curly braces
surrounding the substitution name, which you may specify arbitrarily.
In the <emphasis>(pattern) string, a substitution string matches any
number of any characters, like the asterisk in a VMS wildcard pattern.
The matched string can be substituted into the rewritten address by specifying
the same substitution string in the <emphasis>(result) string, or it may
be omitted.
<p>Rewriting rules can be used when the DEFINE PATH/ROUTE command is
inadequate, such as when a message must pass through two or more
gateways to get to its destination, or when the rewrite affects both
the local-part and the domain-part of an address.
They should be used sparingly, however, since
every address must be matched against the rewrite rules list.
<p>The rewrite rules list is searched in the order you specify, so you
should place more specific rules before more general rules.  For
non-regular-expression rules, pattern matching is done from right to left.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/REGEX)
<QUALDEF>
Specifies that the rewrite rule uses UNIX-style regular expression matching instead
of substitution strings.  Regular expressions provide more sophisticated
matching capabilities; see <REFERENCE>(REGEX_DOC) for more information.  When
using regular expressions, substitutions are performed by enclosing matching
subexpressions in parentheses in the pattern string and referencing those
subexpressions with <QUOTE>(<BACKSLASH><EMPHASIS>(n)) in the result string.
<P>
For example, the rewrite rule mentioned in the Description section above
could be written using regular expressions as:
<interactive>
<s>(MCP> )<u>(DEFINE REWRITE_RULE/REGEX "<([[:username:]]+)@([[:domain:]]+)<BACKSLASH>.DECnet<BACKSLASH>.mycompany<BACKSLASH>.com>" -)
<s>(_MCP> )<u>(                         "<""<BACKSLASH>2::<BACKSLASH>1""@myhost.mycompany.com>")
<endinteractive>
<CP>
Regular expressions use a syntax that can be difficult to understand.  MCP
will flag regular expressions that do not compile properly, but you should
be careful to test your rewrite rules to ensure that they execute properly.
<ENDQUALDEFLIST>

<COMMAND>(DEFINE SYSTEM_USERS\\MGMT_GUIDE_68)
<x>(MCP commands<xs>DEFINE SYSTEM_USERS)

<OVERVIEW>
Defines the address to be given SYSTEM access to mailing lists.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(DEFINE SYSTEM_USERS)
<FPARMS>(address[,...])
<ENDFORMAT>
<PARAMDEFLIST>
<PARAMITEM>(address[,...])
<PARAMDEF>
One or more addresses, separated by commas.  Each of the users identified
by these addresses will be considered <quote>(system) users by the mailing
list processor, and granted access via the SYSTEM protection class to
all mailing lists.  Case is important only in the username portion of
the address.  To retain the case of the address, surround it with quotation
marks.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command is used to provide the mailing list processor with a
list of privileged users.  These users are granted access to mailing lists
via the SYSTEM protection class, and are also given CONTROL access to all
mailing lists.  They receive all messages sent to MXserver that cannot
be handled automatically by the mailing list processor.
<p>The first address on the SYSTEM_USER list is used as the return address
for generic MXserver replies (those replies that are not about a specific
mailing list).  For this reason, you may want to specify an alias as
the first system user.
<P>Typically only the system manager and/or postmaster for the system
should be identified as system users.  This will allow them to control
a mailing list on the system when the owners of the list cannot be contacted.
<ENDDESCRIPTION>


<COMMAND>(EXIT\\MGMT_GUIDE_69)
<x>(MCP commands<xs>EXIT)

<OVERVIEW>
Exits MCP.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(EXIT)
<FPARMS>()
<ENDFORMAT>

<DESCRIPTION>
Use this command to leave MCP.  If you have modified the MX configuration,
it is saved before exiting.  If the configuration file has not been named,
you are prompted for a file name before exiting.
<ENDDESCRIPTION>

<COMMAND>(HELP\\MGMT_GUIDE_70)
<x>(MCP commands<xs>HELP)

<OVERVIEW>
Displays help information.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(HELP)
<FPARMS>([topic...])
<ENDFORMAT>
<PARAMDEFLIST>
<PARAMITEM>(topic)
<PARAMDEF>
The name of a topic in the help library.  If omitted, a list of topics
is displayed.
<ENDPARAMDEFLIST>

<COMMAND>(MODIFY\\MGMT_GUIDE_71)
<x>(MCP commands<xs>MODIFY)

<OVERVIEW>
Modifies existing configuration information.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(MODIFY)
<FPARMS>(<list>(stacked\braces)
<le>ALIAS  alias  new-fwdaddr
<LE>FILE_SERVER  fsrv-name
<LE>LIST  list-name
<LE>PATH  domain  new-path
<LE>REWRITE_RULE  pattern  new-result
<endlist>)
<ENDFORMAT>

<DESCRIPTION>
This 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
appropriate DEFINE command for further information.
<ENDDESCRIPTION>

<COMMAND>(MODIFY USER\\mcp_cmd_mod_user)
<x>(MCP commands<xs>MODIFY USER)
<OVERVIEW>
Modifies a user's password in the SMTP authentication database.
<ENDOVERVIEW>
<FORMAT>
<FCMD>(MODIFY USER)
<FPARMS>(username)
<ENDFORMAT>
<QUAL_LIST>
<QPAIR>(/PASSWORD=password-text\/PASSWORD=<QUOTE>(PASSWORD))
<ENDQUAL_LIST>

<PARAMDEFLIST>
<PARAMITEM>(username)
<PARAMDEF>
The username whose password is to be modified.  Usernames may be up to
16 characters in length, and are case-sensitive.  To specify a lowercase
or mixed-case username, surround it with quotation marks.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command modifies an entry in the SMTP authentication database.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/PASSWORD=password-text)
<QUALDEF>
Specifies a password for this username.  Passwords can contain any characters,
and are case-sensitive.  They may be up to 64 characters in length.
assigned.
<ENDQUALDEFLIST>


<COMMAND>(QUEUE CANCEL\\qcancmd)
<x>(MCP commands<xs>QUEUE CANCEL)

<OVERVIEW>
Cancels one or more queue entries.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE CANCEL)
<FPARMS>([entry-number,...])
<QUAL_LIST>
<QPAIR>(/[NO]LOG\/NOLOG)
<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(entry-number)
<PARAMDEF>
Queue entry number to be cancelled.  If the number of a base queue entry,
all related agent-specific entries will also be cancelled.
<P>
If this parameter is omitted, all entries selected by the last QUEUE SELECT
command are cancelled.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command sets the status of the specified queue entries to CANCELLED,
which prevents further processing of the entries.  This should only be
done on entries which are not currently being processed by the Router
or one of the delivery agents.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/[NO]LOG)
<QUALDEF>
Causes a message to be displayed for each cancelled entry.  The default
is /NOLOG.
<ENDQUALDEFLIST>


<COMMAND>(QUEUE COMPRESS\\qcompresscmd)
<x>(MCP commands<xs>QUEUE COMPRESS)

<OVERVIEW>
Compress the message queue file.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE COMPRESS)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/MAXIMUM_ENTRIES=value\None.)
<QPAIR>(/[NO]LOG\/NOLOG)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
Shrinks the message queue file by creating a new file and
renumbering all the existing entries in the file.  This command may be
used to create a smaller message queue, which affects the maximum number of
entries allowed in the queue.
<P>
The /MAXIMUM_ENTRIES qualifier is required.
<P>
This command requires exclusive access to the MX message queue file.
Before compressing the file, all MX agents must either be shut down or
inactive.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/MAXIMUM_ENTRIES=number-of-entries)
<QUALDEF>
Specifies the maximum number of queue entries to be allowed.  MX will not
allow more entries to be added to the queue than the specified value.
MCP QUEUE EXTEND can be used to increase the number of allowed entries.

<P>
The size of the queue file in blocks is equal to the maximum number of
entries, plus 10 blocks, plus whatever is added for the disk cluster.

<QUALITEM>(/[NO]LOG)
<QUALDEF>
Causes a status message to be displayed after successful operation.
Default is /NOLOG.
<ENDQUALDEFLIST>


<COMMAND>(QUEUE CREATE\\qcreatecmd)
<x>(MCP commands<xs>QUEUE CREATE)

<OVERVIEW>
Create a message queue file.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE CREATE)
<FPARMS>([filespec])
<QUAL_LIST>
<QPAIR>(/MAXIMUM_ENTRIES=value\None.)
<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(filespec)
<PARAMDEF>
Name of the queue control file to be created.  If omitted, the default
name, MX_FLQ_DIR:MX_SYSTEM_QUEUE.FLQ_CTL, is used.
<ENDPARAMDEFLIST>

<DESCRIPTION>
Creates a new, empty MX message queue file. The /MAXIMUM_ENTRIES qualifier is
required.

<NOTE>
This command simply creates a new queue file; the existing queue file is not
automatically deleted.  Any files for any existing queue entries are also
left in place.
<ENDNOTE>
<P>
This command requires exclusive access to the MX message queue file.
Before compressing the file, all MX agents must either be shut down or
inactive.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/MAXIMUM_ENTRIES=number-of-entries)
<QUALDEF>
Specifies the maximum number of queue entries to be allowed.  MX will not
allow more entries to be added to the queue than the specified value.
MCP QUEUE EXTEND can be used to increase the number of allowed entries.

<P>
The size of the queue file in blocks is equal to the maximum number of
entries, plus 10 blocks, plus whatever is added for the disk cluster.
<ENDQUALDEFLIST>


<COMMAND>(QUEUE DUMP\\qdumpcmd)
<x>(MCP commands<xs>QUEUE DUMP)

<OVERVIEW>
Dumps the contents and envelope of a message to a set of
text files for editing.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE DUMP)
<FPARMS>(entry-number)
<QUAL_LIST>
<QPAIR>(/[NO]CANCEL\/CANCEL)
<QPAIR>(/OUTPUT=file-spec\)
<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(entry-number)
<PARAMDEF>
Number of the queue entry to be dumped.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command creates a set of files that can be used to
modify message headers and/or recipient addresses for
any pending (IN-PROGRESS or READY) message currently in
the queue.
<P>
The output files are suitable for use with the MX_SITE_IN
program so the message can be requeued after being dumped.
By default, the three files are placed in the current
default directory, named as shown in <REFERENCE>(qdumptbl).
<TABLE>(QUEUE DUMP Output Files\qdumptbl)
<TABLE_SETUP>(2\15)
<TABLE_HEADS>(File name\Description)
<TABLE_ROW>(ENTRY_<EMPHASIS>(n).RECIPIENTS\List of recipient
            addresses, one per line.)
<TABLE_ROW>(ENTRY_<EMPHASIS>(n).MSG_TEXT\Full text of message,
            including RFC822 headers.)
<TABLE_ROW>(REQUEUE_<EMPHASIS>(n).COM\Command procedure for
            invoking MX_SITE_IN to requeue the message.)
<ENDTABLE>
<CP>
You can modify the directory and/or base filename of the output
files with the /OUTPUT qualifier.
<ENDDESCRIPTION>


<QUALDEFLIST>
<QUALITEM>(/[NO]CANCEL)
<QUALDEF>
Specifies whether or not the dumped queue entry should be
cancelled. The dumped entry is automatically cancelled on successful
completion of a QUEUE DUMP command, unless /NOCANCEL is specified.

<QUALITEM>(/OUTPUT=file-spec)
<QUALDEF>
Specifies the device, directory, and/or base filename for the output
files.  The file type and version fields are not permitted with this
qualifier.  By default, the output files are placed in the current
directory, with names as shown in <REFERENCE>(qdumptbl).
<ENDQUALDEFLIST>


<COMMAND>(QUEUE EXTEND\\qextendcmd)
<x>(MCP commands<xs>QUEUE EXTEND)

<OVERVIEW>
Extends the message queue file.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE EXTEND)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/MAXIMUM_ENTRIES=value\None.)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
Extends the existing message queue file to allow more entries to be in the
queue at any given time.
<P>
The /MAXIMUM_ENTRIES qualifier is required.
<P>
This command requires exclusive access to the MX message queue file.
Before compressing the file, all MX agents must either be shut down or
inactive.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/MAXIMUM_ENTRIES=number-of-entries)
<QUALDEF>
Specifies the maximum number of queue entries to be allowed.  MX will not
allow more entries to be added to the queue than the specified value.
MCP QUEUE EXTEND can be used to increase the number of allowed entries.

<P>
The size of the queue file in blocks is equal to the maximum number of
entries, plus 10 blocks, plus whatever is added for the disk cluster.
<ENDQUALDEFLIST>

<COMMAND>(QUEUE HOLD\\qholdcmd)
<x>(MCP commands<xs>QUEUE HOLD)

<OVERVIEW>
Places a queue entry on hold.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE HOLD)
<FPARMS>([entry-number,...])
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(entry-number)
<PARAMDEF>
Number of the queue entry to be held.
<P>
If this parameter is omitted, all entries selected by the last QUEUE SELECT
command are held.
<ENDPARAMDEFLIST>

<DESCRIPTION>
THis command places a queue entry on hold, so it will not be processed.
Use the QUEUE READY command to release the entry for processing.
<ENDDESCRIPTION>



<COMMAND>(QUEUE PURGE\\qpurcmd)
<x>(MCP commands<xs>QUEUE PURGE)

<OVERVIEW>
Purges the message queue of finished and cancelled entries.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE PURGE)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/[NO]LOG\/NOLOG)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
This command searches the message queue for all entries of
FINISH or CANCELLED status and deletes them from the queue.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/[NO]LOG)
<QUALDEF>
Causes a message to be displayed for each deleted entry.  The default
is /NOLOG.
<ENDQUALDEFLIST>

<COMMAND>(QUEUE READY\\qrdycmd)
<x>(MCP commands<xs>QUEUE READY)

<OVERVIEW>
Readies a queue entry.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE READY)
<FPARMS>([entry-number,...])
<QUAL_LIST>
<QPAIR>(/AFTER=date-time\)
<QPAIR>(/FINAL\)
<QPAIR>(/[NO]LOG\/NOLOG)
<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(entry-number)
<PARAMDEF>
Queue entry number to be readied.  If the number of a base queue entry,
the base entry will be readied and
all existing agent-specific entries will be cancelled.
<P>
If this parameter is omitted, all entries selected by the last QUEUE SELECT
command are held.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command sets the status of the specified queue entries to READY
and clears the delay flag.  This should only be
done on entries which are not currently being processed by the Router
or one of the delivery agents.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/AFTER=date-time)
<QUALDEF>
Specifies a date and time after which the entry should be processed.
Without this qualifier, the entry is readied for immediate processing.
<QUALITEM>(/FINAL)
<QUALDEF>
Specifies that the entry should be readied for a final attempt by
the delivery agent.  This
qualifier causes the retry counts to be set to their maximum value
before the entry is readied.  This will cause the agent to attempt to deliver
the message just once; if the delivery fails, the message will be
returned to sender.
<P>Use this qualifier to force a message to be <quote>(bounced) when
you know that delivery to the intended recipient(s) is impossible.
<QUALITEM>(/[NO]LOG)
<QUALDEF>
Causes a message to be displayed for each readied entry.  The default
is /NOLOG.
<ENDQUALDEFLIST>

<COMMENT>
<COMMAND>(QUEUE RECLAIM\\qrclcmd)
<x>(MCP commands<xs>QUEUE RECLAIM)

<OVERVIEW>
Performs a CONVERT/RECLAIM on the message queue indexed file.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE RECLAIM)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/[NO]LOG\/NOLOG)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
This command executes a CONVERT/RECLAIM on the indexed file that is
used to trace message queue entries.  This will reclaim empty buckets
that are left when entries are deleted from the queue.  This command should
generally be used only when all of the MX processing agents are shut down.

<P>
<X>(Performance<XS>Reclaiming file queue)
This function is periodically performed by the Router process; manual
queue reclaims should not be needed except in unusual circumstances. 
If you find that the queuing system is continually performing poorly,
requiring frequent manual reclaims to speed it up, then you should
define MX_FLQ_RECLAIM_WAIT to be a smaller value, as described in
<reference>(qclnlognams).

<note>
This command requires exclusive access to the queue control file, and
will fail if it cannot acquire that access.  This is normal when the
MX processing agents are running, and when users are sending messages
via MX from VMS Mail.


<P>
If a user tries to send a mail message via MX when the Router is
performing the reclaim pass, an error message is displayed informing
the user that the MX system queue is locked for maintenance and to try
again.

<endnote>
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/[NO]LOG)
<QUALDEF>
Causes a status message to be displayed after successful operation, giving
statistics on the number of buckets reclaimed.  Default is /NOLOG.
<ENDQUALDEFLIST>
<ENDCOMMENT>

<COMMAND>(QUEUE SELECT\\qselcmd)
<x>(MCP commands<xs>QUEUE SELECT)

<OVERVIEW>
Selects queue entries.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE SELECT)
<FPARMS>( )
<QUAL_LIST>
<QPAIR>(/BEFORE=time\)
<QPAIR>(/CREATED\)
<QPAIR>(/DELAY\)
<QPAIR>(/DESTINATION_AGENT=agent\)
<QPAIR>(/EXPIRE\)
<QPAIR>(/HELD\)
<QPAIR>(/IN_PROGRESS\)
<QPAIR>(/MODIFIED\)
<QPAIR>(/ORIGIN_AGENT=agent\)
<QPAIR>(/SINCE=time\)
<QPAIR>(/WAITING\)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
This command builds a list of queue entries based on a combination
of selection criteria that you specify.  Subsequent QUEUE CANCEL,
QUEUE HOLD, and QUEUE READY commands will use this selection list if
you do not specify entry numbers on those commands.
<P>
You can display the selected queue entries with the QUEUE SHOW/SELECTED
command.
<ENDDESCRIPTION>

<QUALDEFLIST>

<QUALITEM>(/BEFORE[=time])
<QUALDEF>
Selects only those entries dated before the specified time.   You can
specify time as an absolute time, a combination of absolute and delta
times, or as one of the following keywords: TODAY (default), TOMORROW,
or YESTERDAY. Specify one of the following qualifiers with the /BEFORE
qualifier to indicate the time attribute to be used as the basis for
selection: /CREATED (default), /DELAY, /EXPIRE, or /MODIFIED.

<QUALITEM>(/CREATED)
<QUALDEF>
Modifies the time value specified with the /BEFORE or the /SINCE
qualifier. The /CREATED qualifier selects entries based on their dates
of creation. 

<QUALITEM>(/DELAY)
<QUALDEF>
Modifies the time value specified with the /BEFORE or the /SINCE
qualifier. The /DELAY qualifier selects entries based on their delay
dates.

<QUALITEM>(/DESTINATION_AGENT=agent)
<QUALDEF>
Selects only those entries that are to be or have been processed by
the specified MX agent.  Valid keywords are: ROUTER, MLF, LOCAL, SMTP,
SITE, DNSMTP, and HOLDING_QUEUE=<EMPHASIS>(n).

<QUALITEM>(/EXPIRE)
<QUALDEF>
Modifies the time value specified with the /BEFORE or the /SINCE
qualifier. The /EXPIRE qualifier selects entries based on their dates
of expiration. 

<QUALITEM>(/HELD)
<QUALDEF>
Selects only those entries that are in USER-HOLD or OPER-HOLD state.

<QUALITEM>(/IN_PROGRESS)
<QUALDEF>
Displays only entries marked as being in-progress (INPROG).

<QUALITEM>(/MODIFIED)
<QUALDEF>
Modifies the time value specified with the /BEFORE or the /SINCE
qualifier. The /MODIFIED qualifier selects entries based on their
dates of modification. 

<QUALITEM>(/ORIGIN_AGENT=agent)
<QUALDEF>
Selects only those entries that were entered into the queue by the
specified MX agent.  Valid keywords are: LOCAL, SMTP,
SITE, MAIL, and DNSMTP.

<QUALITEM>(/SINCE[=time])
<QUALDEF>
Selects only those entries dated after the specified time.   You can
specify time as an absolute time, a combination of absolute and delta
times, or as one of the following keywords: TODAY (default), TOMORROW,
or YESTERDAY. Specify one of the following qualifiers with the /SINCE
qualifier to indicate the time attribute to be used as the basis for
selection: /CREATED (default), /DELAY, /EXPIRE, or /MODIFIED.


<QUALITEM>(/WAITING)
<QUALDEF>
Selects only those entries with READY status.
<ENDQUALDEFLIST>


<COMMAND>(QUEUE SHOW\\qshocmd)
<x>(MCP commands<xs>QUEUE SHOW)

<OVERVIEW>
Displays queue entries.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE SHOW)
<FPARMS>([entry-number,...])
<QUAL_LIST>
<QPAIR>(/ALL\)

<QPAIR>(/BEFORE=time\)

<QPAIR>(/BRIEF\)

<QPAIR>(/CREATED\)
<QPAIR>(/DATE\)
<QPAIR>(/DELAY\)
<QPAIR>(/DESTINATION_AGENT=agent\)
<QPAIR>(/EXPIRE\)

<QPAIR>(/FULL\)
<QPAIR>(/HELD\)
<QPAIR>(/IN_PROGRESS\)
<QPAIR>(/MODIFIED\)
<QPAIR>(/ORIGIN_AGENT=agent\)

<QPAIR>(/OUTPUT=file-spec\)
<QPAIR>(/SELECTED\)
<QPAIR>(/SINCE=time\)

<QPAIR>(/WAITING\)
<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(entry-number)
<PARAMDEF>
Queue entry number to be displayed.  If omitted, all READY and IN-PROGRESS
entries are displayed.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command displays entries in the message queue.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/ALL)
<QUALDEF>
Causes all queue entries to be displayed, regardless of status.  If
omitted, just the READY and IN-PROGRESS entries are displayed.


<QUALITEM>(/BEFORE[=time])
<QUALDEF>
Selects only those entries dated before the specified time.   You can
specify time as an absolute time, a combination of absolute and delta
times, or as one of the following keywords: TODAY (default), TOMORROW,
or YESTERDAY. Specify one of the following qualifiers with the /BEFORE
qualifier to indicate the time attribute to be used as the basis for
selection: /CREATED (default), /DELAY, /EXPIRE, or /MODIFIED.


<QUALITEM>(/BRIEF)
<QUALDEF>
Causes a brief listing of all the queue entries to be displayed,
including those that have finished or been cancelled.  The information
displayed is taken only from the MX queue file and includes the target
MX process for each entry.


<QUALITEM>(/CREATED)
<QUALDEF>
Modifies the time value specified with the /BEFORE or the /SINCE
qualifier. The /CREATED qualifier selects entries based on their dates
of creation. 

<QUALITEM>(/DATE)
<QUALDEF>
Causes the creation and modification dates to be displayed for each
queue entry.

<QUALITEM>(/DELAY)
<QUALDEF>
Modifies the time value specified with the /BEFORE or the /SINCE
qualifier. The /DELAY qualifier selects entries based on their delay
dates.

<QUALITEM>(/DESTINATION_AGENT=agent)
<QUALDEF>
Selects only those entries that are to be or have been processed by
the specified MX agent.  Valid keywords are: ROUTER, MLF, LOCAL, SMTP,
SITE, DNSMTP, and HOLDING_QUEUE=<EMPHASIS>(n).
This qualifier is most useful when used with /BRIEF.

<QUALITEM>(/EXPIRE)
<QUALDEF>
Modifies the time value specified with the /BEFORE or the /SINCE
qualifier. The /EXPIRE qualifier selects entries based on their dates
of expiration. 


<QUALITEM>(/FULL)
<QUALDEF>
Provides more details about the displayed entries, including intended
recipients, error counts, and last error status messages.  If omitted,
a brief, one-line display is produced for each entry.

<QUALITEM>(/HELD)
<QUALDEF>
Selects only those entries that are in USER-HOLD or OPER-HOLD state.

<QUALITEM>(/IN_PROGRESS)
<QUALDEF>
Displays only entries marked as being in-progress (INPROG).

<QUALITEM>(/MODIFIED)
<QUALDEF>
Modifies the time value specified with the /BEFORE or the /SINCE
qualifier. The /MODIFIED qualifier selects entries based on their
dates of modification. 

<QUALITEM>(/ORIGIN_AGENT=agent)
<QUALDEF>
Selects only those entries that were entered into the queue by the
specified MX agent.  Valid keywords are: LOCAL, SMTP,
SITE, MAIL, and DNSMTP.


<QUALITEM>(/OUTPUT=file-spec)
<QUALDEF>
Directs the results to the specified file.  If omitted, the results are
displayed on SYS$OUTPUT.

<QUALITEM>(/SELECTED)
<QUALDEF>
Displays entries selected by the last QUEUE SELECT command.  If this
qualifier is specified, no other selection qualifiers or entry numbers
may specified.

<QUALITEM>(/SINCE[=time])
<QUALDEF>
Selects only those entries dated after the specified time.   You can
specify time as an absolute time, a combination of absolute and delta
times, or as one of the following keywords: TODAY (default), TOMORROW,
or YESTERDAY. Specify one of the following qualifiers with the /SINCE
qualifier to indicate the time attribute to be used as the basis for
selection: /CREATED (default), /DELAY, /EXPIRE, or /MODIFIED.


<QUALITEM>(/WAITING)
<QUALDEF>
Limits the display to only those entries with READY status.
<ENDQUALDEFLIST>


<COMMAND>(QUEUE STATISTICS\\qstaticmd)
<x>(MCP commands<xs>QUEUE STATISTICS)

<OVERVIEW>
Displays statistical information concerning the entries in the MX
message queue.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE STATISTICS)
<FPARMS>()
<ENDFORMAT>

<DESCRIPTION>
This command displays the total number of entries in the queue, the
maximum number of entries possible for the queue file, the percentage
of entries in use, and the largest entry number ever used during the
life of the file.
<ENDDESCRIPTION>

<COMMAND>(QUEUE SYNCHRONIZE\\qsynchcmd)
<x>(MCP commands<xs>QUEUE SYNCHRONIZE)

<OVERVIEW>
Synchronizes the message queue bitmap with the actual entries in the
queue.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUEUE SYNCHRONIZE)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/LOG)
<QPAIR>(/RESET)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
This command updates the bitmap for the MX system message queue to
synchronize it with the actual entries in the queue. The only time
this command may be necessary is in the event of a system crash or
disk failure.
<P>
The command may be issued at any time; it does not require exclusive
access to the MX message queue file.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/LOG)
<QUALDEF>
Causes a status message to be displayed after successful operation.
Default is /NOLOG.

<QUALITEM>(/RESET)
<QUALDEF>
Resets the <QUOTE>(Highest entry used) counter displayed by QUEUE
STATISTICS.  By default, the counter is not reset.
<ENDQUALDEFLIST>

<COMMAND>(QUIT\\MGMT_GUIDE_72)
<x>(MCP commands<xs>QUIT)

<OVERVIEW>
Leaves MCP without saving any configuration changes.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(QUIT)
<FPARMS>()
<ENDFORMAT>

<DESCRIPTION>
Use this command leave MCP without saving any of the changes made to
the MX configuration.  If the configuration was changed, MCP will ask for
confirmation before returning to DCL.
<ENDDESCRIPTION>

<COMMAND>(REMOVE\\MGMT_GUIDE_73)
<x>(MCP commands<xs>REMOVE)

<OVERVIEW>
Removes a configuration record.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(REMOVE)
<FPARMS>(<list>(stacked\braces)
<le>ALIAS  alias
<LE>FILE_SERVER  fileserv-name
<LE>INSIDE_NETWORK_ADDRESS ip-address
<LE>LIST  list-name
<LE>LOCAL_DOMAIN  name-or-pattern
<LE>PATH  domain
<LE>REWRITE_RULE  pattern
<endlist>)
<ENDFORMAT>

<DESCRIPTION>
This command removes one record of the specified type from the MX
configuration.  The specified alias, inside network address,
list name, domain, rejection rule,
or rewrite rule pattern must match exactly the identical field in the 
record to be removed.
<P>
When removing an inside network address, you must also specify
the /NETMASK qualifier when the address is for a network rather than
a host.
<ENDDESCRIPTION>

<COMMAND>(REMOVE USER\\mcp_cmd_rem_user)
<x>(MCP commands<xs>REMOVE USER)
<OVERVIEW>
Removes an entry from the SMTP authentication database.
<ENDOVERVIEW>
<FORMAT>
<FCMD>(REMOVE USER)
<FPARMS>(username)
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(username)
<PARAMDEF>
The username to be removed from the database.  Usernames may be up to
16 characters in length, and are case-sensitive.  To specify a lowercase
or mixed-case username, surround it with quotation marks.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command removes an entry in the SMTP authentication database.  Once
removed, an SMTP client can no longer user the username to authenticate
to the SMTP server.  The authentication sequence will be rejected, and
any messages sent by the client will be subject to normal anti-relay and
anti-junk-mail processing (if the client is on an <quote>(outside) network).
<ENDDESCRIPTION>

<COMMAND>(RESET\\MGMT_GUIDE_74)
<x>(MCP commands<xs>RESET)

<OVERVIEW>
Sends a reset signal to one or more delivery agents.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(RESET)
<FPARMS>([agent-name...])
<QUAL_LIST>
<QPAIR>(/ACCOUNTING\)
<QPAIR>(/CLUSTER\/CLUSTER)

<QPAIR>(/NODE[=(node,...)]\/CLUSTER)

<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(agent-name...)
<PARAMDEF>
One or more MX delivery agent names, separated by commas.  Valid names
are DECNET_SMTP, LOCAL, MLF, ROUTER, SITE, SMTP, 
and HOLDING_QUEUE=(<EMPHASIS>(n),...).
If omitted, all agents running on the same node as the user
executing this command are reset.
<ENDPARAMDEFLIST>

<DESCRIPTION>
The RESET command can be used to signal one or more MX delivery agents
to reload their configuration information. 
<emphasis>(This command requires the SYSLCK privilege.\BOLD)
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/ACCOUNTING)
<QUALDEF>
Causes the specified agents to open new versions of their accounting files.
Only useful for those agents that support accounting, and with MLF (which
causes a new version of FILESERV_LOG.LOG to be opened).
<p>If /ACCOUNTING is specified, no reload of configuration data is performed;
only the accounting files are reset.
<QUALITEM>(/CLUSTER)
<QUALDEF>
Specifies that the RESET command should affect all of the
specified agents cluster-wide, rather than just the ones on the
node from which the command is executed.  This is the default behavior
for RESET; use /NODE to have the reset affect agents on specific nodes
in the cluster.


<QUALITEM>(/NODE[=(node,...)])
<QUALDEF>
Specifies that the RESET command should affect only the specified agents
running on the given nodes.  If no node names are specified, the local node
is used by default.  If this qualifier is omitted, all agents cluster-wide
are reset.

<ENDQUALDEFLIST>

<COMMAND>(REVIEW\\rvwcmd)
<x>(MCP commands<xs>REVIEW)

<OVERVIEW>
Displays the subscribers of a local mailing list.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(REVIEW)
<FPARMS>(mailing-list)
<QUAL_LIST>
<QPAIR>(/OUTPUT=file-spec\)
<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(mailing-list)
<PARAMDEF>
Name of the mailing list whose subscriber list is to be displayed.  The mailing
list must reside on the local system.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command performs the functional equivalent of the mailing list processor's
REVIEW command for any mailing list on the local system.  All subscribers'
addresses and personal names (if any) listed, along with their MAIL/NOMAIL
status.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/OUTPUT=file-spec)
<QUALDEF>
Directs the results to the specified file.  If omitted, the results are
displayed on SYS$OUTPUT.
<ENDQUALDEFLIST>


<COMMAND>(SAVE\\MGMT_GUIDE_75)
<x>(MCP commands<xs>SAVE)

<OVERVIEW>
Saves the current configuration to a file.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(SAVE)
<FPARMS>(file-spec)
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(file-spec)
<PARAMDEF>
The name of the file to which the configuration is written.  If omitted,
the file type defaults to MXCFG.
<ENDPARAMDEFLIST>

<DESCRIPTION>
Use this command to write the MX configuration you are creating or
changing to a file.  You should save the configuration to the file
MX_DIR:MX_CONFIG.MXCFG if you want it to be used by the MX processing
agents.
<ENDDESCRIPTION>

<COMMAND>(SET DECNET_SMTP\\setdncmd)
<x>(MCP commands<xs>SET DECNET_SMTP)
<OVERVIEW>
Alters settings specific to the SMTP-over-DECnet delivery agent.
<endoverview>

<FORMAT>
<FCMD>(SET DECNET_SMTP)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/[NO]ACCOUNTING\)
<QPAIR>(/MAXIMUM_RETRIES=count\)
<QPAIR>(/RETRY_INTERVAL=delta-time\)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
This command is used to change the SMTP-over-DECnet agent settings.
<ENDDESCRIPTION>

<QUALDEFLIST>
<qualitem>(/[NO]ACCOUNTING)
<QUALDEF>
Enables or disables the recording of accounting information.  Accounting
is disabled by default.  When enabled, accounting information is
written to the file MX_DNSMTP_DIR:MX_DNSMTP_ACC.DAT.  You can redirect
the accounting information to another file by defining the logical
name MX_DNSMTP_ACC.
<p>The format of the accounting record is:
<interactive>(WIDE)
dd-mmm-yyyy hh:mm XMIT: PROTO=DECNET_SMTP, SOURCE="src-addr", HOST="host", BYTES_SENT=n
<endinteractive>
<p>where
<keyword>(dd-mmm-yyyy hh:mm) is the date/time stamp of the accounting record;
<keyword>(src-addr) is the source address for the message;
<keyword>(host) is the host to which the message was sent; and
<keyword>(n) is the number of bytes in the delivered message.

<QUALITEM>(/MAXIMUM_RETRIES=count)
<QUALDEF>
Sets the maximum number of retries for message delivery.  The
default count is 96, which for a half-hour retry interval comes to roughly
two days of retries.

<QUALITEM>(/RETRY_INTERVAL=delta-time)
<QUALDEF>
Sets the amount of time that should elapse between delivery
attempts.  The default is 30 minutes.  Specify as a VMS delta time value.
<ENDQUALDEFLIST>


<COMMAND>(SET LOCAL\\MGMT_GUIDE_77)
<x>(MCP commands<xs>SET LOCAL)
<OVERVIEW>
Alters Local-delivery-specific settings.
<endoverview>

<FORMAT>
<FCMD>(SET LOCAL)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/[NO]ACCOUNTING\/NOACCOUNTING)
<QPAIR>(/[NO]CC_POSTMASTER\/NOCC_POSTMASTER)
<QPAIR>(/[NO]DISABLE_EXQUOTA[=FATAL]\/NODISABLE_EXQUOTA)
<QPAIR>(/[NO]HEADERS=(loc:(hdrname[,...])[,...])\)
<QPAIR>(/[NO]LONG_LINES\/NOLONG_LINES)
<QPAIR>(/MAXIMUM_RETRIES=count\See text)
<QPAIR>(/[NO]MULTIPLE_FROM\/MULTIPLE_FROM)
<QPAIR>(/[NO]OMIT_RESENT_HEADERS\/NOOMIT_RESENT_HEADERS)
<QPAIR>(/[NO]QP_DECODE\/QP_DECODE)
<QPAIR>(/RETRY_INTERVAL=delta-time\See text)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
This command is used to change the local delivery agent settings.
<ENDDESCRIPTION>

<QUALDEFLIST>
<qualitem>(/[NO]ACCOUNTING)
<QUALDEF>
Enables or disables the recording of accounting information.  Accounting
is disabled by default.  When enabled, accounting information is
written to the file MX_LOCAL_DIR:MX_LOCAL_ACC.DAT.  You can redirect
the accounting information to another file by defining the logical
name MX_LOCAL_ACC.
<p>The format of the accounting record is:
<interactive>
dd-mmm-yyyy hh:mm DELIVER: SOURCE="src-addr", USER="user", SIZE=n
<endinteractive>
<p>where
<keyword>(dd-mmm-yyyy hh:mm) is the date/time stamp of the accounting record;
<keyword>(src-addr) is the source address for the message;
<keyword>(user) is the address on the local host to which the message
was delivered; and
<keyword>(n) is the number of bytes in the delivered message.


<QUALITEM>(/[NO]CC_POSTMASTER)
<QUALDEF>
Specifies whether or not error messages resulting from LOCAL delivery
errors are mailed to the local POSTMASTER, in addition to the original
message sender.

<QUALITEM>(/[NO]DISABLE_EXQUOTA[=FATAL])
<QUALDEF>
Specifies whether the local delivery agent should disable the EXQUOTA
privilege when attempting to deliver messages to VMS MAIL.  By default,
EXQUOTA privilege remains enabled during local message delivery.  Using
the /DISABLE_EXQUOTA qualifier will prevent users' mailboxes from exceeding
their diskquotas.  In addition, specifying the FATAL keyword on this qualifier
will cause MX to treat an over-quota condition as a non-recoverable error and
immediately return any messages causing the condition to sender.  If FATAL is
not specified, over-quota conditions are treated as transient errors and will
be retried (subject to the /RETRY_INTERVAL and /MAXIMUM_RETRIES settings).


<qualitem>(/HEADERS=(loc:(hdrname[,...])[,...]))
<QUALDEF>
Controls the inclusion and placement of RFC 822 headers in messages
delivered to VMS Mail.  Valid values for <keyword>(loc) are
TOP and BOTTOM.  Valid values for <keyword>(hdrname) are listed
in <reference>(hdrnamtab).
<table>(Header name keywords\hdrnamtab)
<table_setup>(2\20)
<table_heads>(Keyword\Meaning)
<table_row>(ALL\All headers.)
<table_row>(BCC\The Bcc (blind carbon copy) header.)
<table_row>(CC\The CC (carbon copy) header.)
<table_row>(DATE\The Date header.)
<table_row>(FROM\The From header.)
<table_row>(IN_REPLY_TO\The In-Reply-To header.)
<table_row>(KEYWORDS\The Keywords header (not strictly RFC 822).)
<table_row>(MESSAGE_ID\The Message-Id header.)
<table_row>(OTHER\Any header not recognized by MX.)
<table_row>(RECEIVED\The Received header(s).)
<table_row>(REFERENCES\The References header (not strictly RFC 822).)
<table_row>(REPLY_TO\The Reply-To header.)
<table_row>(RESENT_BCC\The Resent-Bcc header.)
<table_row>(RESENT_CC\The Resent-CC header.)
<table_row>(RESENT_DATE\The Resent-Date header.)
<table_row>(RESENT_FROM\The Resent-From header.)
<table_row>(RESENT_MESSAGE_ID\The Resent-Message-Id header.)
<table_row>(RESENT_REPLY_TO\The Resent-Reply-To header.)
<table_row>(RESENT_SENDER\The Resent-Sender header.)
<table_row>(RESENT_TO\The Resent-To header.)
<table_row>(RETURN_PATH\The Return-Path header.)
<table_row>(SENDER\The Sender header.)
<table_row>(SUBJECT\The Subject header.)
<table_row>(TO\The To header.)
<endtable>
<p>The header names can be negated by prefixing them with NO.  You may
include any combination of headers for inclusion at the top and/or the
end of the message.  For example, you might want to move the Received
and Return-Path headers to the bottom of messages, since the information
they convey are of interest only when there are network problems:
<interactive>
<s>(MCP> )<u>(SET LOCAL/HEADERS=<oparen>TOP:<oparen>ALL,NORECEIVED,NORETURN_PATH<cparen>,-)
<S>(_MCP> )<U>(                   BOTTOM:<oparen>NOALL,RECEIVED,RETURN_PATH<cparen><cparen>)
<endinteractive>

<QUALITEM>(/[NO]LONG_LINES)
<QUALDEF>
Enables support for delivery of messages containing lines longer than
the MAIL-11 maximum of 511 characters for non-DECnet addresses.  When enabled,
the local delivery agent will only truncate lines at 511 characters when
the destination address contains a colon (indicating that the recipient is
a DECnet address).  Disabled by default.
<NOTE>
When /LONG_LINES is enabled, delivery to DECnet addresses through VMS MAIL
aliases (either in the forwarding database or through logical names) may
fail because MX cannot determine that such aliased addresses should be treated
as DECnet deliveries rather than local deliveries.
<ENDNOTE>

<QUALITEM>(/MAXIMUM_RETRIES=count)
<QUALDEF>
Sets the maximum number of retries for DECnet message delivery.  The
default count is 96, which for a half-hour retry interval comes to roughly
two days of retries.

<QUALITEM>(/[NO]MULTIPLE_FROM)
<QUALDEF>
Controls whether or not the VMS Mail <QUOTE>(From:) line on incoming
messages can contain multiple return addresses.  By default, if an
RFC822 From: or Reply-To: line contains more than one address, as many
of those addresses as will fit are included on the VMS Mail <QUOTE>(From:)
line (up to 255 characters).  Specifying /NOMULTIPLE_FROM limits the
<QUOTE>(From:) line to a single address.

<QUALITEM>(/[NO]OMIT_RESENT_HEADERS)
<QUALDEF>
Controls whether or not Resent- headers should be omitted when
the local delivery agent performs forwarding due to a VMS MAIL
forwarding database entry containing an MX% address.  By default,
Resent- headers are included; this helps MX detect forwarding loops.
However, some PC e-mail clients treat Resent- headers in a confusing
way, so omitting them may be desirable.

<QUALITEM>(/[NO]QP_DECODE)
<QUALDEF>
Controls whether or not incoming MIME quoted-printable messages are
automatically decoded by MX Local before delivery through VMS Mail. 
By default, such messages are decoded.  If your users read their mail
via POP or IMAP, you might want to disable the decoding to let the
users' browsers do the decoding.

<QUALITEM>(/RETRY_INTERVAL=delta-time)
<QUALDEF>
Sets the amount of time that should elapse between delivery
attempts.  The default is 30 minutes.  Specify as a VMS delta time value.
<ENDQUALDEFLIST>

<COMMAND>(SET MLF\\SET_MLF_CMD)
<x>(MCP commands<xs>SET MLF)
<x>(MLF agent<xs>settings)
<OVERVIEW>
Alters MLF (Mailing List/File server) settings.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(SET MLF)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/[NO]DELAY_DAYS[=(dow...)]\)
<QPAIR>(/[NO]RECIPIENT_MAXIMUM[=n]\)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
This command sets global parameters for the Mailing List/File
Server agent (MLF).
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/[NO]DELAY_DAYS[=(dow...)])
<QUALDEF>
 Specifies the days of the week on which file servers'
send-delay threshold should be respected.  The default is
to respect send-delay thresholds on every day of the week.
A list of day-of-week names may be specified.
Specify /NODELAY_DAYS to globally disable send-delay thresholds
on all file servers.
<QUALITEM>(/[NO]RECIPIENT_MAXIMUM[=n])
<QUALDEF>
 Sets the maximum number of recipients per message generated
by the MLF agent.  If your MLF agent services large mailing
lists with many remote subscribers, you may want to use this
setting to limit the number of recipients per message generated
by MLF.  This will break up the distribution to the mailing list
into smaller chunks, allowing for more parallelism in delivery.
<P>Setting too small a value, however, could create a lengthy backlog
in your MX message queue, depending on the number of subscribers
on your mailing list(s) and the number of messages the list receives
each day.
<P>The default is /NORECIPIENT_MAXIMUM, which forces each incoming
mailing list message to be forwarded as just one outbound message.
<ENDQUALDEFLIST>

<COMMAND>(SET ROUTER\\MGMT_GUIDE_78)
<x>(MCP commands<xs>SET ROUTER)
<OVERVIEW>
Alters Router-specific settings.
<endoverview>

<FORMAT>
<FCMD>(SET ROUTER)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/[NO]ACCOUNTING\)
<QPAIR>(/[NO]OMIT_VMSMAIL_SENDER\)
<QPAIR>(/[NO]PERCENT_HACK\)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
This command is used to enable or disable the automatic de-hacking of
percent signs in a local address.  Percent-hacking is explained in
<reference>(altran).
<ENDDESCRIPTION>

<QUALDEFLIST>

<QUALITEM>(/[NO]ACCOUNTING)
<QUALDEF>
Enables or disables the recording of accounting information.  Accounting
is disabled by default.  When enabled, accounting information is
written to the file MX_ROUTER_DIR:MX_ROUTER_ACC.DAT.  You can redirect
the accounting information to another file by defining the logical
name MX_ROUTER_ACC.
<p>The format of the accounting record is one of the following:
<interactive>(WIDE)
dd-mmm-yyyy hh:mm ROUTE: SENDER="src-addr", RCPT="rcp-addr", ROUTE="host", PATH=path, BYTES=n
dd-mmm-yyyy hh:mm BOUNCE: SENDER="src-addr", RCPT="rcp-addr", ORIGRCPT="orcp-addr", ERROR="errmsg"
<endinteractive>
<p>where
<keyword>(dd-mmm-yyyy hh:mm) is the date/time stamp of the accounting record;
<keyword>(src-addr) is the source address for the message;
<keyword>(rcp-addr) is the recipient's address;
<keyword>(orcp-addr) is the recipient's address before it was changed by any rewrite rules;
<keyword>(host) is the host route associated with the matching path;
<keyword>(path) is the delivery path (agent) that will deliver the message;
<keyword>(errmsg) is the text of the error message describing why routing failed; and
<keyword>(n) is the number of bytes in the delivered message.

<QUALITEM>(/[NO]OMIT_VMSMAIL_SENDER)
<QUALDEF>
Enables or disables the omission of the Sender: header for messages
sent from VMS Mail.  Normally, a Sender: line is included if the
Sender: and From: addresses are different.  However, some sites using
the MX_SITE_NAME_CONVERSION feature with the FULL_CONVERT routine have
had problems sending mail to some mailers when the Sender: and From:
are different, despite the fact that it is allowed by RFC822 (in fact,
according to RFC822, the Sender: should be omitted if it is the same
address as the From: address).  To allow those sites to work around
the problems with those mailers, /OMIT_VMSMAIL_SENDER can be used to
omit the Sender: line in all cases.

<P>
MX_SITE_NAME_CONVERSION is documented in the <REFERENCE>(progguide).

<NOTE>
If /OMIT_VMSMAIL_SENDER is specified, then the Sender: line is also
omitted from any SMTP messages forwarded by users with the MX_FAKE_RFC822
process rights identifier.
<ENDNOTE>


<QUALITEM>(/[NO]PERCENT_HACK)
<QUALDEF>
Enables or disables automatic percent-hack translation.  The default
is to enable translation.
<ENDQUALDEFLIST>

<COMMAND>(SET SITE\\setsitecmd)
<x>(MCP commands<xs>SET SITE)
<OVERVIEW>
Alters settings specific to the SITE delivery agent.
<endoverview>

<FORMAT>
<FCMD>(SET SITE)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/MAXIMUM_RETRIES=count\)
<QPAIR>(/RETRY_INTERVAL=delta-time\)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
This command is used to change the SITE agent settings.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/MAXIMUM_RETRIES=count)
<QUALDEF>
Sets the maximum number of retries for message delivery.  The
default count is 96, which for a half-hour retry interval comes to roughly
two days of retries.

<QUALITEM>(/RETRY_INTERVAL=delta-time)
<QUALDEF>
Sets the amount of time that should elapse between delivery
attempts.  The default is 30 minutes.  Specify as a VMS delta time value.
<ENDQUALDEFLIST>


<COMMAND>(SET SMTP\\MGMT_GUIDE_79)
<x>(MCP commands<xs>SET SMTP)
<OVERVIEW>
Alters SMTP-delivery-specific settings.
<endoverview>

<FORMAT>
<FCMD>(SET SMTP)
<FPARMS>()
<QUAL_LIST>
<QPAIR>(/[NO]ACCOUNTING\)
<QPAIR>(/[NO]AUTHENTICATION=(type,...)\/NOAUTHENTICATION)
<QPAIR>(/DEFAULT_ROUTER=hostname\)
<QPAIR>(/DNS_RETRIES=dnscount\)
<QPAIR>(/MAXIMUM_RETRIES=count\)
<QPAIR>(/[NO]PERCENT_HACK\/PERCENT_HACK)
<QPAIR>(/[NO]RBL_CHECK[=(domain,...)]\)
<QPAIR>(/[NO]RELAY_ALLOWED\/RELAY_ALLOWED)
<QPAIR>(/RETRY_INTERVAL=delta-time\)
<QPAIR>(/[NO]VALIDATE_SENDER_DOMAIN\)
<QPAIR>(/[NO]VERIFY_ALLOWED\)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
This command is used to change the SMTP interface settings.
<ENDDESCRIPTION>

<QUALDEFLIST>
<qualitem>(/[NO]ACCOUNTING)
<QUALDEF>
Enables or disables the recording of accounting information.  Accounting
is disabled by default.  When enabled, accounting information is
written to the file MX_SMTP_DIR:MX_SMTP_ACC.DAT.  You can redirect
the accounting information to another file by defining the logical
name MX_SMTP_ACC.
<p>The format of the accounting record is:
<interactive>(wide)
dd-mmm-yyyy hh:mm XMIT: PROTO=SMTP, SOURCE="src-addr", HOST="dest", SENT-TO="relay", BYTES_SENT=n, RCPT=rcp-addr
<endinteractive>
<p>where 
<keyword>(src-addr) is the source address for the message;
<keyword>(dest) is the name of the Internet host to which the message was directed;
<keyword>(relay) is the name of the Internet host to which the message was actually sent;
<keyword>(n) is the number of bytes transmitted; and
<keyword>(rcp-addr) is the recipient's address.  One accounting message is
written for each successful delivery of a message, so one message could result
in multiple accounting records.

<QUALITEM>(/[NO]AUTHENTICATION=(type,...))
<QUALDEF>
Enables or disables the authentication extension in the SMTP server.
The default is /NOAUTHENTICATION; when turned off, the extension is not
advertised by the server to any clients.  Supported values for <EMPHASIS>(type)
are CRAM_MD5 and PLAIN.
<P>
CRAM_MD5 enables the use of the CRAM-MD5 authentication mechanism,
using the private authentication database maintained through the CREATE
USER_DATABASE_FILE, ADD USER, and REMOVE USER commands in MCP.
<P>
PLAIN enables the use of the PLAIN and LOGIN authentication mechanisms,
using the VMS SYSUAF as the authentication source for usernames and passwords.


<QUALITEM>(/DEFAULT_ROUTER=hostname)
<QUALDEF>
Specifies the name of a host to which SMTP messages can be forwarded if MX
cannot resolve a host name.  This qualifier should only be used if you are
not using the Internet domain name service.  The <keyword>(hostname) should be
the name of a host which appears in your local host table.

<QUALITEM>(/DNS_RETRIES=dnscount)
<QUALDEF>
Sets the maximum number of retries for SMTP delivery when the cause
of the failure is the inability to determine the address corresponding
to a host name.  Certain types of domain server failures can cause MX
to believe a host name is invalid.  When a host name is genuinely invalid,
however, the sender should be told relatively quickly.  Therefore, the
default count is 12 (giving about 6 hours' worth of attempts for a
half-hour retry interval).

<QUALITEM>(/MAXIMUM_RETRIES=count)
<QUALDEF>
Sets the maximum number of retries for SMTP message delivery.  The
default count is 96, which for a half-hour retry interval comes to roughly
two days of retries.

<QUALITEM>(/[NO]PERCENT_HACK)
<QUALDEF>
Controls whether the SMTP server accepts or rejects recipient addresses
containing a percent sign in the username portion of the address (sometimes
used to route messages through other systems).  By
default, such addresses are accepted.  Unlike SET ROUTER/NOPERCENT_HACK,
which disables the percent-hack only for local addresses, SET SMTP/NOPERCENT_HACK
causes the SMTP server to reject <EMPHASIS>(all) addresses with a
percent sign in the username part of the address, regardless of whether
or not the hostname part of the address is local or remote.

<QUALITEM>(/[NO]RBL_CHECK[=(domain,...)])
<QUALDEF>
Controls whether the SMTP server checks to see if a connecting host is on
one or more Internet Realtime Blackhole Lists (RBLs) before allowing it to start
an SMTP session.  This is disabled by default.  You must specify at least one
RBL domain when enabling this check. Multiple domains may be specified.
<P>See <reference>(rblsection) for more information about the Realtime
Blackhole List.

<QUALITEM>(/[NO]RELAY_ALLOWED)
<QUALDEF>
Controls whether the SMTP server accepts <quote>(relayed) messages.  A
relayed message is a message from a remote source that lists recipients
that are also remote.  Relaying is allowed by default.
<P>
When relaying is disabled, the SMTP server examines the originator's address
on each incoming message as well as each recipient's address.  If both
addresses are remote, delivery to the remote recipient(s) is refused.
By default, any address that maps to a LOCAL path is considered local,
as is any host name that shares the same parent domain as the MX host name
or the TCP/IP host name.  You may specify other host or domain names
that should also be considered local with the DEFINE LOCAL_DOMAIN command.

<QUALITEM>(/RETRY_INTERVAL=delta-time)
<QUALDEF>
Sets the amount of time that should elapse between delivery
attempts.  The default is 30 minutes.  Specify as a VMS delta time value.

<QUALITEM>(/[NO]VALIDATE_SENDER_DOMAIN)
<QUALDEF>
Enables or disables a check by the SMTP server on the validity of
the domain name appearing in the SMTP MAIL FROM: command on incoming
messages.  When enabled, the SMTP server attempts
to look up the domain name of the sender in the domain name system;
if the name does not appear in the DNS (with any type of resource
record), the MAIL FROM command, and hence the incoming message, will
is rejected.  This setting is disabled by default.
<P>Enabling this option can be useful in preventing unwanted junk
e-mail from entering your system, since junk e-mail is often sent
using fictitious return addresses, sometimes with nonexistent
domain names.

<QUALITEM>(/[NO]VERIFY_ALLOWED)
<QUALDEF>
Enables or disables the processing of VRFY commands in the SMTP server.
The VRFY command, a required command in the SMTP protocol, is often used
by users on other systems to check whether or not a particular mailbox
is valid.  This information can be regarded as a security risk, and
security-conscious system administrators may want to prevent VRFY commands
from being processed.
<P>By default, VRFY commands are allowed.
<ENDQUALDEFLIST>

<COMMAND>(SHOW\\MGMT_GUIDE_80)
<x>(MCP commands<xs>SHOW)

<OVERVIEW>
Displays all or part of the current MX configuration.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(SHOW)
<FPARMS>(<list>(stacked\braces)
<le>ALIASES [pattern]
<LE>CONFIGURATION_FILE
<LE>DECNET_SMTP
<LE>FILE_SERVER [pattern]
<LE>KEY [key]
<LE>LISTS [pattern]
<le>LOCAL
<LE>PATHS [pattern]
<LE>REWRITE_RULES [pattern]
<le>ROUTER
<LE>SITE
<le>SMTP
<LE>SYSTEM_USERS
<LE>USERS [pattern]
<LE>VERSION
<LE>ALL
<endlist>)
<QUAL_LIST>
<QPAIR>(/BRIEF\/FULL)
<QPAIR>(/[NO]COMMAND\/NOCOMMAND)
<QPAIR>(/FULL\/FULL)
<QPAIR>(/OUTPUT=file-spec\/OUTPUT=SYS$OUTPUT:)
<ENDQUAL_LIST>
<ENDFORMAT>

<DESCRIPTION>
The SHOW command displays the specified parts of the current MX
configuration.  For aliases, file servers, lists, paths, and rewrite rules,
only those records matching <emphasis>(pattern) (which may contain wildcard
characters) are displayed;
if you omit <emphasis>(pattern), all records are displayed.
<p>SHOW 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.
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/BRIEF)
<QUALDEF>
The /BRIEF qualifier indicates that the display should be formatted
in an abbreviated format.  The default is to display full information.
This qualifier only affects SHOW LISTS output; the brief and full
displays are identical for other SHOW commands.

<QUALITEM>(/[NO]COMMAND)
<QUALDEF>
The /COMMAND qualifier indicates that the display should be formatted as
the commands that would be entered to create the specified records.
Use /COMMAND with the /OUTPUT qualifier to create an MCP command file
that can be altered with your favorite editor, then read back into MCP
to create a new configuration.

<QUALITEM>(/FULL)
<QUALDEF>
The /FULL qualifier indicates that full information should be
displayed.  This is the default.
This qualifier only affects SHOW LISTS output; the brief and full
displays are identical for other SHOW commands.

<QUALITEM>(/OUTPUT=file-spec)
<QUALDEF>
The /OUTPUT qualifier is used to direct the SHOW result to a file or other
device.  By default, the result is displayed on the current output device,
SYS$OUTPUT.
<ENDQUALDEFLIST>

<COMMAND>(SHUTDOWN\\MGMT_GUIDE_81)
<x>(MCP commands<xs>SHUTDOWN)

<OVERVIEW>
Sends a shutdown signal to one or more delivery agents.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(SHUTDOWN)
<FPARMS>([agent-name...])
<QUAL_LIST>
<QPAIR>(/CLUSTER\/NODE)

<QPAIR>(/NODE[=(node,...)]\/NODE)
<QPAIR>(/[NO]WAIT\/NOWAIT)
<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(agent-name...)
<PARAMDEF>
One or more MX delivery agent names, separated by commas.  Valid names
are DECNET_SMTP, LOCAL, MLF, ROUTER, SITE, SMTP,
SMTP_SERVER, and HOLDING_QUEUE=(<EMPHASIS>(n),...).
If omitted, all agents running on the same node as the user executing this
command are shut down.

<P>Note that the SMTP delivery agent may be shut down separately from the
SMTP_SERVER message entry agent.
<ENDPARAMDEFLIST>

<DESCRIPTION>
The SHUTDOWN command can be used to signal one or more MX delivery agents
to finish processing and exit.  <emphasis>(This command requires the
SYSLCK privilege.\BOLD)
<ENDDESCRIPTION>

<QUALDEFLIST>
<QUALITEM>(/CLUSTER)
<QUALDEF>
Specifies that the SHUTDOWN command should affect the specified agents
on all nodes in the cluster, not just the current node.


<QUALITEM>(/NODE[=(node,...)])
<QUALDEF>
Specifies that the SHUTDOWN command should affect the specified agents
only on the given nodes.  If /NODE is specified with no node names,
agents on the local node are shut down; this is the default behavior.

<QUALITEM>(/[NO]WAIT)
<QUALDEF>
Specifies whether or not MCP should wait until the agent(s) have responded
to the shutdown notification before continuing.  The default is /NOWAIT.

<ENDQUALDEFLIST>

<COMMAND>(SPAWN\\mcp_cmd_spawn)
<x>(MCP commands<xs>SPAWN)
<OVERVIEW>
Spawns a subprocess.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(SPAWN)
<FPARMS>([dcl-command])
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(dcl-command)
<PARAMDEF>
A DCL command to be executed in the subprocess.  If omitted,
MCP is suspended and the terminal is attached to the
subprocess for interactive entry of commands.  To return
to the process running MCP, use the DCL LOGOUT command to
end the subprocess.
<ENDPARAMDEFLIST>

<DESCRIPTION>
This command creates a subprocess to execute one or more DCL
commands.  See the description of the DCL SPAWN command for
further information.
<ENDDESCRIPTION>

<COMMAND>(STATUS\\cmd_status)
<x>(MCP commands<xs>STATUS)

<OVERVIEW>
Displays a list of the MX agent processes currently running
and the current state of each agent process.
<ENDOVERVIEW>

<FORMAT>
<FCMD>(STATUS)
<FPARMS>([agent-name...])
<QUAL_LIST>

<QPAIR>(/NODE=(node[,...])\)

<ENDQUAL_LIST>
<ENDFORMAT>

<PARAMDEFLIST>
<PARAMITEM>(agent-name...)
<PARAMDEF>
One or more MX agent names, separated by commas.  Valid names are
DECNET_SMTP, LOCAL, MLF, ROUTER, SITE, SMTP, and SMTP_SERVER.
If omitted, information about all agents is
displayed.
<ENDPARAMDEFLIST>

<DESCRIPTION>
For each process running one of the MX agent programs, the process ID,
process name, MX status, and MX agent type is displayed.  In a
VMScluster environment, the VMScluster node name for the process is
also displayed.
<emphasis>(This command requires the SYSLCK privilege.\BOLD)

<P>
The status field indicates the action currently being performed by the
agent.  Valid status descriptions are shown in
<REFERENCE>(MCP_STATUS_TABLE).

<TABLE>(MCP STATUS Descriptions\MCP_STATUS_TABLE)
<TABLE_SETUP>(2\15)
<TABLE_ROW>(Unknown\Current status is not known.)
<TABLE_ROW>(Reading Config.\Reading the MX configuration file.)
<TABLE_ROW>(Idle\Process is idle, waiting for an entry to process.)
<TABLE_ROW>(Enabling\Requesting single agent enable lock.)
<TABLE_ROW>(Selecting\Searching in-memory queue for an entry to process.)
<TABLE_ROW>(Searching\Searching in-memory queue for an entry to process.)
<TABLE_ROW>(Locating\Initializing the in-memory queue by searching the
		MX queue file for entries to be processed by that agent.)
<TABLE_ROW>(Searching2\Searching in-memory queue for located entries.)
<TABLE_ROW>(Processing\Processing the specified entry.)
<TABLE_ROW>(Retrying\Retrying delivery of the specified entry.)
<TABLE_ROW>(Inserting\Inserting a new queue entry.)
<TABLE_ROW>(Search. for wait\Searching for delayed entries.)
<TABLE_ROW>(Waiting for\Idle, waiting to process the specified entry.)
<TABLE_ROW>(Req update\Requesting other agents to update an entry.)
<TABLE_ROW>(FLQ Cleanup\Performing MX queue file maintenance.)
<TABLE_ROW>(FLQread wait\Waiting for a read from the MX queue file.)
<TABLE_ROW>(Wlock wait\Waiting for entry work lock.)
<TABLE_ROW>(Connected\SMTP Server has the specified number of incoming
		connections active.)
<ENDTABLE>
<ENDDESCRIPTION>


<QUALDEFLIST>
<QUALITEM>(/NODE=(node[,...]))
<QUALDEF>
Specifies that the STATUS command should show only the specified agents
running on the given nodes.
<ENDQUALDEFLIST>


<ENDCOMMAND_SECTION>
<part>
<part_page>
<title>(REJMAN Command Dictionary)
<endpart_page>(RENUMBER)
<INCLUDE>(MX_SRC_MCP:REJMAN_HELP.SDML)

<PART>
<PART_PAGE>
<TITLE>(Appendices)
<ENDPART_PAGE>(RENUMBER)
<APPENDIX>(Regular Expressions\REGEX_DOC)

<P>
MX uses <quote>(extended) regular expressions as defined in the
POSIX 1003.2 standard.  This appendix provides a brief description of
the syntax of regular expressions and how they work.
<NOTE>
MX regular expression matching is case-insensitive and supports only
the ASCII character set.
<ENDNOTE>
<HEAD1>(Specifying Regular Expressions\specregex)
<P>A regular expression (RE) is one or more non-empty <NEWTERM>(branches),
separated by vertical bars.  A string matching one of the branches is
a considered a match for the RE.
<P>A branch consists of one or more <NEWTERM>(pieces), concatenated.
A string matching the first piece, followed by the second, etc., is
considered to match the branch.
<P>A piece is an <NEWTERM>(atom) possibly followed by one of the elements
listed in <REFERENCE>(atom_sequencers).
<TABLE>(Atom Sequencing Terms\atom_sequencers)
<TABLE_SETUP>(2\10)
<TABLE_HEADS>(Term\Description)
<TABLE_ROW>(*\Matches zero or more occurrences of the atom.)
<TABLE_ROW>(+\Matches one or more occurrences of the atom.)
<TABLE_ROW>(?\Matches zero or one occurrence of the atom.)
<TABLE_ROW>({<EMPHASIS>(count)}\Matches exactly <EMPHASIS>(count) occurrences of the atom.)
<TABLE_ROW>({<EMPHASIS>(min),}\Matches <EMPHASIS>(min) or more occurrences of the atom.)
<TABLE_ROW>({<EMPHASIS>(min),<EMPHASIS>(max)}\Matches <EMPHASIS>(min) to <EMPHASIS>(max) occurrences of the atom, inclusive.)
<ENDTABLE>
<P>An atom consists of an ordinary character, a <NEWTERM>(bracket expression) (explained below), or one of
the special matching sequences show in <REFERENCE>(atoms).
<TABLE>(Atom Sequences\atoms)
<TABLE_SETUP>(2\10)
<TABLE_HEADS>(Atom\Description)
<TABLE_ROW>(<OPAREN><CPAREN>\Matches the null string.)
<TABLE_ROW>(.\Matches any single character.)
<TABLE_ROW>(^\Matches the null string at the beginning of a line.)
<TABLE_ROW>($\Matches the null string at the end of a line.)
<TABLE_ROW>(<BACKSLASH><EMPHASIS>(c)\Matches the character <EMPHASIS>(c), even if it is one of the
special characters used for one of the other matching sequences.)
<ENDTABLE>
<P>A bracket expression typically matches exactly one of a set of characters; the matching set is enclosed
in square brackets.  Within the brackets, you may enumerate the characters of the set individually or use
one of the collating element specifiers described in <REFERENCE>(bracket_expressions).
<TABLE>(Collating Elements in Bracket Expressions\bracket_expressions)
<TABLE_SETUP>(2\10)
<TABLE_HEADS>(Specifier\Description)
<TABLE_ROW>(<EMPHASIS>(a)-<EMPHASIS>(b)\Matches the range of characters between <EMPHASIS>(a) and <EMPHASIS>(b), inclusive.)
<TABLE_ROW>(^\If the first character in a bracket expression, inverts the meaning; that is, the bracket expression matches
any of the characters <EMPHASIS>(not\bold) in the set.)
<TABLE_ROW>([:<EMPHASIS>(class):]\Matches any character in the named class.  See <REFERENCE>(char_classes) for a description
of the supported character classes.)
<TABLE_ROW>([:<:]\Matches the null string at the beginning of a word.)
<TABLE_ROW>([:>:]\Matches the null string at the beginning of a word.)
<TABLE_ROW>([.<EMPHASIS>(chars).]\Matches the specified string of characters as a single unit.)
<ENDTABLE>
<CP>To include a right bracket in a bracket expression set, place it at the beginning of the set
(immediately after the opening left bracket or <QUOTE>(^)).
<P>MX recognizes the character class names shown in <REFERENCE>(char_classes).  Only ASCII characters are recognized.
<TABLE>(Character Classes\char_classes)
<TABLE_SETUP>(2\10)
<TABLE_HEADS>(Class Name\Description)
<TABLE_ROW>(alnum\Letter or digit.)
<TABLE_ROW>(alpha\Letter only (A-Z, a-z).)
<TABLE_ROW>(blank\Space or tab character.)
<TABLE_ROW>(cntrl\ASCII control characters.)
<table_row>(digit\Digits only (0-9).)
<TABLE_ROW>(domain\Any character permitted in the domain-part of an RFC821/RFC822 address.)
<TABLE_ROW>(graph\Any non-blank printable character.)
<TABLE_ROW>(lower\Lower-case letter.)
<TABLE_ROW>(print\Any printable character, including spaces but excluding tab characters.)
<TABLE_ROW>(punct\Any punctuation character.)
<TABLE_ROW>(space\Any whitespace character, including horizontal and vertical tabs, formfeeds, and carriage returns.)
<TABLE_ROW>(upper\Upper-case character.)
<TABLE_ROW>(username\Any character permitted in the local-part of an RFC821/RFC822 address.)
<TABLE_ROW>(xdigit\Hexadecimal digit.)
<ENDTABLE>
<CP>The <EMPHASIS>(domain) and <EMPHASIS>(username) character classes are MX extensions to standard
regular expressions, included to make it easier to match e-mail addresses.  Note that since MX always
performs case-independent matching, the <EMPHASIS>(upper) and <EMPHASIS>(lower) character classes
are equivalent to <EMPHASIS>(alpha).
<P>Enclosing an RE in parentheses creates a <NEWTERM>(subexpression); multiple subexpressions may
be concatenated to form a larger RE.

<HEAD2>(Examples\regexexamp)
<P>
Some examples of REs are shown below.  Note that since periods normally match any character
in an RE, to match a literal period in, for example, a domain name, you must quote it with a backslash.
The examples are shown in quotation marks as they would be specified in a command; the quotation marks are
not part of the REs themselves.
<P>
<INTERACTIVE>(WIDE)
<QUOTE>(<[[:username:]]+@[[:domain:]]+<BACKSLASH>.mydom<BACKSLASH>.com)
<ENDINTERACTIVE>
<P>This RE matches any valid address in any subdomain under <quote>(mydom.com).
<P>
<INTERACTIVE>(WIDE)
<QUOTE>(Subject:[[:blank:]]*<BACKSLASH>$+[[:blank:]]*MAKE MONEY FAST[[:blank:]]*<BACKSLASH>$+[[:blank:]]*)
<ENDINTERACTIVE>
<P>
This RE would match any Subject: header containing one or more dollar signs, the string <QUOTE>(MAKE MONEY FAST), followed 
by another string of one or more dollar signs (with the dollar signs possibly surrounded by blanks).  Note that the text will
match regardless of case, and the use of the <EMPHASIS>(blank) character class will match either spaces or tabs. 
<HEAD2>(Substitutions\regexsubst)
<P>
In rewrite rule processing, strings matching subexpressions are tracked and may be substituted into the rewritten
address.  While there is no fixed limit on the number of subexpressions allowed in an RE, only the first nine are
tracked for substitution purposes.  To include the matching string in the rewritten address, specify a backslash
followed by the digit (1-9) for the 1st through 9th subexpression, respectively.
<P>For example, the following rewrite rule:
<INTERACTIVE>(WIDE)
DEFINE REWRITE_RULE "<([[:username:]]+)@([[:domain:]]+)<BACKSLASH>.dnet>" "<""<BACKSLASH>2::<BACKSLASH>1""@myhost>"
<ENDINTERACTIVE>
<CP>could be used to create a fake <QUOTE>(dnet) domain that rewrites domain-style addresses into DECnet-style
references for delivery at host <QUOTE>(myhost).  The <QUOTE>(<BACKSLASH>2) reference causes the string matching the
second subexpression (the domain string) to be included, and the <QUOTE>(<BACKSLASH>1) reference causes the
string matching the first subexpression (the username string) to be included.
<P>
Note that substitution string indices are assigned in order from left to right, based on the presence of the
opening left parenthesis, regardless of the level of subexpression nesting.  For example:
<INTERACTIVE>(WIDE)
DEFINE REWRITE_RULE "<(user_(alpha<VBAR>beta))@([[:domain:]]+)>" "<<BACKSLASH>2@<BACKSLASH>3>"
<ENDINTERACTIVE>
<CP>
In this rewrite rule, substitution string <QUOTE>(<BACKSLASH>1) would contain the string matching the entire first
subexpression (matching <QUOTE>((user_(alpha<VBAR>beta)))).  The <QUOTE>(<BACKSLASH>2) substitution string
would contain the string matching the second subexpression, which happens to be nested inside the first
(matching <QUOTE>((alpha<VBAR>beta))).  Finally, <QUOTE>(<BACKSLASH>3) would contain the domain-name
string to the right of the at sign.
<ENDAPPENDIX>
<INDEX_FILE>
