Message Exchange User's Guide
April, 1990
This manual provides information for users of Message
Exchange, electronic mail software for VMS systems.
Revision/Update Information: This is a new manual.
Operating System and Version: VMS V5.0 or later
Software Version: Message Exchange V1.2
Engineering Computing Services
Rensselaer Polytechnic Institute
Troy, New York
________________________
09 April 1990
Permission is granted to copy and redistribute this
document for no commercial gain.
The information in this document is subject to change
without notice and should not be construed as a
commitment by Rensselaer Polytechnic Institute.
Rensselaer assumes no responsibility for any errors
that may appear in this document.
This document is still under construction. Comments
and suggestions for improvements may be forwarded to
MX-List@vms.ecs.rpi.edu.
DISCLAIMER: The software described in this document
is provided "as is". No guarantee is made by the
author or the author's employer as to the suitability,
reliability, security, usefulness, or performance of
this software.
The following are trademarks of Digital Equipment
Corporation:
DEC VAX VAXcluster
VAXstation VMS VT
Jnet is a trademark of Joiner Associates, Inc.
__________
Copyright ©1990 Rensselaer Polytechnic Institute
All Rights Reserved.
Printed in U.S.A.
This document was prepared using VAX DOCUMENT, Version
1.2
_______________________________________________________
Contents
_________________________________________________
PREFACE v
_______________________________________________________
CHAPTER 1 USING MESSAGE EXCHANGE WITH VMS MAIL 1-1
_________________________________________________
1.1 SPECIFYING AN ADDRESS 1-1
1.1.1 Multiple Recipients ___________ 1-2
1.1.2 Quotation Marks _______________ 1-2
_________________________________________________
1.2 USING SET FORWARD WITH MX 1-2
_________________________________________________
1.3 PERSONAL NAME 1-3
_________________________________________________
1.4 SIGNATURE FILES 1-3
_________________________________________________
1.5 REDIRECTING REPLIES 1-4
_________________________________________________
1.6 RECEIPT ACKNOWLEDGMENT 1-4
_________________________________________________
1.7 NETWORK DELIVERY DELAYS 1-5
iii
Contents
_______________________________________________________
CHAPTER 2 ELECTRONIC MAILING LISTS 2-1
_________________________________________________
2.1 INTERNET-STYLE LISTS 2-1
2.1.1 BITNET-Style Lists ____________ 2-2
_______________________________________________________
CHAPTER 3 NETWORK FILE SERVERS 3-1
_________________________________________________
3.1 GET HELP 3-1
_________________________________________________
3.2 MX FILESERV COMMANDS 3-2
3.2.1 Packages ______________________ 3-2
3.2.2 Binary Files __________________ 3-2
_______________________________________________________
APPENDIX A MESSAGE HEADER FORMAT A-1
_________________________________________________
A.1 VMS MAIL HEADERS A-3
A.1.1 From Header ___________________ A-3
A.1.2 To and CC Headers _____________ A-4
A.1.3 Subject Header ________________ A-4
iv
_______________________________________________________
Preface
Message Exchange (MX) is software that provides store-
and-forward routing and delivery of electronic mail
messages. It can also provide mailing list and file
distribution services. MX can be used to enhance local
electronic mail (E-mail) support, and it can be used
with several kinds of network protocols to provide a
unified E-mail interface to different networks.
__________________________________________________________________
Intended Audience
This manual is intended for any VMS MAIL user who
uses MX, and users of MX's mailing list and file
distribution services. The reader should already know
the basics of using VMS and the VMS MAIL utility.
__________________________________________________________________
Document Structure
This guide consists of three chapters and one
appendix.
Chapter 1 Describes the MX/VMS MAIL interface.
Chapter 2 Describes the mailing list handler.
Chapter 3 Describes the file server.
Appendix A Describes MX message formats in detail.
v
Preface
__________________________________________________________________
Related Documents
You can find additional information in the following
documents:
o Message Exchange Installation Guide describes the
installation of MX.
o Message Exchange Management Guide describes the
management and operation of MX.
o Message Exchange Release Notes contain information
and updates not included in this manual. The
release notes are part of the software distribution
kit.
o VMS Mail Utility Manual describes the VMS MAIL
utility in detail.
vi
_______________________________________________________
1 Using Message Exchange with VMS MAIL
Message Exchange (MX) interfaces with VMS MAIL to
provide the means for addressing outgoing mail through
MX. It als ensures that mail that is delivered via
MX has an appropriate source address for replies,
and provides support for signature files and user-
specified reply-to addresses.
__________________________________________________________________
1.1 Specifying an Address
MX interfaces with VMS MAIL as a "foreign protocol".
When using VMS MAIL, you address mail to be sent
through MX by specifying an address of the form:
MX%"user@host"
The leading MX% tells VMS MAIL to invoke the MX
protocol handler; the address, which should be
surrounded by quotation marks to prevent the address
from being converted to upper case and prevent the
@-sign from being interpreted by VMS MAIL, is the
network mail address of the user you wish to send mail
to.
If the user is on the local host, you can omit the
@host part of the address, and the quotation marks,
just specifying
MX%username
for an address.
1-1
Using Message Exchange with VMS MAIL
___________________________
1.1.1 Multiple Recipients
When sending messages to more than one recipient
through MX, each recipient's address requires the MX%
prefix (and quotation marks, if needed). For examples:
MAIL>SEND
To:SMITH, MX%"jones@otherhost.edu",BROWN,MX%NAMES-L
Note that you can mix plain, local usernames with
MX-directed addresses in the same message.
___________________________
1.1.2 Quotation Marks
VMS MAIL cannot handle quotation marks within an
address. MX works around this problem by substituting
apostrophes instead. For example, if the destination
address is
"node::user"@remote.host
you can specify this address in VMS MAIL as
MX%"'node::user'@remote.host
__________________________________________________________________
1.2 Using SET FORWARD with MX
You can use the SET FORWARD command in VMS MAIL to set
a forwarding address for your mail through MX. To do
this, however, requires two extra pairs of quotation
marks around the address. For example:
MAIL>SET FORWARD MX%"""user@host"""
You should be sure to check the forwarding address
with SHOW FORWARD and to send yourself a test message
to ensure that you specified the address correctly.
1-2
Using Message Exchange with VMS MAIL
__________________________________________________________________
1.3 Personal Name
The SET PERSONAL_NAME command in VMS MAIL lets you
enter your real name, to be appended to your VMS
username on outgoing mail. Messages sent via MX will
also include your personal name if you have one set.
__________________________________________________________________
1.4 Signature Files
The MX/VMS MAIL interface provides support for
"signature" files. A signature file is a file that
contains your name, E-mail address, and any other
information that you would like to have included in
your outgoing mail messages. It should be no more
than a few lines long and should probably contain
lines that do not exceed 80 characters in length. For
example:
Peter Shandy, Ph.D.
Horticulture Department
Balaclava Agricultural College
shandy@buster.balaclava.edu
Once you create a signature file, you inform MX of its
existence by defining the logical name MX_SIGNATURE:
$DEFINE MX_SIGNATURE device:[directory]name.type
You can then have the signature included in your
message by entering the line
/SIGNATURE
in your message. To be recognized, there can be no
other text on the line and no leading blanks. Case
is not important, and you can abbreviate SIGNATURE
to SIG. Your signature file will be inserted in the
message at the point where you place the /SIGNATURE
line.
1-3
Using Message Exchange with VMS MAIL
Note that the signature is included only in copies
of the message that are sent via MX; if you also
send your message to users not using the MX% prefix,
they will just see the /SIGNATURE line and not your
signature file.
To enable your signature file every time you login,
include the DEFINE command in your login command
procedure.
__________________________________________________________________
1.5 Redirecting Replies
Normally when you send a message via MX from your VMS
account, the message will include information that
will direct any replies to the message back to your
VMS account. If you would rather have replies go to
a different account, or to an account on a different
system, you can define the logical name MX_REPLY_TO to
include this information in the message:
$DEFINE MX_REPLY_TO "user@host"
Note that you should not include the MX% prefix on the
address, and you should not change quotation marks to
apostrophes when you specify the address.
To have this reply address included in your messages
every time you login, include the DEFINE command in
your LOGIN.COM file.
__________________________________________________________________
1.6 Receipt Acknowledgment
Most network E-mail systems are modelled after the
postal system: once you put an electronic mail message
in the post, you have no way of knowing whether the
message will ever get to its intended recipient.
Some systems support some primitive return recipt
mechanism, but there is no standard for this on the
Internet. MX does not support any form of receipt
acknowledgment.
1-4
Using Message Exchange with VMS MAIL
__________________________________________________________________
1.7 Network Delivery Delays
Messages sent over any network can be delayed due to
network outages, system loading, or other reasons.
Once a message leaves the local system, there is no
way to determine where the message may be held up.
However, messages still on the local system awaiting
network transfer can be displayed with the MAILQUEUE
utility:
$RUN MX_EXE:MAILQUEUE
MAILQUEUE, if installed by the system manager, will
list any messages you have sent that are waiting for
network transfer. All messages that cannot be sent
are tried every half hour for two days. If, after
that period, the message still cannot be sent, it is
returned to sender with an message explaining why the
transfer did not occur.
1-5
_______________________________________________________
2 Electronic Mailing Lists
When talking about electronic mail, the term mailing
list is generally used to describe an E-mail address
that forwards messages to more than one user. Mailing
lists abound on the Internet and BITNET, on a wide
variety of technical and non-technical topics.
Unfortunately, there are no standards on the
implementation of mailing lists, so their use will
vary depending on the systems on which the mailing
lists are set up. For the most part however, mailing
lists can be broken down into two basic types:
Internet and BITNET.
__________________________________________________________________
2.1 Internet-Style Lists
For an Internet-style mailing list, there are
generally two addresses: one for the mailing list
itself, and one for "administrivia" (subscription
requests, etc.). The administrative address is usually
the mailing list name with "-request" added. For
example, the mailing list for discussing Message
Exchange is MX-List@vms.ecs.rpi.edu. Subscription
requests, removals, or comments about the list are
sent to MX-List-request@vms.ecs.rpi.edu.
Most Internet-style mailing lists are managed
manually, so mail sent to -request addresses can
usually be free-form. However, a few systems, MX
included, have mailing list handlers which process
some types of requests automatically, without human
intervention. The syntax of the commands you send
to these automated handlers will vary from system to
system. For example, the MX mailing list processor
accepts the following commands:
2-1
Electronic Mailing Lists
SUBSCRIBE for getting added to the list
SIGNOFF for getting removed from the
list
REVIEW for getting a list of the
subscribers
To have a command be processed by MX automatically,
you must place it on the first line of the body of the
message you send to the -request address.
___________________________
2.1.1 BITNET-Style Lists
Most mailing lists on BITNET hosts are implemented
using LISTSERV, a package developed specifically for
automated handling of mailing lists. One LISTSERV on
a system, at address LISTSERV@hostname, manages all
the mailing lists offered on that system, and provides
automatic administrative request handling.
LISTSERV will usually handle the following commands:
SUBSCRIBE list-name for getting added to the list
SIGNOFF list-name for getting removed from the
list
REVIEW list-name for getting a list of the
subscribers
Along with several more. The MX mailing list processor
also provides LISTSERV-style command handling, but
supports only the commands listed above.
2-2
_______________________________________________________
3 Network File Servers
The term file server, for the purposes of this
document, refers to a network entity that maintains a
library of files and delivers them to users on demand.
As with mailing lists, there are no standards for file
servers. There are several file server implementations
in existence: LISTSERV, VMSSERV, MAILSERV, and
several others. MX also includes a file server module,
generally referred to as FileServ. Some of these file
servers accept commands via BITNET immediate messages,
some only by E-mail messages. Some take commands on
the subject line of a message, and some in the body of
a mesasge. The way files are distributed can also vary
from server to server.
__________________________________________________________________
3.1 Get HELP
If you want to obtain files from a file server, and
you are unsure of the commands you need to use, you
should begin by requesting help information from the
server. The best way to do this is to send an E-mail
message to the file server's address with the word
HELP on the subject line and on the first and only
line of the body of the message. Most servers will
mail you back a message listing the commands they
accept and the format the commands should take, along
with other helpful information.
If you cannot get assistance from the file server
itself, you may be able to get some from the
postmaster on the file server's system.
3-1
Network File Servers
__________________________________________________________________
3.2 MX FileServ Commands
The MX file server, usually called FileServ, accepts
commands, one command per line, in the body of an
E-mail message. The commands it accepts are:
LIST [pattern] lists all packages matching
"pattern"
DIRECTORY [pattern] same as LIST
SENDME sends an entire package or the
package[.part] specified part
HELP sends a help message
FileServ commands may be abbreviated to their shortest
unique string.
___________________________
3.2.1 Packages
A package is a collection of related files that are
grouped together distribution. FileServ, along with
other file servers, distributes files in packages.
These packages are usually in a special format for
distribution over the network via E-mail; once you
collect all of the parts in a package, the parts are
combined together and fed through an unpacking program
(sometimes contained within the package itself) to
recreate the original collection of files.
___________________________
3.2.2 Binary Files
Because E-mail systems generally do not properly
handle binary data, binary files (such as executable
images or compressed files) are generally encoded
before being packaged and distributed by a file
server. Once unloaded from the package, the encoded
3-2
Network File Servers
file must then be decoded to recreate the binary file.
The type of encoding will vary from system to system.
In addition, large files may be compressed before
being encoded and packaged, to cut down on the
network bandwidth required when transmitting the
package. Restoring the original files then requires
an additional decompression program.
3-3
_______________________________________________________
A Message Header Format
Most network mail systems require or include more
information about messages than VMS MAIL can handle.
MX, for example, follows the Internet message format
standard, usually called RFC 822 after the number of
the document that describes the format.
When you receive a message via MX, the FROM address
identified in the VMS MAIL headers will begin with the
MX% prefix, which allows you to REPLY to the message.
In addition to the VMS MAIL headers, you will also see
the RFC 822 header information, which is displayed as
the first part of the message text. For example:
#1 29-FEB-1990 10:36:22.11 NEWMAIL
From: MX%"idiot@vms.ecs.rpi.edu"
To: MADISON
CC:
Subj: Question
Return-Path: <@mdmvs.ecs.rpi.edu:idiot@vms.ecs.rpi.edu>
Received: from vms.ecs.rpi.edu by mdmvs.ecs.rpi.edu; Thu, 29 Feb 1990
10:35:10 EST
Resent-Date: Thu, 29 Feb 1990 10:35:01 EST
Resent-From: system@vms.ecs.rpi.edu
Resent-To: madison@mdmvs.ecs.rpi.edu
Date: Thu, 29 Feb 1990 10:34:55 EST
From: idiot@vms2.ecs.rpi.edu (Idiot User)
Reply-To: idiot@vms.ecs.rpi.edu
Message-ID: <00933068.08a17f00.31437@vms.ecs.rpi.edu>
To: system@vms.ecs.rpi.edu
Subject: Question
How do I log in? Please reply by E-mail.
A-1
Message Header Format
The first five lines of this message are the VMS MAIL
headers. The message text starts with the RFC 822
headers, followed by the message itself. The following
sections explain the meaning of the RFC 822 headers.
Return-Path. The return address as appears on the
envelope of the message. This usually identifies the
route the message took in getting to you, and can be
used to identify forged messages in some cases. The
return path is used as the VMS MAIL From address if no
other address is available.
Received. There may be several of these lines for
a message. They usually indicate how and when the
message was transferred from one system to another.
They are provided for informational purposes only.
Resent- lines. If the message is forwarded (usually by
an automatic mechanism such as SET FORWARD in VMS
MAIL), some messaging systems (MX included) will
include information about when it was forwarded and
who it was forwarded to. One set of Resent lines
usually appears for each forwarding hop.
Date. This line indicates the date and time the
message was entered into the mail system by the
sender. It will usually include the local time for
the sender, which may be in a different time zone.
From. This line indicates who the message is from.
If the message was sent by someone on behalf of
another person or group, the message will also include
a Sender line to identify the person or agent who
actually sent the message.
Reply-To. If the sender wants to receive replies at
an address different from the From address, a Reply-To
line will be included to redirect the replies.
Message-ID. The message identifier uniquely identifies
a message. Message-ID's are used by some mail systems
for tracking messages and replies.
A-2
Message Header Format
To. Identifies the target user or users for the
message. Also included can be CC and BCC lines that
identify users to whom a carbon copy and "blind"
carbon copy of the message is sent.
Subject. A brief description of the subject of the
message.
Other headers are also possible, some of which are
extensions to the RFC 822 message standard. Also, the
order in which the headers appear may vary from system
to system.
__________________________________________________________________
A.1 VMS MAIL Headers
MX automatically translates some of the RFC 822 header
information into VMS MAIL headers.
___________________________
A.1.1 From Header
There are several RFC 822 headers used for identifying
the originator of a message. VMS MAIL, however, allows
only one. To allow the REPLY command to work properly,
therefore, MX fills in the VMS MAIL From line with
the address that should be used in generating a
reply. This reply address is selected from one of
the following header lines, listed here in order of
preference:
1 Reply-To
2 From
3 Sender
4 Return-Path
MX will only use the address from one of these headers
if it is syntactically valid. Since most mail systems
provide a valid address in the Reply-To and/or From
headers, this should not be a problem.
A-3
Message Header Format
___________________________
A.1.2 To and CC Headers
The VMS MAIL To and CC headers will list only the
users on the local system receiving the message. To
see the actual list of recipients, examine the To, CC,
and BCC lines in the RFC 822 headers.
___________________________
A.1.3 Subject Header
The VMS MAIL Subject header should be identical to the
RFC 822 Subject header, if one exists.
A-4