V'0);,Message Exchange User's Guide5

Message Exchange User's Guide





+

February, 2001



@This manual provides information for users of Message Exchange, )electronic mail software for VMS systems.

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

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

OpenVMS Alpha V6.2 or later

"Software Version:Message Exchange V5.2


25 February 2001

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

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

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

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

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

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


CMultiNet and TCPware are registered trademarks of Process Software Corporation.

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

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

Copyright ©2001



 ,  
GContents
 


$

Preface



BMessage Exchange (MX) is software that provides store-and-forward Frouting and delivery of electronic mail messages. It can also provide Gmailing list and file distribution services. MX can be used to enhance Hlocal electronic mail (E-mail) support, and it can be used with several Dkinds of network protocols to provide a unified E-mail interface to different networks.4

Intended Audience



HThis manual is intended for any VMS MAIL user who uses MX, and users of DMX's mailing list and file distribution services. The reader should >already know the basics of using VMS and the VMS MAIL utility.5

Document Structure



6This guide consists of four chapters and one appendix.                    
 Chapter 1 * Describes the MX/VMS MAIL interface.
 Chapter 2 $ Describes the MXALIAS utility.
 Chapter 3 ) Describes the mailing list handler.
 Chapter 4 Describes the file server.
 Appendix A - Describes MX message formats in detail.
4

Related Documents



?You can find additional information in the following documents:

 


R

Chapter 1
Using Message Exchange with VMS MAIL




HMessage Exchange (MX) interfaces with VMS MAIL to provide the means for Gaddressing outgoing mail through MX. It also ensures that mail that is Ddelivered via MX has an appropriate source address for replies, and Aprovides support for signature files and user-specified reply-to addresses.V

1.1 Specifying an Address



DMX interfaces with VMS MAIL as a "foreign protocol". When Husing VMS MAIL, you address mail to be sent through MX by specifying an address of the form:

 

"
MX%"user@host"




FThe leading MX% tells VMS MAIL to invoke the MX protocol handler; the Faddress, which should be surrounded by quotation marks to prevent the Gaddress from being converted to upper case and prevent the @-sign from Gbeing interpreted by VMS MAIL, is the network mail address of the user you wish to send mail to.

GIf the user is on the local host, you can omit the @host part 8of the address, and the quotation marks, just specifying

 

"
MX%username




for an address.

@The MXALIAS utility can be used to define MX aliases for e-mail ‹addresses; see Chapter 2, The MXALIAS Utility, for information about using MXALIAS. MX Daliases are used just as if sending mail through MX to a local user:

 

"
MX%alias




HAny MX% address given without the @host part of the address is Fchecked to see if it is an MX alias. If it is, the equated address is Eused; if not, the specified address is assumed to be that of a local user.#M

1.1.1 Displaying MX Address Translations



?If you want to see all address translations made by MX for MX% ;addresses passed from VMS Mail, you can define the logical 7MX_VMSMAIL_SHOW_ADDR as shown in the following command:

 

"
"$ DEFINE MX_VMSMAIL_SHOW_ADDR TRUE




DIf the logical is defined, MX displays the final address used for a given address:

 

"
MAIL> SEND 4To:     MX%JOE, MX%"MX-List@WKUVX1.WKU.EDU", SYSTEM 8  MX rewrote alias JOE as <SYSTEM@WKUVX1.WKU.EDU> F  MX rewrote MX-List@WKUVX1.WKU.EDU as <MX-List@WKUVX1.WKU.EDU> 
Subj:   .... 




ENote that "SYSTEM" was not passed to MX because it was not Fspecified with the MX% prefix. Also note that JOE had been defined as Ban alias equal to SYSTEM@WKUVX1.WKU.EDU using the MXALIAS utility M(described in Chapter 2).

FPlacing the MX_VMSMAIL_SHOW_ADDR logical definition in your LOGIN.COM :will cause MX to always show you all address translations.>

1.1.2 Multiple Recipients



BWhen sending messages to more than one recipient through MX, each Erecipient's address requires the MX% prefix (and quotation marks, if needed). For examples:

 

