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