"
MAIL> SEND4To: SMITH, MX%"jones@otherhost.edu",BROWN,MX%NAMES-L




HNote that you can mix plain, local usernames with MX-directed addresses in the same message.:

1.1.3 Quotation Marks



CVMS MAIL cannot handle quotation marks within an address. MX works Faround 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"




BTo enter an apostrophe in an address, quote the apostrophe with a 5backslash. For example, if the destination address is

 

"
o'reilly@remote.host


you would enter

 

"
MX%"o\'reilly@remote.host"


Z

1.2 Using SET FORWARD with MX



DYou can use the SET FORWARD command in VMS MAIL to set a forwarding Eaddress for your mail through MX. To do this, however, requires that Fyou add extra quotes to the address. The forwarding address should be Fquoted, and, since MX addresses must be quoted, the inner quotes must ;be doubled to comply with the command parsing. For example:

 

"
'MAIL> SET FORWARD "MX%""user@host"""




EYou should be sure to check the forwarding address with SHOW FORWARD Eand to send yourself a test message to ensure that you specified the address correctly.N

1.3 Personal Name



CThe SET PERSONAL_NAME command in VMS MAIL lets you enter your real Ename, to be appended to your VMS username on outgoing mail. Messages Esent via MX will also include your personal name if you have one set.P

1.4 Signature Files



EThe MX/VMS MAIL interface provides support for "signature" Bfiles. A signature file is a file that contains your name, E-mail Haddress, and any other information that you would like to have included Fin your outgoing mail messages. It should be no more than a few lines Hlong 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 




DOnce you create a signature file, you inform MX of its existence by 'defining the logical name MX_SIGNATURE:

 

"
1$ DEFINE MX_SIGNATURE device:[directory]name.type




EYou can then have the signature included in your message by entering the line

 

"
/SIGNATURE




Ein 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 Eabbreviate SIGNATURE to SIG. Your signature file will be inserted in =the message at the point where you place the /SIGNATURE line.

GNote that the signature is included only in copies of the message that Fare 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.

GTo enable your signature file every time you login, include the DEFINE (command in your login command procedure.H

1.4.1 Automatic Signature Inclusion



EYour signature file can be included automatically at the end of your 7message by defining the logical name MX_AUTO_SIGNATURE:

 

"
$ DEFINE MX_AUTO_SIGNATURE text




CThe text is not important; as long as the logical name is Ddefined, the signature file you specify with MX_SIGNATURE will will Fautomatically be appended to the end of all subsequent MX messages. A C/SIGNATURE line can be used to place the signature anywhere in the -message (overriding the automatic appending).

GIf you wish to prevent the automatic inclusion of your signature file, enter a line

 

"
/NOSIGNATURE


Cin your message. The same formatting rules apply as for /SIGNATURE.T

1.5 Redirecting Replies



CNormally when you send a message via MX from your VMS account, the Emessage will include information that will direct any replies to the Fmessage back to your VMS account. If you would rather have replies go Hto a different account, or to an account on a different system, you can Gdefine the logical name MX_REPLY_TO to include this information in the message:

 

"
 $ DEFINE MX_REPLY_TO "user@host"




HNote that you should not include the MX% prefix on the address, and you Fshould not change quotation marks to apostrophes when you specify the address.

DTo have this reply address included in your messages every time you 9login, include the DEFINE command in your LOGIN.COM file.

<Some mailers, including MX, allow multiple addresses on the H"From:" line for messages. You can include multiple addresses Ain the MX_REPLY_TO definition to allow replies to be returned to Hmultiple addresses (assuming the remote mailer allows it). For example, Fif you want replies to your messages to go to two different accounts, (you could define the logical as follows:

 

"
,$ DEFINE MX_REPLY_TO "user@host,user2@host2"


g

1.6 Directing Delivery to VMS MAIL Folders



GMX normally delivers incoming messages to your NEWMAIL folder, just as CVMS MAIL does for local messages. If you receive a large amount of Ce-mail, particularly from different mailing lists, MX's folder Gdelivery option may help you to keep your e-mail better organized.I

1.6.1 Folder Delivery Address Format



.MX accepts local e-mail addresses of the form Gusername+foldername, and treats the Dcharacters appearing after the plus sign (+) as either the Gname of a folder or an alias for a folder name. You control the folder Cnames into which MX can deliver messages by creating a file called 'MX_FOLDERS.DAT in your login directory.

GWhen MX receives a message for you that contains a plus sign, it reads Fthe contents of your MX_FOLDERS.DAT file. If it finds the folder name Ein the file, it delivers the message into that folder. Otherwise, it 3simply delivers the message to your NEWMAIL folder.C

1.6.2 Format of MX_FOLDERS.DAT



EThe file MX_FOLDERS DAT must reside in your login directory E(SYS$LOGIN:) and should be an ordinary VMS text file. Blank lines in Fthe file are ignored. Other lines should contain one of the following:



GLeading and trailing blanks (and tabs) are ignored. Blanks and/or tabs .separate alias names from actual folder names.

DSince the folder specifications allowed in addresses are limited to ?only ASCII alphanumeric (A through Z, 0 through 9) characters, Funderscores (_), and hyphens (-), you can use folder aliases to allow Fdelivery to folders that contain other characters that are allowed by ;VMS MAIL (such as dots and international 8-bit characters).A

1.6.3 Example MX_FOLDERS.DAT



CThe following is an example of an MX_FOLDERS.DAT file for the user /SAMPLE. It resides in SAMPLE's login directory.

 

"
'!  MX-LIST for the MX-List mailing list+mx-list)!  INFO-VAX for the Info-VAX mailing list	+info-vax-!  MAD.GOAT for the Info-MadGoat mailing list+info-madgoat  mad.goat


O

1.6.4 Specifying Folders in From Addresses



DYou can specify a folder name to be added to your e-mail address in Doutgoing messages by using the following directive on the first %line of the text of the message:

 

"
/FROM=+foldername




GThis only applies to ordinary (non-/FOREIGN) text messages sent by VMS BMAIL or DECwindows Mail. If present, MX's VMS MAIL interface will Cautomatically remove the line from the text of the message and the "address in the From: header to be Gusername+foldername. Note that this Cfolder name must contain only 7-bit ASCII alphanumeric characters, underscores, and hyphens.

BIf you use this directive when subscribing to a mailing list, and Gspecify the folder name in your MX_FOLDERS.DAT file, then all messages Gfrom that mailing list will be delivered to the folder, rather to your default NEWMAIL folder.^

1.7 Delivery Status Notifications



HMX supports the Internet standard form of delivery status notifications F(DSNs), which can provide information on the status of a message that @you send. When a system supporting the DSN standards delivers a Emessage, it examines the DSN control information you defined for the Hmessage and determines whether it should notify you about the status of the delivery.

:To enable these notices, you must define the logical name HMX_VMSMAIL_DSN_CONTROL. This logical name can be defined with up to two separate settings:

@

1.7.1 Notification Settings



1The notification setting is specified as follows:

 

"
<$ DEFINE MX_VMSMAIL_DSN_CONTROL "NOTIFY=type[,...]"


;where type can be one of these notification types:                
NEVER N Specifies that you do not want to be notified about the delivery of the message, even if it fails.
SUCCESS N Specifies that you want to be notified about successful delivery of the M message, or if it has been successfully relayed to another system that  does not support DSNs.
FAILURE N Specifies that you want to be notified if delivery of the message fails.
DELAY K Specifies that you want to be notified if delivery of the message is  delayed for some reason.
GIf you specify NOTIFY=NEVER, you cannot specify any other notification Gtype. Other types may be combined by separating the type keywords with commas.

DNote that for SUCCESS notifications, notification of the successful Hdelivery of the message may only be notification of a "relay" Dto another system. This happens if a remote system does not support HDSNs, or the message is sent to a remote system using a protcol that is )not capable of transmitting DSN requests.H

1.7.2 Returned-Information Settings



/The setting for returned information is either:

 

"
0$ DEFINE MX_VMSMAIL_DSN_CONTROL "RETURN=HEADERS"


Gwhich specifies that you only want the RFC822 message headers included )in the returned notification message, or:

 

"
-$ DEFINE MX_VMSMAIL_DSN_CONTROL "RETURN=FULL"


Awhich specifies that you want the entire message included in the returned notification message.

CIf you do not specify a RETURN setting, the system that issues the Ddelivery status notification is allowed to choose whether it should .return the entire message or just the headers. A

1.7.3 Combining the Settings



GYou may specify both notification and returned-information settings by Aseparating the two settings with one or more blanks. For example:

 

"
G$ DEFINE MX_VMSMAIL_DSN_CONTROL "NOTIFY=SUCCESS,FAILURE RETURN=HEADERS"


FThis DSN control string specifies that you want to be notified if the Hmessage is delivered successfully or if it fails, and you want only the /message headers included with the notification.6

1.7.4 Limitations



EBecause DSN settings are controlled by a logical name, they apply to Ball recipients of all messages you send while the logical name is Hdefined. You cannot specify per-message or per-recipient settings while -using MX through VMS MAIL or DECwindows Mail.X

1.8 Network Delivery Delays



FMessages sent over any network can be delayed due to network outages, Bsystem loading, or other reasons. Once a message leaves the local Gsystem, there is no way to determine where the message may be held up. FHowever, messages still on the local system awaiting network transfer ,can be displayed with the MAILQUEUE utility:

 

"
$ RUN MX_EXE:MAILQUEUE




HMAILQUEUE lists any messages you have sent that are waiting for network Ctransfer. All messages that cannot be sent are tried periodically, Gbased on settings established by your system manager. If the number of Cattempts exceeds the established limit, the message is returned to @sender with a message explaining why the transfer did not occur.#O

1.8.1 Displaying MX Informational Messages



HIf you want MX to display information messages indicating that your VMS GMail message has been successfully delivered to MX, you can define the ?logical MX_VMSMAIL_SHOW_INFO as shown in the following command:

 

"
"$ DEFINE MX_VMSMAIL_SHOW_INFO TRUE




FIf the logical is defined, MX displays a line like the following when "the message has been queued to MX:

 

"
I%MX-I-MAIDLVR, message (entry number 22643) successfully delivered to MX 




GAn informational message will also be displayed when a message is sent with SEND/FOREIGN:

 

"
7%MX-I-BASE64, encoding MX foreign message using BASE64 




FPlacing the MX_VMSMAIL_SHOW_INFO logical definition in your LOGIN.COM =will cause MX to always display the informational messages. h

1.9 Sending binary files to other VMS users



GThe VMS Mail command SEND accepts an undocumented qualifier, /FOREIGN. DSEND/FOREIGN allows you to mail any VMS file to another user on the Asame system or over DECnet. The file retains all of the VMS file >attributes. When the recipient tries to read the mail message <containing the file, the following information is displayed:

 

"
<    #2          14-APR-1993 15:28:02.11             NEWMAIL From:   GOATHUNTER To:     GOATHUNTER CC: Subj:   RESET.EXE  ,You cannot read this foreign format message H        Use the EXTRACT command to copy the message to an external file  	MAIL> 




GThe EXTRACT command copies the message to the named external file with all VMS file attributes intact.

CThe SEND/FOREIGN command can also be used to send VMS binary files Athrough MX, if the target user is on a system running MX V3.3 or >higher, MultiNet V3.3 or higher, or PMDF V4.1 or higher. When GSEND/FOREIGN is used, MX encodes the message using an algorithm called ABASE64, which is defined in RFC 1341, a document describing MIME D(Multipurpose Internet Mail Extensions). The BASE64-encoded file is Gwrapped in a MIME-compliant message and mailed to the recipients. When Hthe message is received on a system running the appropriate versions of Geither MX, MultiNet, or PMDF, the encoded binary file is automatically Fdecoded and mailed to the local user as a foreign file. The recipient Hwill receive two messages---one containing the headers for the message, 9and the other containing the foreign file as shown above.

3The MIME "Content-Type:" for the file is E"APPLICATION/VMS-RMS". MX will automatically recognize and Adecode incoming "VMS-RMS" files that are encoded using *BASE64, as well as QUOTED-PRINTABLE files.



/  
Note

@The encoding done by MX is only compatible with the VMS mailers Especified above. SEND/FOREIGN cannot be used to send binary files to 'non-VMS MIME-compliant mailers.


DThe following example demonstrates sending a binary file through MX:

 

"
$ mail(MAIL> send/noedit/foreign program.exeTo:     MX%"gene@KISS.COM"/Subj:   Here is that program I promised to send(Encoding MX foreign message using BASE649Message (entry number 22244) successfully delivered to MXMAIL>






/  
Note

ENon-VMS recipients or VMS recipients on systems not running Fthe appropriate software will receive a single message containing the FBASE64-encoded file. This message will most likely be meaningless for those recipients.


DFrom the DCL prompt, the command MAIL/FOREIGN can be used to send a &binary file to one or more recipients:

 

"
C$ mail/foreign/subj="My LOGIN.COM" login.com "mx%""user@node.edu"""


 !


A

Chapter 2
The MXALIAS Utility




EMXALIAS is a simple database manager for user-defined MX aliases. An Halias is a name that is equated with a mail address that can be used to Faddress electronic mail. For example, the address "BOB" can Ebe equated with "smithjb@node1.school.edu"; it can then be Dused in VMS Mail by specifying MX%BOB at the "To:" prompt:

 

"
MAIL> SENDTo:     MX%BOBSubj:   ....




4MX aliases are stored, by default, in a file called DMX_ALIAS_DATABASE.DAT in your login directory (SYS$LOGIN:). You can Gdefine the MX_ALIAS_DATABASE logical in your LOGIN.COM to relocate the database file:

 

"
5$ DEFINE MX_ALIAS_DATABASE dev:[user.MAIL]ALIASES.DAT




GMXALIAS will automatically create the MX alias database the first time you add an alias definition.

?MXALIAS can be executed by setting up a foreign symbol in your LOGIN.COM:

 

"
!$ mxalias :== $mx_exe:mxalias.exe




FYour system manager may have already defined it for you in the system Alogin procedure. You can also just use RUN MX_EXE:MXALIAS to run MXALIAS.

HWhen MXALIAS is invoked without any parameters on the DCL command, your Hare put into an interactive mode. The prompt is "MXalias>":

 

"
	$ mxaliasMXalias> 




FAt the MXALIAS prompt, you can ADD aliases, MODIFY them, REMOVE them, Aand list them using the DIRECTORY command. There is on-line help 3available by typing HELP at the MXalias> prompt.#S

2.1 Adding an MX Alias



EThe MXALIAS command ADD is used to add an alias to the database. ADD Etakes three parameters: the alias to define, the equivalent address, Gand an optional description for the alias. The following example shows a typical definition:

 

"
FMXalias> add joe "smith@somewhere.com" "Joe Smith, Somewhere, Inc."$Added alias JOE to MX alias databaseMXalias>




AThe alias, JOE in the example above, can be a string of up to 20 Galphanumeric characters (plus $, -, _, and .) that is equated with the Hgiven e-mail address. The alias is the address given to MX from the VMS HMail "To:" line using a format like MX%alias. All aliases are converted to uppercase.

6The given address must be a valid address in the form D"user@host". If the domain is omitted, it defaults to the Alocal host (as defined by the MX_VMSMAIL_LOCALHOST logical). The @maximum length of the address is 255 characters. If you want to @preserve the case of an address, or if the address contains the H"!" character, you must enclose the address in double-quotes. GIf the address includes quotes, the address should be quoted, with the 0inside quotes doubled ("""node::user""@domain").

BThe description is any quoted string of up to 255 characters. The Fdescription is displayed by the DIRECTORY command; it is not included ,in the mail headers of the outgoing message.#R

2.2 Using an MX Alias



DOnce an MX alias has been added to the MX alias database, it can be Hused on the VMS Mail "To:" line by simply prefixing the alias Ename with MX%. MX will check every address that does not include the E"@" character to see if it is an MX alias. For example, if HJOE is defined as an alias, the following "To:" line would be specified:

 

"
MAIL> SENDTo:     MX%JOESubj:   ....




HSending to MX%"JOE@localhost" will prevent MX from performing Ethe alias translation, in case you want to send mail to a local user name JOE.'Q

2.2.1 Disabling System-Wide MX Alias Lookups



@MX supports both a personal MX alias database and a system-wide G(global) alias database created by your system manager. If an alias is Hnot found in your personal database, MX will see if it's defined in the Hglobal database and, if so, it will use that definition. If your system Fmanager has defined a global database and you wish to prevent MX from ;accessing it, you can do so by using the following command:

 

"
&$ define mx_global_alias_database _nl:




HThat command causes MX to attempt to open the null device as the global Bdatabase, which effectively disables a system-wide alias database.$M

2.2.2 Displaying MX Address Translations



HTo see the resulting addresses used by MX for all MX% addresses, define )the logical MX_VMSMAIL_SHOW_ADDR as TRUE:

 

"
"$ define mx_vmsmail_show_addr true$ mail 
MAIL> SEND3To:     MX%JOE, MX%"MX-List@WKUVX1.WKU.EDU", SYSTEM7  MX rewrote alias JOE as <SYSTEM@WKUVX1.WKU.EDU>E  MX rewrote MX-List@WKUVX1.WKU.EDU as <MX-List@WKUVX1.WKU.EDU>Subj:   ....




GThe MX_VMSMAIL_SHOW_ADDR works regardless of whether or not MX aliases Fare specified. If you always want to see MX address translations, you -can put the DEFINE command in your LOGIN.COM.#S

2.3 Displaying Aliases



GThe MXALIAS command DIRECTORY is used to display your defined aliases. EBy default, the brief directory listing shows only the alias and the comment, if there is one:

 

"
MXalias> dir!MX Alias              Description!------------          -----------0JOE                   Joe Smith, Somewhere, Inc.MXalias>




DWildcards can be given to limit the display to aliases matching the Bgiven pattern. The DIRECTORY/FULL command can be used to show the equivalent e-mail addresses.

FThe /OUTPUT=file qualifier can be used to write the directory listing to a text file.#R

2.4 Modifying Aliases



FThe MODIFY command is used to modify an existing alias definition. It Faccepts the alias name as a parameter and the qualifiers /ADDRESS and /DESCRIPTION. For example:

 

"
9MXalias> MODIFY JOE/DESCRIPTION="Local system manager"Modified alias JOEMXalias>


&Q

2.5 Removing Aliases



EThe REMOVE command is used to remove an alias definition from the MX Halias database. By default, it prompts the user for confirmation before removing the specified alias:

 

"
MXalias> remove joe/Remove JOE <SYSTEM@WKUVX1.WKU.EDU> [N]? yRemoved alias JOEMXalias>




EYou can supply the qualifier /NOCONFIRM to override the confirmation prompt. 


F

Chapter 3
Electronic Mailing Lists




FWhen talking about electronic mail, the term mailing list is Ggenerally used to describe an E-mail address that forwards messages to Dmore than one user. Mailing lists abound on the Internet, on a wide .variety of technical and non-technical topics.

=Unfortunately, there are no widely-enforced standards on the Eimplementation of mailing lists, so their use will vary depending on 2the systems on which the mailing lists are set up._

3.1 Typical Internet Mailing Lists



HFor most Internet mailing lists, there are generally two addresses: one Cfor the mailing list itself, and one for "administrivia" E(subscription requests, etc.). The administrative address is usually Hthe mailing list name with "-request" added. For example, the 0mailing list for discussing Message Exchange is @MX-List@WKUVX1.WKU.EDU. Subscription requests, 1removals, or comments about the list are sent to 0MX-List-request@WKUVX1.WKU.EDU.

BMany Internet mailing lists are managed manually, so mail sent to G-request addresses can usually be free-form. However, some systems, MX Aincluded, have mailing list handlers which process some types of Frequests automatically, without human intervention. The syntax of the Gcommands you send to these automated handlers will vary from system to ?system. For example, the MX mailing list processor accepts the following commands:                                        
 SUBSCRIBE # for getting added to the list
SIGNOFF ' for getting removed from the list
REVIEW + for getting a list of the subscribers
HELP for getting a help message
QUERY 5 for getting the status of your subscriber entry
 SET [NO]CONCEAL E for concealing or revealing your e-mail address in REVIEW lists
 SET [NO]DIGEST K for switching between reception of regular list traffic and periodic E digests (only applies to lists that have corresponding digests)
 SET [NO]MAIL F for enabling/disabling receipt of list messages while remaining  subscribed to the list
 SET [NO]REPRO > for enabling/disabling receipt of your own list postings
QUIT 4 for preventing the parsing of a mail signature


HCommands must generally be placed in the body of a mail message, rather than on the Subject line. 


E

Chapter 4
Mail-Based File Servers




DThe term file server, for the purposes of this document, Arefers to a network entity that maintains a library of files and Fdelivers them to users on demand. While most files are served via FTP Cor HTTP, some older systems may still use e-mail for file delivery.

FThere are no standards for mail-based file servers. There are several Gfile server implementations in existence: LISTSERV, VMSSERV, MAILSERV, Eand several others. MX also includes a file server module, generally referred to as FileServ.I

4.1 Get HELP



FIf you want to obtain files from a file server, and you are unsure of Bthe commands you need to use, you should begin by requesting help Cinformation from the server. The best way to do this is to send an FE-mail message to the file server's address with the word HELP on the Hsubject line and on the first and only line of the body of the Hmessage. Most servers will mail you back a message listing the commands Fthey accept and the format the commands should take, along with other helpful information.

EIf you cannot get assistance from the file server itself, you may be Aable to get some from the postmaster on the file server's system.U

4.2 MX FileServ Commands



CThe MX file server, usually called FileServ, accepts commands, one Dcommand per line, in the body of an E-mail message. The commands it accepts are:                        
 ADDRESS valid-address % provides a valid e-mail address
 LIST [pattern] 5 lists all packages matching "pattern"
 DIRECTORY [pattern]  same as LIST
 SENDME package[.part] 3 sends an entire package or the specified part
HELP  sends a help message
QUIT ; causes any lines following this command to be ignored


EFileServ commands may be abbreviated to their shortest unique string.

>ADDRESS provides the user with the ability to specify a valid FRFC822-compliant e-mail address to which any FileServ output is to be Bsent. Normally, any files requested from FileServ are sent to the Gaddress in the "Reply-To:" or "From:" lines in the Hmessage headers. However, addresses are sometimes corrupted by gateways Athrough which the message passes, resulting in an invalid return Daddress. File server users can use the ADDRESS command to provide a 1valid alternate to the "From:" address.



/  
Note

FWhen an ADDRESS command is processed, the file server transaction log Dincludes the original "From:" address. Any user receiving Funasked-for files can use it to determine from whom the request came. 
3

4.2.1 Packages



GA package is a collection of related files that are grouped Dtogether for distribution. FileServ, along with other file servers, Gdistributes files in packages. These packages are usually in a special Fformat for distribution over the network via E-mail; once you collect Gall of the parts in a package, the parts are combined together and fed Ethrough an unpacking program (sometimes contained within the package 5itself) to recreate the original collection of files.7

4.2.2 Binary Files



EBecause E-mail systems generally do not properly handle binary data, Abinary files (such as executable images or compressed files) are Hgenerally encoded before being packaged and distributed by a Hfile server. Once unloaded from the package, the encoded file must then Gbe decoded to recreate the binary file. The type of encoding will vary from system to system.

CIn addition, large files may be compressed before being Dencoded and packaged, to cut down on the network bandwidth required Awhen transmitting the package. Restoring the original files then -requires an additional decompression program.


E

Appendix A
Message Header Format




DMost network mail systems require or include more information about @messages than VMS MAIL can handle. MX, for example, follows the HInternet message format standard, usually called RFC 822 after 5the number of the document that describes the format.

FWhen you receive a message via MX, the FROM address identified in the EVMS MAIL headers will begin with the MX% prefix, which allows you to DREPLY to the message. In addition to the VMS MAIL headers, you will Galso see the RFC 822 header information, which is usually displayed as Ethe first part of the message text (this is under the control of the system manager). For example:

 

"
F    #1          29-FEB-1992 10:36:22.11                       NEWMAIL (From:   MX%"naive@myhost.mycompany.com" To:     MANAGER CC: Subj:   Question  0Return-Path: <naive@myhost.mycompany.com> GReceived: from myhost.mycompany.com by mgrsta.mycompany.com (MX V3.0); (          Thu, 29 Feb 1992 10:35:10 EST GReceived: by myhost.mycompany.com (MX V3.0) id 31437; Thu, 29 Feb 1992           10:35:05 EST +Resent-Date: Thu, 29 Feb 1992 10:35:01 EST )Resent-From: system@myhost.mycompany.com (Resent-To: manager@mgrsta.mycompany.com +Sender: <naive@myhost.mycompany.com> $Date: Thu, 29 Feb 1992 10:34:55 EST 4From: Naive User <naive@myhost.mycompany.com> %Reply-To: naive@myhost.mycompany.com AMessage-ID: <00933068.08a17f00.31437@myhost.mycompany.com>  To: system@myhost.mycompany.com Subject: Question  How do I send E-mail? 




CThe first five lines of this message are the VMS MAIL headers. The Fmessage text starts with the RFC 822 headers, followed by the message Bitself. The following sections explain the meaning of the RFC 822 headers.

CReturn-Path. The return address as appears on the Genvelope of the message. This usually identifies the route the message Gtook in getting to you, and can be used to identify forged messages in Gsome cases. The return path is used as the VMS MAIL From address if no other address is available.

EReceived. There may be several of these lines for a Hmessage. They usually indicate how and when the message was transferred @from one system to another. They are provided for informational purposes only.

HResent- lines. If the message is forwarded (usually by Han automatic mechanism such as SET FORWARD in VMS MAIL), some messaging Asystems (MX included) will include information about when it was Gforwarded and who it was forwarded to. One set of Resent lines usually appears for each forwarding hop.

HSender. This line indicates the sender of the message, ;which could be different from the address in the From line.

ADate. This line indicates the date and time the Hmessage was entered into the mail system by the sender. It will usually Hinclude the local time for the sender, which may be in a different time zone.

GFrom. This line indicates who the message is from. If Fthe message was sent by someone on behalf of another person or group, Ethe message will also include a Sender line to identify the .person or agent who actually sent the message.

HReply-To. If the sender wants to receive replies at an Aaddress different from the From address, a Reply-To line will be !included to redirect the replies.

HMessage-ID. The message identifier uniquely identifies Ca message. Message-ID's are used by some mail systems for tracking messages and replies.

ATo. Identifies the target user or users for the 6message. Also included can be CC and EBCC lines that identify users to whom a carbon copy 9and "blind" carbon copy of the message is sent.

DSubject. A brief description of the subject of the message.

EOther headers are also possible, some of which are extensions to the FRFC 822 message standard. Also, the order in which the headers appear may vary from system to system.Q

A.1 VMS MAIL Headers



HMX automatically translates some of the RFC 822 header information into VMS MAIL headers.6

A.1.1 From Header



FThere are several RFC 822 headers used for identifying the originator Eof a message. VMS MAIL, however, allows only one. To allow the REPLY Hcommand to work properly, therefore, MX fills in the VMS MAIL From line Gwith the address that should be used in generating a reply. This reply Haddress 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 Hsyntactically valid. Since most mail systems provide a valid address in ?the Reply-To and/or From headers, this should not be a problem.<

A.1.2 To and CC Headers



EThe VMS MAIL To and CC headers will list only the users on the local Dsystem receiving the message. To see the actual list of recipients, 9examine the To, CC, and BCC lines in the RFC 822 headers.9

A.1.3 Subject Header



GThe VMS MAIL Subject header should be identical to the RFC 822 Subject header, if one exists.

 .
^ Contents