This chapter describes how to configure the MultiNet SMTP (Simple Mail Transport Protocol) server to send and receive electronic mail.
If you are running PMDF or another mail system that provides its own SMTP support, refer to that mail system's documentation.
The MultiNet SMTP configuration is stored in the START_SMTP.COM and START_SMTP_LOCAL.COM startup command procedures. Use the MAIL-CONFIG utility to edit these files. You start the utility by entering the MULTINET CONFIGURE /MAIL command. After using this configuration utility, stop and restart the mail queues. Enter:
· @MULTINET:START_SMTP.COM to update the VMScluster.
· @MULTINET:START_SMTP_LOCAL.COM to update the local host only.
The current release of SMTP implements Extended SMTP (RFC-1869) and Pipelining (RFC-2197)
The SMTP server supports mail delivery to folders other than the NEWMAIL folder. The folder names are restricted to UPPERCASE characters only, the pound sign (#), and the underscore (_). Use of the comma (,) in a folder name causes an error. Mail addressed to user+folder@host is delivered to the specified folder. You can disable this mechanism by defining the system-wide logical name MULTINET_SMTP_DISABLE_FOLDER_DELIVERY.
The current release of SMTP supports alias file extensions that request mail delivery to a file or specify addresses in a separate file. You must use the SMTP aliases file, specified with MULTINET CONFIG/MAIL, to list all of these mail delivery mechanisms. The default is MULTINET:SMTP_ALIASES. The syntax for these aliases follows the form of those described in Configuring Mail Aliases found later in this chapter. It is necessary to use the colon and semicolon in the command lines as shown in the examples.
|
<device:[directory]address.list |
Delivers mail to the list of addresses in the specified file.
alias1 : "<filespec" ; |
|
| device:[directory]procedure.com parameter(s) |
Submits the specified command procedure to the queue identified by the logical name MULTINET_SMTP_BATCH_QUEUE, SYS$BATCH by default. The first parameter (P1), passed to the submitted procedure, is always the name of a temporary file containing the mail message that the procedure must delete. Any parameter(s) specified in the alias file are passed to the submitted procedure in a single string as its second parameter (P2).
alias2 : "|filespec p2 p3" ; |
|
>device:[directory]mail.file |
Appends mail to the specified file. If no filetype is specified, the default is .yyyy-mm, yyyy and mm are to the current year and month, respectively.
alias3 : ">filespec" ; |
The SMTP server supports a set of rules for rejecting mail messages received by itself based on the mail header contents or any combination of MAIL FROM, RCPT TO, and Source IP Address values. Mail matching the criteria can be ignored or rejected quietly with a message to the SMTP client or delivered to an address rewritten according to the rule specification. This capability can be useful for controlling SPAM and preventing your system from being used as a mail relay.
The file MULTINET:SMTP_SERVER_REJECT. contains the rejection and rewrite rules. You may specify an alternate file via the logical name MULTINET_SMTP_SERVER_REJECT_FILE. A rejection file line of the form #include device:[directory]reject.file temporarily suspends processing of the current file and begins processing of the specified file. Rejection files can be nested to arbitrary depth. Comments may be included in rejection files by placing any of the characters ; or ! or # in the first column of a line. The following is a sample rejection file:
!
! This is a sample reject file for the company FLOWERS.COM.
!
! This file is processed sequentially. In other words, processing ends on ! the
first rule that the message applies to. So if you have a wildcard
! accept at the top of this file, then no other rules will be processed.
!
! Entries can have one of the following formats:
!
! from_user [from_ip to_user action action-data]
!
! :rfc822 header
!
! Wildcards can be used in FROM_USER, FROM_IP, and TO_USER. ACTION is the !
reject action, which is one of:
!
! n Don't reject, but rewrite TO address to be ACTION-DATA.
! If ACTION-DATA is blank then we simply deliver to TO_USER.
!
! y Reject and use optional ACTION-FIELD as a rejection message
! format that can contain up to three %s formatting
! designators for mail from, mail to, and local domainname.
!
! q Reject quietly -- don't inform Sending SMTP Client that
! message will be discarded. If only FROM_USER is specified
! other fields default to FROM_IP=*, TO_USER=*, and ACTION=n.
!
! Don't rewrite or reject any mail to "postmaster*"
!
! * * postmaster* n
!
! Accept all messages with MAIL FROM:<> (bounce messages)
! This rule is commented out because you probably don't want it, although !
We're _supposed_ to always accept it. This is the main method relay
! attacks use, by always saying they are from <> to take advantage of
that ! RFC hole.
!
! <> * * n
!
! Reject anything with a Message-ID that appears to have originated from
! cyberpromo.com or nowhere.com
!
:Message-ID: <*@cyberpromo.com>
:Message-ID: <*@nowhere.com>
!
! Reject mail from well-known SPAM sites with sample non-standard error
! messages.
!
<*answerme.com> * * y "Spam from <%s> rejected"
<*cyberpromo.com> * * y "Spam from <%s> to <%s>
rejected"
<*pleaseread.com> * * y "Spam rejected;%.0s%.0s Contact
postmaster@%s"
!
! Disallow percent-hacks (e.g, joe%somewhere.com@flowers.com)
!
* * *@*@*flowers.com y "No forwarding-path relaying
allowed"
!
! Disallow "!" UUCP hacks (e.g. somewhere.com!joe@flowers.com)
!
* * *!* y "No UUCP relaying allowed"
!
! Rewrite all mail to webmaster to the postmaster
!
* * webmaster@*flowers.com n postmaster@flowers.com
!
!
! Disallow relaying through our mailer, and only allow users on our
! networks to claim to be from our company (flowers.com)
!
* * *@flowers.com n
* * *@daisy.flowers.com n
* * *@[10.0.0.1] n
!
<*flowers.com> 10.0.0.* * n
<*flowers.com> 10.115.140.* * n
<*flowers.com> 10.115.141.* * n
!
! Allow our internal systems to bounce mail out.
!
<> 10.0.0.* * n
<> 10.115.140.* * n
<> 10.115.141.* * n
!
! If a message has slipped through all the tests above, then we want to
! reject it, as they are either relaying through us or it's not a valid
! MAIL FROM.
!
*@* * *@* y "no relaying through this site"
* * *@* y "missing domain name in MAIL FROM"
!
!end of sample file
Mail rejection rules have two formats:
1. :RFC822_header pattern
This format causes rejection of any mail in which a line with the specified header matches the given pattern. The following rejection message is sent to the client:
554 ssage rejected due to header contents
Note! Use caution when rejecting mail based on header contents. No other criteria are considered during rejection processing.
2. from_user ip_address to_user action action_data
This format causes rejection or alternate delivery of all messages that match all of the patterns specified. The action item can be as follows:
|
n |
Means do not reject the mail, but deliver it to the address specified as the action_data. If action_data is not specified, deliver the message to its intended recipient. |
|
y |
Means reject the mail, sending the action_data string to the SMTP client as a rejection message. The action_data item is actually used as a format string and may contain from one to three %s formatting designators to include the from_user, the to_user, and the SMTP server name, in that order. If action_data is missing, the default rejection message is:
553-Mail to <to_user>
not allowed; |
|
q |
Means reject the mail, but do not give the SMTP client any indication that it has been rejected. Use caution when rejecting messages quietly. |
Each of the pattern specifications pattern, from_user, ip_address, and to_user may contain the OpenVMS * and % wildcard characters.
You can represent from_addr expressions in the SMTP_SERVER_REJECT filter with the <> syntax. So, *@*domain.com and <*@*domain.com> are the same expression. To return to the previous behavior, add the following line to the top of your SMTP_SERVER_REJECT file:
<> * * n
(Accept any mail with a MAIL FROM: of <>)
When comparing the RCPT TO: address with the SMTP_SERVER_REJECT file expressions, any % signs in the RCPT TO: address are changed to @. You can write filter rules in the SMTP_SERVER_REJECT files that can match against forward-path relays. You can add the rule of
* * *@*@localdomain y “No forward-path relaying allowed”
to your SMTP_SERVER_REJECT file above the rules that accept mail with the destination of your domains. RCPT TO: addresses will replace any % character with the @ character for matching purposes only so you can filter with *@*@*-type rules. So, RCPT TO:<xxx%yyy@zzz> is changed to xxx@yyy@zzz. You can use the logical name MULTINET_SMTP_SERVER_REJECT_INFO to control debug and informational OPCOM messages produced during rejection processing. You should define it to have some non-zero value to request OPCOM messages. The following values may be combined to control message quantity and content:
|
Values |
To show... |
|
1 |
mail rejected due to action y |
|
2 |
rewritten addresses (action n with action_data) |
|
4 |
the reject message sent to the remote system |
|
8 |
configuration file parsing |
|
16 |
non-written addresses (action n and no action_data) |
|
32 |
mail rejected due to action q |
|
64 |
mail rejected due to header rules |
The value 65 is appropriate for auditing rejection activity.
The SMTP service supports both IPv4 and IPv6. There are no configuration parameters to control which one is used, though system managers should be aware of potential reachability issues when switching SMTP to use IPv6.
The remainder of this chapter describes the configuration tasks.
The following sections discuss how to get SMTP statistics and accounting information.
Partial support for RFC 2788 (Network Monitoring MIB) has been added to SMTP. To use the 2788 feature, do the following:
$ MULTINET CONFIGURE/SERVER
SELECT SMTP
SET FLAGS SNMP_MONITORED
WRITE
EXIT
$ @MULTINET:START_SERVER
This feature requires the SNMP Agent X functionality; to use this SNMP must be configured to have Agent X service enabled, and to allow 127.0.0.1 to be an AGENTX_PEER. See Chapter 23 for more information on SNMP and Agent X.
SMTP’s network service monitoring is based on RFC 2788 (Monitoring MIB). Information is maintained only while the service is active. The following items from the Network Services Monitoring MIB (RFC 2788) are available in the enterprises.105.2.25 MIB:
|
ApplAccumulatedInboundAssociations |
(Counter) the total number of connections that the SMTP program has serviced since it was started. enterprises.105.2.25.10 |
|
ApplDescription |
(String) Description of the program/application. enterprises.105.2.25.16 |
|
ApplInboundAssociations |
(Counter) The number of connections currently active. enterprises.105.2.25.8 |
|
ApplIndex |
(Integer) unique application index. The port SMTP is offered on (25). enterprises.105.2.25.1 |
|
ApplLastChange |
(TimeTicks) the value of sysUpTime when the SMTP program entered the
current state. |
|
ApplLastInboundActivity |
(TimeTicks) the value of sysUpTime at the time the most recent connection was established. enterprises.105.2.25.12 |
|
ApplName |
(String) SMTP. enterprises.105.2.25.2 |
|
ApplOperStatus |
(Integer) the operational status of the SMTP program; the values are: up(1), down(2), halted(3), congested(4), restarting(5), quiescing(6). Some of these values may not be used. enterprises.105.2.25.6 |
|
ApplRejectedInboundAssociations |
(Counter) the number of connections that have been rejected (due to not being allowed from the access list values). enterprises.105.2.25.14 |
|
ApplUptime |
(TimeTicks) the value of the SNMP variable sysUpTime when the SMTP program was started. enterprises.105.2.25.5 |
|
ApplVersion |
(String) the version of the SMTP program. enterprises.105.2.25.4 When displaying the enterprises.105.2.25 MIB, entries for 1 to 17 will display but some (specifically .3, .9, .11, .13, .15, .17) will have 0 values. |
Partial support for RFC 2789 (Mail Monitoring MIB) has been added to SMTP. To enable this feature, do the following:
$ MULTINET CONFIGURE/MAIL
SET RFC2789 TRUE
WRITE
EXIT
$ @MULTINET:START_SMTP
This feature requires the SNMP Agent X functionality; to use this SNMP must be configured to have Agent X service enabled, and to allow 127.0.0.1 and the system’s own IP address to be an AGENTX_PEER. See Chapter 23 for more information on SNMP and Agent X.
|
MtaReceivedMessages |
The number of messages received since Message Transfer Agent (MTA)
initialization. |
|
MtaStoredMessages |
The total number of messages currently stored in the MTA. enterprises.105.3.25.2 |
|
MtaTransmittedMessages |
The number of messages transmitted since MTA initialization. enterprises.105.3.25.3 |
|
MtaReceivedVolume |
The total volume of messages received since MTA initialization,
measured in kilo-octets. |
|
MtaStoredVolume |
The total volume of messages currently stored in the MTA, measured in kilo-octets. enterprises.105.3.25.5 |
|
MtaTransmittedVolume |
The total volume of messages transmitted since MTA initialization,
measured in kilo-octets. |
|
MtaReceivedRecipients |
The total number of recipients specified in all messages received
since MTA initialization. |
|
MtaStoredRecipients |
The total number of recipients specified in all messages currently stored in the MTA. enterprises.105.3.25.8 |
|
MtaTransmittedRecipients |
The total number of recipients specified in all messages transmitted
since MTA initialization. |
|
MtaSuccessfulConvertedMessages |
The number of messages that have been successfully converted from one form to another since MTA initialization. enterprises.105.3.25.10 |
|
MtaFailedConvertedMessages |
The number of messages for which an unsuccessful attempt was made to
convert them from one form to another since MTA initialization. |
This information can be displayed with the MULTINET SHOW /SNMP command. See the SHOW /SNMP command in the MultiNet for OpenVMS Administrator’s Reference.
MultiNet can record accounting information from services that have been enabled. Currently this includes FTP and SMTP. The accounting information includes information about when a network session took place and how much data was transferred. The accounting facility is enabled from MULTINET CONFIGURE/SERVER and reads MULTINET:ACCOUNTING.CONF for additional configuration information. The format of the accounting records is described in MULTINET_ROOT:[MULTINET.EXAMPLES]ACCOUNTING.H
A sample program using this is in MULTINET_ROOT:[MULTINET.EXAMPLES]ACC_DUMP.C
To configure Session Accounting, follow these steps:
1. Edit the ACCOUNTING configuration file, as described in the next section.
2. To start the procedure, do the following:
$ MULTINET CONFIGURE/SERVER
ENABLE ACCOUNTING
WRITE
$ @MULTINET:START_SERVER
The Accounting configuration file is MULTINET:ACCOUNTING.CONF. The Accounting configuration file defines:
· The Port the Accounting program listens on. This should be an unused port, not the port for the service on which logging is being enabled.
· The name of the file used for accounting records. This file is opened shareable and new records are always appended to it. To start a new file stop the Accounting program, delete (or rename) the existing file, and restart the Accounting program.
· The IP addresses of systems that are allowed to write accounting records to this host.
Note! After editing the configuration, stop and restart the Accounting program so that the changes can take effect.
Follow these guidelines when entering data in the Accounting configuration file:
· Allow one line for each item.
· Enter information in any order; in uppercase or lowercase.
· Use a pound sign (#) or exclamation point (!) to denote comments. The Accounting facility ignores all information following these characters.
The commands that can be in MULTINET:ACCOUNTING.CONF are:
|
PORT port_number |
The TCP port that the accounting program should listen on. |
|
PEER ip-address |
The IP address of a host that is allowed to log records with the accounting software. |
|
FILENAME filename |
The name of the file that the accounting records will be written to. The MULTINET: device is assumed if a device is not specified as part of the file specification. |
To view accounting information, do the following:
$ MULTINET ACCOUNTING/INPUT=<accounting_data_file>
[/output=output filename] -
_$ [/since=start_date] [/before=end_date]
[/protocol={SMTP, FTP, MAIL}] [/CSV]
· accounting_data_file is the name of the logging file you want to see.
· output filename is the name of the file you want to call this information. If this field is omitted, the information displays to the terminal screen.
·
start_date is the beginning date you want
the command to start with. The date format is
[DD-MMM-YYYY
[:]] [hh:mm:ss]cc] If not
specified, all records display up to the end of the data found.
o DD is the day of the month, counting from 01.
o MMM is the abbreviation for the month, like JAN, FEB, MAR.
o YYYY is the number of the year, including the century (1999, 2000, 2001, 2002, 2003).
o hh is the hour, from 00 to 23.
o mm is the minute, from 00 to 59.
o ss is the second, from 00 to 59.
o cc is hundredths of seconds.
The time is always in local time.
·
end_date is the ending date you want the
command to end with. The date format is
[DD-MMM-YYYY
[:]] [hh:mm:ss]cc] If not
specified, all records display until the end of the file.
· protocol is any combination of SMTP, FTP, or MAIL.
· CSV is the Comma Separated Values, for input to products like Excel.
The accounting file is written using OpenVMS RMS records. The format of these records is defined in MULTINET_ROOT:[MULTINET.EXAMPLES]ACCOUNTING.H, and listed below:
struct accountingPDU {
char version;
char type; /* type of record */
/*
* FTP:
* C - Client
* S - Server
*
* SMTP:
* N - Network delivery (send)
* L - Local delivery (received)
* R - Rejected message
*
*/
char flags; /* not currently used */
char reserved; /* for future use */
int payload_length; /* length (in bytes) of data after header */
int port; /* IP port of reporting service - 25 SMTP, 21 - FTP
*/
int reporterIP; /* IP address of reporter */
};
struct FTPaccounting_data {
struct accountingPDU header;
int start_time[2]; /* VMS time that session started */
int end_time[2]; /* VMS time that session ended */
int datasent; /* KBytes of file data sent */
int datarecv; /* KBytes of file data received */
int filessent; /* Number of files sent */
int filesrecv; /* Number of files received */
int partnerIP; /* IP address of partner */
char user[12]; /* username that operations were done under */
};
struct SMTPaccounting_data {
struct accountingPDU header;
int date[2]; /* Time of activity */
int msg_size; /* size of message in bytes */
int from_str_size; /* size of From: string */
int to_str_size; /* size of To: string */
char from_to_str[1]; /* text of From & To string */
};
To configure SMTP for accounting purposes, do the following:
$ MULTINET CONFIGURE/MAIL
SET ACCOUNTING-HOST hostname
SET ACCOUNTING-PORT port number
WRITE
EXIT
$ @MULTINET:START_SMTP
The collected accounting information can be displayed with the MULTINET ACCOUNTING command.
See the MULTINET ACCOUNTING command in the MultiNet Administrator’s Reference.
The parameters that control the operations of the MultiNet mailer are described in the table below.
To configure mail parameters with the MAIL-CONFIG utility:
1. Start MAIL-CONFIG with the MULTINET CONFIGURE /MAIL command.
2. Use the SET parameter_name commands (for detailed descriptions of these commands, refer to the MultiNet Administrator's Reference).
3. Save the configuration with the SAVE command.
4. Quit MAIL-CONFIG with the QUIT command.
The modified configuration takes effect the next time your system reboots or the queues are restarted.
The table below describes all the mail parameters you can set with the MAIL-CONFIG utility.
|
Parameter |
Description |
|
ALIAS-FILE |
File in which SMTP aliases are stored; see the Configuring Mail Aliases section. |
|
DECNET-DOMAIN |
Domain name for DECnet gateway function; see the Configuring the SMTP-DECnet Mail Gateway section. |
|
DELIVERY-RECEIPTS |
Specifies whether mail receipts are sent when incoming mail containing Delivery-Receipt-To: or Return-Receipt-To: headers is submitted to the SMTP queue. If TRUE, mail receipts are sent. |
|
DISALLOW-USER-REPLY-TO |
When TRUE, prevents VMS MAIL users from setting a Reply-To: header address with the logical name MULTINET_SMTP_REPLY_TO. |
|
FORWARDER |
Identifies a host (known as a mail hub) to which mail should be forwarded if a host name cannot be resolved for an address. The specified name must resolve to an IP address; it must not resolve to an MX record. |
|
FORW ARD-LOCAL-MAIL |
Forwards all mail designated for local users to the mail hub instead of delivering it locally. Can be overridden by entries in the SMTP_ALIASES file. |
|
FORWARD-REMOTE-MAIL |
Forwards all SMTP-delivered mail to the mail hub instead of directly to the destination host. Can be overridden by a GATEWAY or LOCAL-DOMAIN entry. |
|
HEADER-CONTROL |
Controls which RFC-822 headers appear in messages delivered to VMS MAIL users. |
|
HOST-ALIAS-FILE |
Contains a list of host names considered aliases for the local host name. |
|
LOCAL-MAIL-FORWARDER |
Identifies a host to which mail should be forwarded when a local mail delivery fails because the user name is unknown. |
|
POSTMASTER |
Identifies the user name of the system postmaster. |
|
QUEUE-COUNT |
Specifies the number of mail processing queues to create on a particular system. |
|
REPLY-CONTROL |
Specifies how Internet mail headers should be mapped to the VMS MAIL from header. Permitted values are FROM and REPLY-TO. You may specify both as a comma-separated list. |
|
RESENT-HEADERS |
When FALSE, the SMTP symbiont omits the Resent-From, Resent-To, and Resent-Date headers that are usually included when a message is forwarded using a VMS MAIL forwarding address. |
|
RETRY-INTERVAL |
Specifies the amount of time (in minutes) that should elapse after a failed attempt before another attempt is made. |
|
RETURN-INTERVAL |
Specifies the amount of time (in hours) a message can remain in the processing queue before it is returned to sender. |
|
SEND-BROADCAST-CLASS |
Controls the OpenVMS broadcast class used by SMTP for SEND-type messages (which are sent to a terminal). |
|
SMTP-HOST-NAMES |
A list of up to 16 host names to consider as aliases for the local host. See the Specifying SMTP Host Aliases section. |
|
START-QUEUE-MANAGER |
Determines whether START_SMTP.COM starts the VMS queue manager if it is not already running. |
To configure mail parameters via logical name, see the MultiNet Administrator's Reference.
When using a logical name to configure mail parameters, if the setting is for all users, define the logical system-wide. For example:
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_SPOOL [PATH.DIRECTORY]
An SMTP SYMBIONT logical may be set up to enable additional logging for debugging purposes.
For example:
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_SMTP_SYMBIONT_LOG TRUE
will enable logging. The default logging filename and location is MULTINET:MULTINET_SMTP_LOG.queuename. If you wish to change the location and/or filename, you may define:
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_SMTP_LOG "filespec"
where filespec is similar to DEVICE:[dir]filename. If the filename does not specify an extension, then the queuename will be utilized.
If the logical MULTINET_SMTP_ALLOW_MIME_SEND is defined to Yes, 1 or True, then if the first line of the message file being sent begins with the mime tag, the blank line at the end of the header section will be suppressed so that the header lines in the mime message file will be seen as header lines rather than message body. The string that is used as the mime tag can be controlled with the logical MULTINET_SMTP_MIME_TAG which defaults to “Mime-version:”
Outbound mail sanity checking can be used to test the operation type of the mail message before it is sent out. If there is no operation type, the file is not sent. Use this logical to disable sanity checking:
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_SMTP_DISABLE_OPTYPE_SANITY_CHECK
The MultiNet SMTP server accepts mail from remote hosts and delivers it to users' mailboxes.
By default, the SMTP server is disabled when you install MultiNet. For details on configuring and controlling MultiNet servers, see Chapter 12.
MultiNet provides a logical name to solve the problem of systems sending messages containing lines terminated by an LF character only instead of the proper CR/LF sequence. The following command tells MultiNet to accept the bare LF as the end-of-line indicator:
$ DEFINE/SYSTEM/EXEC MULTINET_SMTP_ACCEPT_UNIX_LF TRUE
MultiNet lets you validate the contents of the envelope-from field by defining the system-wide logical name MULTINET_SMTP_REJECT_INVALID_DOMAINS. Use the equivalence string STRICT to require the presence of a host in those addresses. For example, require MAIL FROM: <user@host> rather than MAIL FROM: <user>. The host specified in the MAIL FROM: address must exist in the DNS database.
The logical name MULTINET_SMTP_ACCEPT_UNIX_LF has been added as a synonym for MULTINET_SMTP_ACCEPT_UNIX_LF_BRAIN_DAMAGE. You can define either to have the same effect.
MultiNet provides you with a way to limit the system/vendor information given out on connection, HELP, and QUIT. The MULTINET_SMTP_SUPPRESS_VENDOR logical removes operating system and TCP stack information from SMTP server text responses.
MultiNet lets users send mail to remote destinations by submitting outbound messages to mail queues that are processed by the MultiNet SMTP symbiont. You can configure the SMTP symbiont to:
· Control users' ability to specify their own REPLY-To: headers (see the Specifying the REPLY_TO Header section.)
· Provide more than one server queue for each cluster node. By default, MultiNet provides one server queue for each cluster node running MultiNet (see the Configuring Mail Queues section).
· Forward mail through a central mail hub (see the Forwarding Mail through a Mail Hub section.)
· Use gateways to reach specific hosts, domains, or "virtual" domains (see the Configuring Mail Gateways section.)
· Use host aliases (see the Specifying SMTP Host Aliases section.)
· Use mail aliases (see the Configuring Mail Aliases section.)
You can also write your own SMTP dispatcher by modifying and compiling the SMTP user exit MULTINET_ROOT:[MULTINET.EXAMPLES]USER_SMTP_DISPATCH.C. Instructions for modifying the dispatcher are outside the scope of this manual.
For outbound mail, MultiNet SMTP eases the 255 character limitation on RFC-822 To: and CC: header lengths. The limit of 255 characters was imposed because some mail applications cannot handle headers longer than 255 characters.
The default header length is 1024 characters. The logical name MULTINET_SMTP_MAXIMUM_822_TO_LENGTH can be used to override the 1024 byte default length of the To: and Cc: header fields. The logical can set the maximum length to anywhere from 256 to 65535. To automatically lower the case of usernames in outbound messages, define the logical name MULTINET_VMSMAIL_LOCASE_USERNAME.
The MULTINET_SMTP_REPLY_TO logical name lets you specify the value for the RFC822 REPLY-TO: header. For example, to set your Reply-To: header to FNORD@PROCESS.COM, use the command:
$ DEFINE MULTINET_SMTP_REPLY_TO "FNORD@PROCESS.COM"
This logical name only affects mail agents that use the SMTP% interface (for example, OpenVMS and DECwindows mail). The system manager can disable the use of this logical name with the SET DISALLOW-USER-REPLY-TO command of the MULTINET CONFIGURE /MAIL utility.
To disable VRFY and EXPN processing, use the logical name MULTINET_SMTP_SERVER_DISABLE_VRFYEXPN. Define it to have some non-zero value to disable the requisite functions. The following values may be combined to specify which function:
|
Value |
Function |
|
1 |
to disable VRFY |
|
2 |
to disable EXPN |
|
3 |
to disable both VRFY and EXPN |
MultiNet uses OpenVMS server queues for SMTP processing. Initially, MultiNet configures each cluster node running MultiNet with a server queue and configures a generic queue for the entire cluster. New messages are placed in the generic queue for processing, which distributes mail processing to the first available server queue.
For example, if three clustered nodes, Huey, Louey, and Dewey, are running MultiNet, MultiNet creates three server queues and one generic queue. The queue names are:
SMTP_HUEY [Execution queue]
SMTP_LOUEY [Execution queue]
SMTP_DEWEY [Execution queue]
MULTINET_SMTP [Generic queue]
The following example lists the queues for node Huey:
$ SHOW QUEUE MULTINET_SMTP/FULL
Generic server queue MULTINET_SMTP
/GENERIC=(SMTP_HUEY,SMTP_LOUEY,SMTP_DEWEY) /OWNER=[SYSTEM]
/PROTECTION=(codes)
$ SHOW QUEUE SMTP_HUEY/FULL
Server queue SMTP_HUEY, idle, on HUEY::, mounted form DEFAULT
/BASE_PRIORITY=4 /DEFAULT=(FEED,FORM=DEFAULT) /OWNER=[SYSTEM]
/PROCESSOR=MULTINET_SMTP_SYMBIONT /PROTECTION=(codes)
The queues SMTP_LOUEY and SMTP_DEWEY are also created, and are similar to the SMTP_HUEY queue shown.
Note! A standalone (non-clustered machine) has two queues created by default; that is, one generic queue (MULTINET_SMTP) and one execution queue (SMTP_nodename).
If mail traffic is heavy on your system, you can configure multiple server queues on one or more nodes using MAIL-CONFIG. To configure multiple queues with the MAIL-CONFIG utility:
1. Start MAIL-CONFIG with the MULTINET CONFIGURE /MAIL command.
2. Use the SET QUEUE-COUNT command to specify the number of queues on the node (for a full description of this command, refer to the MultiNet Administrator's Reference).
3. Save the configuration with the SAVE command.
4. Quit MAIL-CONFIG with the QUIT command.
The modified configuration takes effect the next time your system reboots.
In heterogeneous cluster environments, you may need to partition mail processing by grouping homogeneous subsets of your cluster into queue groups using MAIL-CONFIG. To configure queue groups with the MAIL-CONFIG utility:
1. Start MAIL-CONFIG with the MULTINET CONFIGURE /MAIL command.
2. Use the ADD QUEUE-GROUP and DELETE QUEUE-GROUP commands to add or delete queues (for descriptions of these commands, refer to the MultiNet Administrator's Reference).
3. Save the configuration with the SAVE command.
4. Quit MAIL-CONFIG with the QUIT command.
The modified configuration takes effect the next time your system reboots.
Many sites provide outbound e-mail access to the Internet through a single system known as a mail hub to deliver all outbound mail on behalf of the other hosts at the site. A mail hub typically implements a single-address scheme for e-mail users at the site, so that all users have addresses of the form username@sitename rather than username@hostname.sitename. Site administrators often configure mail hubs to provide Internet e-mail access to hosts that do not have direct access to the Internet. To forward mail through a mail hub:
1. Specify the host that will serve as a mail hub.
2. Specify the conditions under which MultiNet forwards mail to the mail hub.
The following sections describe these procedures.
To specify the host that will serve as a mail hub for your MultiNet host:
1. Start MAIL-CONFIG (MULTINET CONFIGURE /MAIL).
2. Modify the FORWARDER parameter:
a. With MAIL-CONFIG, use the SET FORWARDER mailhub_hostname command.
3. If desired, set any of the following conditions for forwarding mail to the mail hub:
a. Forward mail addressed to users on remote hosts (see the Forwarding Mail Addressed to Remote Hosts section.)
b. Exclude hosts in specific domains from remote mail hub forwarding (see the Excluding Hosts in Specific Domains From Mail Forwarding section.)
c. Forward mail addressed to users on the local host (see the Forwarding Local Mail section.)
d. Exclude specific local users from mail hub forwarding (see the Excluding Specific Local Users from Mail Forwarding section.)
4. Exit the configuration utility. When prompted, save the new parameters.
5. To make the changes take effect immediately, stop and restart the mail queues. To update the VMScluster, use the @MULTINET:START_SMTP.COM command. To update the local host only, use the @MULTINET:START_SMTP_LOCAL.COM command. Otherwise, your changes take effect the next time you reboot your system.
To configure MultiNet to forward mail addressed to remote users via a mail hub:
1. Make sure the FORWARDER parameter specifies the host you want to use as a mail hub (see the Specifying a Mail Hub section.).
2. Start MAIL-CONFIG (MULTINET CONFIGURE /MAIL).
3. Modify the FORWARD-REMOTE-MAIL parameter:
a. With MAIL-CONFIG, use the SET FORWARD-REMOTE-MAIL TRUE command.
4. If desired, exclude hosts in specific domains from mail hub forwarding (see the Excluding Hosts in Specific Domains From Mail Forwarding section.).
5. If desired, specify other conditions under which MultiNet forwards mail to the mail hub (see the Specifying a Mail Hub section.).
6. Exit the configuration utility. When prompted, save the new parameters.
7. To make the changes take effect immediately, stop and restart the mail queues with @MULTINET:START_SMTP.COM to update the VMScluster or with @MULTINET:START_SMTP_LOCAL.COM to update the local host only. Otherwise, your changes take effect the next time you reboot your system.
If you configure MultiNet to forward mail addressed to remote users via a mail hub (see the Forwarding Local Mail section), you can exclude hosts in specific domains from the mail forwarding system by adding the domain to a list of "local domains." To modify the local domain list:
1. Make sure remote mail forwarding is enabled (see the Forwarding Mail Addressed to Remote Hosts section.).
2. Start MAIL-CONFIG (MULTINET CONFIGURE /MAIL).
3. To add a domain to the list:
a. With MAIL-CONFIG, use the ADD LOCAL-DOMAIN domain_name command. If domain_name begins with a dot, it specifies a domain name. Otherwise, domain_name specifies a host name.
4. To delete a domain from the list:
a. With MAIL-CONFIG, use the DELETE LOCAL-DOMAIN domain_name command.
5. Exit the configuration utility. When prompted, save the modified configuration.
6. To make the new configuration take effect immediately, stop and restart the mail queues with @MULTINET:START_SMTP.COM to update the VMScluster or with @MULTINET:START_SMTP_LOCAL.COM to update the local host only. Otherwise, your changes take effect the next time you reboot your system.
To configure MultiNet to forward mail addressed to local users via a mail hub:
1. Make sure the FORWARDER parameter specifies the host you want to use as a mail hub (see the Specifying a Mail Hub section.).
2. Start MAIL-CONFIG (MULTINET CONFIGURE /MAIL).
3. Modify the FORWARD-LOCAL-MAIL parameter:
a. With MAIL-CONFIG, use the SET FORWARD-LOCAL-MAIL TRUE command.
4. If desired, exclude specific local users from mail hub forwarding (see the Excluding Specific Local Users from Mail Forwarding section.).
5. Exit the configuration utility. When prompted, save the new parameters.
6. To make the changes take effect immediately, stop and restart the mail queues with @MULTINET:START_SMTP.COM to update the VMScluster or with @MULTINET:START_SMTP_LOCAL.COM to update the local host only. Otherwise, your changes take effect the next time you restart your system.
The logical name MULTINET_SMTP_APPEND_FORWARDER_TO_MX can be used to prevent SMTP from appending the forwarder to the MX list by default. To do this:
$ DEFINE/SYSTEM/EXECUTIVE MULTINET_SMTP_APPEND_FORWARDER_TO_MX FALSE
If the logical name is not defined (or is defined to anything not beginning with F, N, or 0), then the FORWARDER is appended to the MX list.
When the logical name MULTINET_SMTP_IGNORE_INTERFACE_NAMES
is defined (as
/system,
or any value), the MultiNet SMTP mail delivery procedure does not compare the
destination address with the addresses of the interfaces on the system to
determine if the message could be delivered locally. The default (no logical
defined) is to check the addresses of the interfaces on the system. Defining
this logical causes the MX records to be used exclusively in determining where
a mail message should be delivered.
If you configure MultiNet to forward local mail via a mail hub (see the Forwarding Local Mail section), you can exclude specific local users from the mail forwarding system by creating mail aliases for them in the MULTINET:SMTP_ALIASES file. Each users' alias must be in the following format: username: *; For more information on configuring mail aliases, see the Configuring Mail Aliases section.
You can configure MultiNet with gateways to particular hosts or domains to override the normal host lookup used by SMTP or to configure "virtual" domains not actually present on the network. To configure mail gateways with MAIL-CONFIG:
1. Start MAIL-CONFIG with the MULTINET CONFIGURE /MAIL command.
2. Use the ADD GATEWAY and DELETE GATEWAY commands (for descriptions of these commands, refer to MultiNet Administrator's Reference).
3. Save the configuration with the SAVE command.
4. Quit MAIL-CONFIG with the QUIT command.
The modified configuration takes effect the next time your system reboots.
For example, to make it easier for users to address mail to BITNET users, configure a gateway for the .BITNET "domain" to point to one of the Internet-BITNET gateway systems, such as CUNYVM.CUNY.EDU:
MAIL-CONFIG>ADD GATEWAY .BITNET CUNYVM.CUNY.EDU
Once defined, any mail bound for an address ending in .BITNET is sent to the gateway you specified (in this case, CUNYVM.CUNY.EDU).
If your system is a member of a VMScluster, you can define host aliases, which are host names interpreted by the mailer as aliases for the actual local host name. You can specify these aliases in return addresses for individual users.
MultiNet relies on two parameters to obtain its list of host aliases:
|
SMTP-HOST-NAMES |
Is a comma-separated list of up to 16 host aliases. If defined, the first alias in the list is the name used for outgoing mail. Any aliases are names for which your host accepts incoming mail. |
|
HOST-ALIAS-FILE |
Is the complete file specification of a file containing an unlimited list of host alias entries (one entry per line). The HOST-ALIAS-FILE value defaults to MULTINET:SMTP_HOST_ALIASES. |
To change your host aliases with MAIL-CONFIG, use the SET SMTP-HOST-NAMES command or the SET HOST-ALIAS-FILE command and save the modified configuration with the SAVE command. The new configuration takes effect the next time you reboot the system or the queues are restarted. Alternatively, specify the alias file name dynamically with the following command:
$ DEFINE/SYSTEM/EXEC MULTINET_SMTP_HOST_ALIASES_FILE file-spec
If this logical name is not defined, by default the SMTP software looks for the file MULTINET:SMTP_HOST_ALIASES. Names in the host aliases file should be listed one per line.
The logical name MULTINET_SMTP_FROM_HOST lets you change the host name that appears in your return address on outgoing mail.
Normally, the host name you choose must be a "local" host name; that is, it must be one of the registered SMTP host name aliases on the system (either from the SMTP-HOST-NAMES setting or the HOST-ALIAS-FILE). If it is not a known alias, the setting is ignored.
If you define the host name in executive mode, however, MULTINET_SMTP_FROM_HOST can be any arbitrary host name. The name is not checked against the SMTP host name.
When the logical MULTINET_SMTP_ENVELOPE_FROM_HOST is defined the value is used for the host name instead of the actual host name when sending the MAIL FROM: line to the remote server. This is useful if there are multiple independent systems that send mail that you would like to appear to be a single system.
This feature lets users from different administrative entities within an organization have return addresses that reflect the names of those entities. To enable this feature:
1. Set up MX records in DNS so mail is routed to the local host for each separate host name. For information about MX records, see the discussion of zone files in Chapter 10.
2. Set up SMTP-HOST-NAMES or the HOST-ALIAS-FILE with a list of host names.
3. Define the logical name MULTINET_SMTP_FROM_HOST for each user. Base the value for this logical name on some aspect of the department or organization to which the user belongs.
The MultiNet SMTP system supports system-wide mail aliases, system-wide mailing lists, and per-user mail aliases. The default system-wide alias file is MULTINET:SMTP_ALIASES. You can configure this name or specify a list of alias file names.
Per-user mail aliases are kept in the file SMTP_ALIASES in each user's login directory. The format for alias entries is: alias: real_address[,...];
· alias is an alphanumeric string.
· real_address is either a local or remote electronic mail address.
You can specify multiple addresses by separating them with commas; the alias definition may span multiple lines, if needed, and must always be terminated with a semicolon (;).
For example, a local user has the user name "JB134A", but wants to receive SMTP mail sent to the address "john". The system manager adds the following line to the alias file: john: jb134a;
You can both forward a mail message and deliver it to a local mailbox by adding the mailbox name, preceded by an underscore, to the MULTINET:SMTP_ALIASES file. The following example shows such an alias entry:
FNORD: FNORD@SOMEWHERE.PROCESS.COM, _FNORD;
The leading underscore on the second address (_FNORD), tells the SMTP symbiont to skip any further alias processing.
Mailing lists are a special form of mail alias and are supported only in the system-wide alias files. The format for specifying a mailing list is: list-name:: owner-address, file-spec;
· A double-colon (::) signifies that this alias is a mailing list.
· owner-address is the address of the mailing list owner. Messages sent to this mailing list go to each subscriber on the list with the return-path set to this address. The owner address can be an actual user's address or an alias, if desired.
· file-spec is the file specification for the file containing the subscribers to the mailing list. Specify a complete path name for this file, including the device and directory.
For example, you might want to set up a mailing list called OPERATIONS-STAFF for your operations staff, and have your operations manager, user OPER1, manage that list. You might set up the mailing list this way:
Operations-Staff:: Operations-Manager, USERS:[OPER1]STAFF.LIST;
Operations-Manager: OPER1;
Mail sent to OPERATIONS-STAFF is forwarded to the addresses listed in USERS:[OPER1]STAFF.LIST. Because this file is in OPER1's area, the operations manager has control over who is included in the list. The list is set up in this example so the return-path on list messages is set to "Operations-Manager" instead of user OPER1; setting up the list owner as an alias makes it easier to change list owners at a later date.
By default, the MultiNet SMTP system obtains system-wide mail aliases from the MULTINET:SMTP_ALIASES file. You can configure MultiNet to use any other file, or to use multiple files.
To change the SMTP aliases file with MAIL-CONFIG, use the SET ALIASES-FILE command, then save the modified configuration with the SAVE command. The new configuration takes effect the next time you reboot the system.
If you want aliases configured within the MultiNet SMTP alias file to be accessible to local VMS MAIL users (or those connected via DECnet), specify the address using the MultiNet SMTP VMS MAIL foreign mail protocol interface.
For example, a local user wanting to send mail to the "gcc-users" mailing list would specify the address SMTP%"gcc-users".
Note! You can, however, define a VMS MAIL alias containing the SMTP% specification. To define the VMS MAIL alias "Operations-Staff," use the VMS MAIL SET FORWARD command:
MAIL> SET FORWARD SMTP%"""Operations-Staff-USERS""" /USER=Operations-Staff
MultiNet SMTP uses the RFC-822 To: and CC: headers to provide the contents of the VMSmail To: and CC: fields. To enable this processing, define the logical name MULTINET_VMSMAIL_USE_RFC822_TO_HEADER.
Note! VMSmail limits the length of its To: and CC: fields to 255 characters.
The Internet Message Access Protocol (IMAP) server lets an IMAP-compliant client mail program access remote message storage as if the storage were local. MultiNet's implementation is based on IMAP Version 4, Revision 1.
IMAP and the Post Office Protocol (POP3), described in the next section, operate differently. IMAP retains the message on the server, whereas POP3 retrieves the message and stores it "off-line" on the client, thereby deleting it from the mail server. IMAP does not delete the mail message and lets you access your mail from more than one client workstation at a time.
IMAP was designed to:
· Be fully compatible with Internet messaging standards, such as MIME.
· Allow message access and management from more than one computer.
· Allow access without relying on less efficient file access protocols.
· Provide support for "online," "offline," and "disconnected" access modes
· Support concurrent access to shared mailboxes.
· Eliminate the need for the client software to know about the server's file storage format.
The IMAP protocol includes operations for:
· Creating, deleting, and renaming mailboxes
· Checking for new messages
· Permanently removing messages
· Setting and clearing flags
· Server-based RFC-822 and MIME parsing and searching
· Selective fetching of message attributes, texts, and portions thereof, for efficiency
For other IMAP features and how they contrast with those of POP3, see either of these web sites:
http://www.imap.org/imap.vs.pop.brief.html
http://www.imap.org/imap.vs.pop.html
Problems arise when remote users log into systems using a login command procedure (SYS$LOGIN:SYLOGIN.COM or SYS$MANAGER:SYLOGIN.COM) that requires screen output. To inhibit this behavior, make sure the following lines are included at the top of all login command procedures:
$ VERIFY = 'F$VERIFY(0) ! Turn off verify
without echoing
$ IF F$MODE() .EQS. "OTHER" THEN EXIT ! If a DETACHED process
(IMAP)...
$ IF VERIFY THEN SET VERIFY ! If a batch job, may want to turn
! verify back on.
In contrast to POP3, IMAP allows you to access server mail folders (message stores) other than INBOX. In MAIL, for example, if you create a NOTES folder, you can access mail in that folder. This NOTES folder can be in a mail file other than the default MAIL.MAI file. In fact, you can set a configuration parameter that determines the way mail folders are presented to the client so that you can use folders in these other mail files.
Your default mail directory includes a .IMAPRC file in which you can set certain configuration directives (described more fully in the IMAP Directives File section that follows). Among these directives is allow-subfolders. This directive specifies that folder names are comprised of a directory (optional), mail file, and folder. For example, the NOTES folder in MAIL.MAI is represented as mail/notes (as opposed to just notes if the directive were not set). This would distinguish it from another NOTES folder in the OLD.MAI mail file, for example, which would be named old/notes.
Each level beyond the second in this hierarchy represents a subdirectory of the default mail directory. For example, the NOTES folder in [.ARCHIVED]MAIL.MAI has the IMAP equivalent of archived/mail/notes.
Because of this folder syntax ambiguity, directory names, file names, and folders can overlap, such as the examples below.
|
This mail file... |
Containing this folder... |
Has this IMAP equivalent... |
|
MAIL.MAI |
NOTES |
mail/notes |
|
[.MAIL]NOTES.MAI |
STUFF |
mail/notes/stuff |
|
[.MAIL.NOTES]STUFF.MAI |
BOBS |
mail/notes/stuff/bobs |
Entries in the syntax can at different times be mail files, directories, subdirectories, or folders. Because of this overlap, the server must keep an internal representation of the hierarchy and mark what each level of the folder name means. This information is critical when renaming or deleting folders.
One restriction is that a first level folder (MAIL, for example) cannot be a message store, since it represents only a file and not a mail folder. INBOX, however, is a special case. INBOX is always INBOX, cannot be deleted or renamed (a rename moves messages to the renamed folder but does not delete INBOX), and never goes away. In IMAP, INBOX is mail/NEWMAIL by default, and is hidden to the user.
(Note that you can change the mail "in-box" from INBOX to another folder by defining the file-inbox-messages-to-folder directive in the .IMAPRC file. See the next section for details.)
You can also access mail files in your login directory (SYS$LOGIN) by prefixing the folder name with a tilde (~). The ~ folder is reserved and cannot be used by other folders.
Users can set certain preferences by creating a file in their default mail directory called .IMAPRC and including directives. The below table lists these directives along with their meanings. Each directive must be on its own line and in lowercase.
|
This directive... |
Does the following... |
|
set allow-child-folders |
Enables or disables the use of subfolders and the way that folders are presented to the client. By default, this value is false. If you want to set the value to be true, put this line in the .IMAPRC file: set allow-child-folders true. (See the previous section for details.) |
|
set autofile-messages-to-folder foldername |
Moves read messages from INBOX to the specified folder in the user's default mail file. By default, this option is disabled. |
|
set case-insensitive-folders |
Specifies that folder names are case-insensitive. Otherwise, two
folders with the same name but with different cases could become inaccessible
to the IMAP client. Newly created folders are created in uppercase on the
server. By default, this value is false. If you want to set the value to
be true, put this line in the .IMAPRC file: set case-insensitive-folders true |
|
set do-purge-reclaim |
Enables or disables purge-reclaim operations upon closing a folder. By default, this value is true. |
|
set folder-timer delta_time |
Specifies the frequency the IMAP server will check for externally created folders. By default, this value is 00:02:00 (2 minutes). |
|
set inbox-folder foldername |
Maps INBOX to the specified folder in the user's default mail file. By default, this value is NEWMAIL. |
|
set newmail-timer delta_time |
Specifies the frequency the IMAP server will check folders for new messages. (Note that checking for new mail is time consuming for large folders.) By default, this value is 00:00:30 (30 seconds). |
These options are valid in the global IMAPD.CONF file (MULTINET:IMAPD.CONF) as shown in the below table:
|
This directive... |
Does the following... |
|
set decnet-address nodename namespace domainname |
Maps the specified decnet nodename and/or namespace to a given domain name. Use " " to represent either a blank nodename or namespace. Multiple entries are allowed. By default, this option is disabled. Example:
set decnet-address knob " " door.com. |
|
set enable-full-cache |
Enables or disables full message caching. By default, this value is false. |
|
set max-ping-count integer |
Specifies, in number of messages, the threshold at which the server will no longer attempt to check for new messages. By default, this value is 20000. |
|
set smtp-transport-prefix string |
Specifies the SMTP transport prefix. By default, this value is SMTP. If you want to change it to MX, put this line in the IMAPD.CONF:
|
|
set trailing-header-marker string |
Specifies a text string used to indicate the start of RFC822 message headers if the system does not place them at the start of the message. By default, this option is disabled. |
The IMAP server includes files created in the user's mail directory where it maintains state information, as shown in the following table.
|
This file... |
Stores... |
|
.MAILBOXLIST |
Folders to which the user subscribes. |
|
.NEWMAILBOXES |
List of folders known to be empty. OpenVMS MAIL deletes folders once it deletes the last message, so that the server must "remember" these folders. |
|
mailfolder.foldernameuidvalidity |
For each folder, the UIDs for all the messages. The file name is composed of the folder name and its UIDVALIDITY code. For example: MAIL.NEWMAIL3B3200E6. In the example, the folder name is NEWMAIL and the UID validity code is 3B3200E6. |
The following IMAP logicals are supported:
By default, an informing message of This message cannot be retrieved is sent to the user when the processing message is too big. You can use this logical to define a different informing message. For example, if you define the logical like this:
$ define/sys/exe MULTINET_IMAPD_MESSAGE_ONE "Your mail is too big to be processed"
The message seen by the user is:
Your mail is too big to be processed.
If the defined logical string starts with @, the rest of the string defines a text file that holds the text. The maximum file size of the informing message is 255 bytes. For example, if you define the logical like this:
$ define/sys/exe MULTINET_IMAPD_MESSAGE_ONE "@MULTINET:IMAPD_MSG_ONE.TXT"
and edit the file MULTINET:IMAPD_MSG_ONE.TXT to be:
The size of this message is too big for the IMAP server to
process. Most likely it has a big attachment file. Contact the sender to
arrange re-transmission by other means such as FTP.
-System Manager.
The text message from the System Manager is seen by the user when the processing message cannot be retrieved.
There could be times when an oversized mail file prevents the mail system from working. This oversized mail file could also slow down other processes on the system. If such a case happens, use this logical to limit the size of the mail that IMAP processes.
When a mail file size reaches the limit defined by this logical, IMAP does not process it and sends a message to the user. Use the following metrics to define this logical: "S" (40K records), "M" (120K records), or "L" (240K records).
Note! Because VMS uses records to define the mail size and a record could have as few as 1 byte to as many as 255 bytes, the size limit defined by the logical does not reflect the actual mail size in bytes. For example:
$ define/sys/exe MULTINET_IMAPD_MESSAGE_SIZE_LIMIT "M"
A mail with a 5MB attachment file could reach the limit. But another mail with a 6MB attachment file could pass the limit.
Note! If the logical is not defined, the mail size limit is actually the current VMS Page file limit quota (PGFLQUO) of the IMAP process.
This logical enables additional logging for debugging purposes. Output is written to the file MULTINET:IMAP_SERVER.LOG. By default, this logical is unassigned. IMAP events normally are logged to SYSLOG.
This logical updates the last non-interactive login field in this SYSUAF for each IMAP login.
The MultiNet Post Office Protocol version 2 (POP2) and version 3 (POP3) servers allow a remote user to access mail stored in VMS MAIL files from POP2 and POP3 mail clients. The POP2 protocol is documented in RFC-937, "Post Office Protocol: Version 2," and POP3 is documented in RFC-1460, "Post Office Protocol: Version 3."
The remote user must have a valid account on the OpenVMS host and mail must be delivered into the VMS MAIL files associated with the account. A user specifies a user name and password when VMS MAIL is accessed from a POP2 or POP3 client.
The POP3 server accepts Kerberos V4 authentication in place of user name and password authentication. The current release of the Eudora mail client supports this method of authentication. The POP3 server allows cross-realm Kerberos V4 authentication when the logical name MULTINET_POP3_ENABLE_CROSS_REALM_AUTHENTICATION is defined.
The POP3 server waits indefinitely for input from POP3 clients. A logical is definable so you can specify the amount of time the POP3 server should wait for input before closing the connection. The logical is MULTINET_POP3_INPUT_WAIT x, where x is a normal VMS time string.
The POP3 server supports Unique Identifier Lists (via the UIDL command) for improved operation of Eudora clients.
The current release of the MultiNet POP3 server does not support the APOP authentication mechanism. The user name and password are validated by LOGINOUT, and a server process is created on the OpenVMS host. The server process invokes both the system-wide login command procedure (SYS$MANAGER:SYLOGIN.COM) and the user's LOGIN.COM before the POP server image is run. A log file is created in the user's login directory detailing the transactions between the client and the OpenVMS system; with POP2 this log file is called POP2_SERVER.LOG with POP3, it is called POP3_SERVER.LOG.
You can define the logical names described in this section to provide additional functionality to POP2 and POP3. These logicals, which affect several aspects of mail operation, can be defined either system-wide or for individual users.
Note! The default value for all of these logicals is 0 (all bits disabled).
You can use these logicals for either POP2 or POP3. In using the logicals, substitute either 2 (for POP2) or 3 (for POP3) for the x in the logical name.
MULTINET_POP3_UPDATE_LOGIN_TIME
When defined /SYSTEM, this causes the LAST NONINTERACTIVE DATE/TIME field in SYSAUF to be updated with the time the POP3 session was started. Note that this logical applies to POP3 sessions only.
This logical specifies functions as decimal values that are interpreted as described in the following table. To define more than one function, add the decimal values together; for an example, see the Defining the Logicals System-Wide section.
|
Value |
Effect |
|
1 |
Read only messages marked as new from the NEWMAIL folder. The default is to read all messages in this folder. If MULTINET_POPx_SOURCE_FOLDER is defined, this flag is ignored. |
|
2 |
Move messages from the NEWMAIL folder to the MAIL folder after they are read. If MULTINET_POPx_DEST_FOLDER is defined, this flag is ignored. |
|
4 |
Release the POP client before the VMS mailbox is actually closed; that is, cause a quick close. VMS MAIL can take several minutes to reclaim large amounts of deleted message space. The server replies to the client with a success, closes the connection, releases the client, and closes the mailbox. Any errors that result from closing the mailbox when this flag is enabled are lost. |
|
16 |
Remove the "NODE::" portion of the "From:" address. The MultiNet POP server creates RFC-822 headers from VMS headers before sending the message to the POP client. If the mail message was received via SMTP, SMTP headers are used.
When NODE is the same as the OpenVMS logical name SYS$NODE, the "NODE::" portion of the address is removed; otherwise, this portion of the address is retained.
For example: · For a local node WHITEFANG in which a message originates via DECnet from a remote OpenVMS host, the "From:" line is WHARFIN::HOLMES. · After conversion to RFC-822 conventions, the line is "WHARFIN::HOLMES"@WHITEFANG.EXAMPLE.COM. · Because some POP clients cannot reply to this address, the bit value represented by 16 should be enabled. When enabled, the "From:" line becomes HOLMES@EXAMPLE.COM.
Note: If a message is routed via DECnet before being received by SMTP, enabling this bit invalidates the return path to the remote DECnet node. |
|
32 |
Deleted messages are saved into the folder specified by MULTINET_POPX_DEST_FOLDER. Otherwise, when a message is deleted, it is removed completely. |
|
64 |
POP builds headers from the OpenVMS Mail "From" statement. Specify this flag when your mailer has been configured to not insert the SMTP headers as the first lines of text in the message.
The only time you should use this value in the MULTINET_POP3_FLAGS logical name is when you want to construct ad hoc SMTP headers (that is, when your SMTP agent is configured to place the real headers at the bottom of the message). |
|
128 |
The mail box is compressed, but all versions of MAIL.OLD in the MAIL directory are deleted. |
The MULTINET_POPx_DEST_FOLDER logical specifies the folder containing messages that have been read.
The MULTINET_POPx_SOURCE_FOLDER logical specifies the folder from which to read messages. The default folder name is NEWMAIL.
By default, the POP2 and POP3 servers look for mail in the NEWMAIL folder of the user's OpenVMS MAIL files. This default may be overridden by defining the logical names MULTINET_POPx_SOURCE_FOLDER and MULTINET_POPx_DEST_FOLDER in the file SYS$LOGIN:LOGIN.COM. For example, if a POP3 user wants to access mail stored in the MAIL folder by default, place the following command in LOGIN.COM:
$ DEFINE MULTINET_POP3_SOURCE_FOLDER "MAIL"
Note! OpenVMS MAIL folder names are case-insensitive.
When a mail message is accessed by POP2 or POP3, it remains in its original folder until the POP client deletes it. This happens even if the mail is being accessed from the user's NEWMAIL folder. Users may, however, define the logical name MULTINET_POPx_FLAGS, using the value 2, in their LOGIN.COM files to alter this behavior. If MULTINET_POPx_FLAGS is set to 2, mail messages are placed in a user's MAIL folder. This occurs after they are read via POP from the NEWMAIL folder, if the POP client does not delete the messages after it reads them.
This behavior is the same as with OpenVMS MAIL. For example, if a POP2 user wants mail read from the NEWMAIL folder placed in the MAIL folder after being read, add this command to LOGIN.COM:
$ DEFINE MULTINET_POP2_FLAGS "2"
Again, the user must also configure the POP2 client so messages are not deleted after they are read. If the client deletes a message, it is not saved in either the MAIL or NEWMAIL folder on the OpenVMS server.
All POP logical names can be defined system-wide for all users, as shown in the following example:
$ DEFINE /SYSTEM /EXECUTIVE MULTINET_POP3_FLAGS "7"
This example sets the flags parameter so that:
· All users only read messages from the NEWMAIL folder that are marked as new.
· Messages are moved from the NEWMAIL folder to the MAIL folder after they are read.
· The POP client is released quickly at the end of the mail session.
The MultiNet mailer supports users of HP's ALL-IN-1 office automation environment (often referred to as ALL-IN-1 IOS or ALL-IN-1 Classic) and ALL-IN-1 MAIL via an interface to Message Router, the backbone of HP's MAILbus product line. This interface allows both ALL-IN-1 IOS and ALL-IN-1 MAIL users to send and receive SMTP mail. Message Router V3.1 or later is required for this feature to function properly. For information on sending and receiving SMTP mail from within ALL-IN-1 IOS and ALL-IN-1 MAIL, see the electronic mail chapter in the MultiNet User's Guide.
You must have Message Router V3.1 or later installed on your system before configuring the MultiNet SMTP to Message Router (SMTP/MR) interface. If you want to support automated conversion of WPS and DX documents in ALL-IN-1 messages to ASCII, you must also have the Message Router VMS MAIL Gateway (MRGATE) installation kit.
You do not need to install MRGATE on your system; however, certain object libraries in the MRGATE kit are needed to provide the necessary document conversion functions. The SMTP/MR gateway software functions even if the document conversion is not built. It does, however, cause all WPS and DX message bodyparts to be discarded as the ALL-IN-1 message passes through SMTP/MR.
The MR_CONFIGURE.COM command procedure in the MULTINET: directory is used to configure the SMTP/MR gateway software. Execute this procedure with the DCL command:
$ @MULTINET:MR_CONFIGURE
The command procedure presents a series of prompts. Enter a question mark (?) at any time to display more information about that prompt. The configuration command procedure prompts you for the following information:
1. Whether to display a detailed explanation before each question. It is recommended that you answer YES to this question the first time you run the configuration procedure.
2. The domain name of the gateway system. This is a domain-style host name used to refer to the gateway from the Internet. Be sure the name you choose is within a domain or subdomain over which you have administrative authority, and is not currently being used for another host. If your local domain is EXAMPLE.COM, a reasonable choice for this domain name would be MR.EXAMPLE.COM. This name is largely for internal use, and should not be needed to address mail to ALL-IN-1 users.
3. The domain name to be used for local ALL-IN-1 IOS users. This is a domain-style host name used to indicate to the MultiNet mailer that it should pass the message to the Message Router for delivery to an ALL-IN-1 user. Be sure the name you choose is within a domain or subdomain over which you have administrative authority, and is not currently being used for another host. If your local domain is EXAMPLE.COM, a reasonable choice for this domain name would be A1.EXAMPLE.COM.
Note! If you are not running ALL-IN-1 IOS, you should specify NONE.
4. The domain name to use for local ALL-IN-1 MAIL users. This is a domain-style host name used to indicate to the MultiNet mailer that it should pass the message to Message Router for delivery to an ALL-IN-1 user. Be sure the name you choose is within a domain or subdomain over which you have administrative authority, and is not currently being used for another host. If your local domain is EXAMPLE.COM, a reasonable choice for this domain name would be AM.EXAMPLE.COM.
Note! If you are not running ALL-IN-1 MAIL, you should specify NONE.
5. The Message Router mailbox name used for the gateway. This Message Router mailbox name is used by ALL-IN-1 users to send outbound SMTP mail. You are directed later to create this mailbox with the Message Router MRMAN utility. The default value of "SMTP" should be used.
Both ALL-IN-1 IOS and ALL-IN-1 MAIL users use the address form user@host@SMTP to specify remote SMTP recipients. Each ALL-IN-1 mail utility places this outbound mail in the Message Router mailbox named SMTP. The MultiNet mailer "picks up" mail from this mailbox and sends it via the normal SMTP delivery mechanism.
The current version of MultiNet allows both ALL-IN-1 IOS and ALL-IN-1 MAIL users to reply to messages imported with the V command or forwarded into ALL-IN-1 using an address of the form MRGATE:"A1::user" or MRGATE::"AM::user". Return addresses are translated from Message Router format to a more standard RFC-822 format in a fashion analogous to the DECnet to SMTP gateway conversion. The following logical names can be used to customize the translation:
|
MULTINET_SMTP_MRGATE_NAME |
Change the name of the Message Router gateway mailbox. The default value is MRGATE. |
|
MULTINET_SMTP_A1_NAME |
Change the name of the ALL-IN-1 IOS gateway mailbox. The default value is A1. |
|
MULTINET_SMTP_AM_NAME |
Change the name of the ALL-IN-1 MAIL gateway mailbox. The default value is AM. |
|
MULTINET_SMTP_A1_DOMAIN |
Specify the RFC-822 domain associated with the ALL-IN-1 IOS gateway. Use the domain you specified when configuring your SMTP/MR gateway. |
|
MULTINET_SMTP_AM_DOMAIN |
Specify the RFC-822 domain associated with the ALL-IN-1 MAIL gateway. Use the domain you specified when configuring your SMTP/MR gateway. |
6. The Message Router mailbox name used for delivery to ALL-IN-1 MAIL users. This Message Router mailbox is used to deliver inbound SMTP mail to ALL-IN-1 MAIL users. Normally this mailbox is named "AM", but the name is configurable. If your site uses a name other than AM, enter that name.
7. The Message Router mailbox name used by default when mail is sent to the domain name of the gateway system (for example, MR.EXAMPLE.COM). Specify the default value, "MRGATE," to indicate the Message Router VMS MAIL Gateway mailbox.
8. The Message Router mailbox name for the local system. Specify the DECnet node name of the local system. SMTP/MR uses this name to generate addresses that are valid on remote systems.
9. The names of any null routes. Specify the name of the local DECnet node and any other nodes in a homogeneous VMScluster (including the cluster alias). Message Router routing information often includes local DECnet node names or a cluster alias which is superfluous in outbound SMTP mail. To determine the names of any null routes, use the MRMAN utility SHOW * command. Null routes have the general form:
nullname, Replace=
The names you specify at this point are automatically stripped from addresses passing through SMTP/MR, greatly simplifying them when they pass into the SMTP world. Use a blank entry to terminate the list.
10. The SMTP address of the local postmaster, which should be the full domain-style e-mail address of the user who should receive error messages generated by SMTP/MR.
11. The password associated with this gateway's Message Router mailbox (SMTP by default). Message Router protects each mailbox with a password to ensure privacy of mail messages.
12. Whether you want to have messages with WPS and DX bodyparts automatically converted to ASCII. SMTP/MR can perform these conversions if it is linked against libraries provided as part of various Message Router products, notably MRGATE. If you intend to have messages in these special formats converted to ASCII, answer YES. If you answer NO, these bodyparts are not converted, and may be discarded.
13. You are then prompted for the names of several SMTP/MR configuration files. Accept the defaults for each of these file names.
14. You are then asked if you want to generate the configuration files. If you are satisfied with all of your responses, type YES.
In the following example, which shows an MR_CONFIGURE.COM session, the local host's DECnet node name is MIGUEL, while its TCP/IP host name is MIGUEL.EXAMPLE.COM. The DECnet cluster alias is IRISDN; and other hosts in the homogeneous VAXcluster are named WHARFIN, BIGBTE, and YAYA. The e-mail address of the local postmaster is POSTMASTER@EXAMPLE.COM.
$ @MULTINET:MR_CONFIGURE
SMTP-MR Configuration Utility, Version V3.1
This utility creates an initial pair of databases for mapping SMTP RFC 822-style addresses to Message Router X.400-style addresses and back again. Only minimal mappings are created to support ALL-IN-1 users sending and receiving SMTP mail. If you need full MAILbus to SMTP gatewaying capabilities, contact Process Software at (508) 879-6994 about their PMDF and PMDF-MR e-mail gateway products.
Important note: No changes are made to existing SMTP-MR database information until all questions have been answered. This utility can be aborted at any prompt by entering a CTRL/Z. The files output by this utility may optionally be redirected to a different location so they will have no impact on the existing SMTP-MR databases.
Do you wish to continue [Y]? RETURN
Do you wish to have a detailed explanation printed before each question
[N]? RETURN
Domain name of the gateway: MR.EXAMPLE.COM
Domain name for local ALL-IN-1 IOS users [A1.FLOWERS.COM]: RETURN
Domain name for local ALL-IN-1 MAIL users [AM.FLOWERS.COM]: RETURN
Message Router mailbox name for the gateway [SMTP]: RETURN
ALL-IN-1 IOS mailbox known to Message Router [A1]: RETURN
ALL-IN-1 MAIL mailbox known to Message Router [AM]: RETURN
Message Router mailbox used by default [MRGATE]: RETURN
Local system's Message Router mailbox [MIGUEL]: RETURN
Local node name or other null routes [RETURN if no more]: MIGUEL
Local node name or other null routes [RETURN if no more]: WHRFIN
Local node name or other null routes [RETURN if no more]: BIGBTE
Local node name or other null routes [RETURN if no more]: YAYA
Local node name or other null routes [RETURN if no more]: IRISDN
Local node name or other null routes [RETURN if no more]:
RFC822 address of local PostMaster: postmaster@example.com
Password for the Message Router mailbox: secret
Convert WPS-PLUS and DX messages to ASCII automatically [Y]? RETURN
SMTP to MR mapping text file [MULTINET:TO_MR.]: RETURN
MR to SMTP mapping text file [MULTINET:FROM_MR.]: RETURN
Gateway options file [MULTINET:MR_OPTIONS.]: RETURN
SMTP-MR checklist file name [MULTINET:SMTP-MR.CHECKLIST]: RETURN
All configuration questions have been answered.
Do you wish to generate the configuration files [Y]? RETURN
Generating SMTP to MR mapping text file...
SMTP to MR mapping text file is complete.
Generating MR to SMTP mapping text file...
MR to SMTP mapping text file is complete.
Generating the setup checklist...
Checklist file is complete.
Generating options file...
Options file is complete
***********************************************************************
* To complete your SMTP-MR configuration, carry out the steps
* detailed in the setup checklist MULTINET:SMTP-MR.CHECKLIST.
***********************************************************************
$
The DCF document conversion utility is used by SMTP/MR to convert WPS and DX message bodyparts to ASCII text. This utility is built from document conversion library routines supplied as part of the Message Router VMS MAIL Gateway (MRGATE) distribution kit. SMTP/MR can function without this utility, but cannot convert WPS and DX bodyparts to ASCII without it. Bodyparts in outbound SMTP mail that cannot be converted to ASCII are discarded.
The DCF utility is not supplied in executable form with SMTP/MR; it must be built after SMTP/MR is configured. The command procedure MULTINET:DCF_BUILD.COM is provided to accomplish this. This procedure prompts for two items:
· The location of the save set from which to extract the necessary conversion libraries
· The name of a directory into which the libraries should temporarily be placed while the utility is being linked. Under MRGATE V3.1, the name of the save set containing the conversion libraries is MRGATE031.A.
You need not copy the saveset from the distribution media for DCF_BUILD.COM to work. For example, if you want to access the libraries on a TK50 containing MRGATE while on a VAXstation 3100, you would specify the saveset name as MKA500:MRGATE031.A. The following example shows how to build the DCF utility from a saveset located in the SYS$MANAGER directory:
$ @MULTINET:DCF_BUILD
Directory to put libraries in [SYS$SCRATCH:]: RETURN
File specification of save set from which to extract libraries:
SYS$MANAGER:MRGATE031.A
Extracting libraries...
%BACKUP-S-CREATED, created SYS$SYSROOT:[SYSMGR]KOALA.OLB;1
%BACKUP-S-CREATED, created SYS$SYSROOT:[SYSMGR]DCF_BASE.OLB;1
%BACKUP-S-CREATED, created SYS$SYSROOT:[SYSMGR]DCF_TRANSLATE.OLB;1
%BACKUP-S-CREATED, created SYS$SYSROOT:[SYSMGR]DCF_MAIL_CONVERSIONS.OLB;1
%BACKUP-S-CREATED, created SYS$SYSROOT:[SYSMGR]DCF_DSAF.OLB;1
%BACKUP-S-CREATED, created SYS$SYSROOT:[SYSMGR]WPADOC.OLB;1
%BACKUP-S-CREATED, created SYS$SYSROOT:[SYSMGR]WPABASE.OLB;1
%BACKUP-S-CREATED, created SYS$SYSROOT:[SYSMGR]XPORT.OLB;1
Linking DCF utility...
Cleaning up...
Done
$
The DCF utility is never invoked interactively. It is always invoked automatically by the SMTP/MR gateway whenever it has mail containing WPS or DX bodyparts it needs to send via SMTP.
Note! You must use the A save set from MRGATE V3.1 or V3.2 to build DCF. Versions V3.3 and later do not contain the object files needed to link to DCF. If you upgrade to MRGATE V3.3, save your V3.1 or V3.2 distribution media.
In addition to the SMTP/MR configuration data files, the file MULTINET:SMTP-MR.CHECKLIST is created by the MR_CONFIGURE.COM command procedure. This file contains the steps needed to complete the SMTP/MR configuration, which include:
1. Adding the SMTP/MR gateway mailbox to your Message Router configuration. Run the MRMAN utility exactly as documented in the checklist file. The Message Router mailbox name and password must be exactly the same as you specified to MR_CONFIGURE.COM.
2. Building the WPS and DX document conversion utility. See the previous section for details on building this utility.
3. Configuring your Domain Name System (DNS) name server for SMTP/MR operation. You must add a Mail eXchanger (MX) record to your name server configuration for the following:
· The domain name of the gateway itself (MR.EXAMPLE.COM in the example in the Configuring S section)
· The domain name used to direct mail to your ALL-IN-1 IOS users (A1.EXAMPLE.COM in the example in the Configuring SMTP/MR section)
· The domain name used to direct mail to your ALL-IN-1 MAIL users (AM.EXAMPLE.COM in the example in the Configuring SMTP/MR section).
If the host running SMTP/MR is named MIGUEL.EXAMPLE.COM, the DNS Resource Records (RRs) you would use in the DNS configuration file for the domain EXAMPLE.COM are:
MR.EXAMPLE.COM. IN MX 0 MIGUEL.EXAMPLE.COM.
A1.EXAMPLE.COM. IN MX 0 MIGUEL.EXAMPLE.COM.
AM.EXAMPLE.COM. IN MX 0 MIGUEL.EXAMPLE.COM.
For more detailed information on configuring a DNS name server, see the Host Tables and DNS chapter.
4. If you are not running a DNS name server locally, you must add additional host records to the MULTINET:HOSTS.LOCAL file for the host names of the gateway and your ALL-IN-1 users. Using the names from the above example, and assuming that the IP address for MIGUEL.EXAMPLE.COM is 128.0.0.1, you would add the following lines to MULTINET:HOSTS.LOCAL:
HOST : 128.0.0.1 : MR.FLOWERS.COM : :
: :
HOST : 128.0.0.1 : A1.FLOWERS.COM : : : :
HOST : 128.0.0.1 : AM.FLOWERS.COM : : : :
You should:
· Place these lines after the entry for MIGUEL.EXAMPLE.COM.
· Specify each name on a line by itself. Merging entries in the hosts file prevents the gateway from functioning properly.
· Recompile and re-install the host tables after adding the new entries.
For detailed information on adding entries to your host tables, see Chapter 10.
5. Submitting the command procedure MULTINET:MR_TO_MULTINET.COM to the appropriate batch queue on your system. This command procedure runs periodically to transfer mail from the SMTP/MR Message Router mailbox (normally SMTP) to the MultiNet mailer. Examine this command procedure before submitting it to ensure it runs in the batch queue and under the desired user name.
MultiNet can be set up as a gateway to route mail between SMTP and DECnet-only hosts, with appropriate address translations to make the DECnet-style addresses easier for Internet hosts to interpret. To do this, you set the DECNET-DOMAIN mail parameter and add an appropriate MX record to the Domain Name Service. The addresses of DECnet mail sent out via SMTP will be rewritten such that the DECnet node name(s) appear under the DECNET-DOMAIN name in the host-part of the address. The addresses of incoming SMTP mail for hosts under the DECNET-DOMAIN are automatically converted into DECnet addresses and delivered to the DECnet-only hosts.
In the DECnet-to-SMTP direction, a VMS MAIL user on a DECnet-only host sends SMTP mail by specifying an address of the form:
node::SMTP%"user@host"
node is the DECnet node name of the system running MultiNet.
MultiNet recognizes that the mail originated in DECnet and, if the DECNET-DOMAIN parameter is set, rewrites the originating address in the form
user@node.decnet-domain.
For example, EXAMPLE.COM has set up node HQ as a DECnet-SMTP gateway. A user named JOHN on DECnet-only node WHARFIN at EXAMPLE.COM addresses mail to the Info-MultiNet mailing list as: HQ::SMTP%"Info-MultiNet@PROCESS.COM"
JOHN's DECnet return address, WHARFIN::JOHN, is rewritten by the gateway as:
JOHN@WHARFIN.DNET.EXAMPLE.COM
instead of:
"WHARFIN::JOHN"@HQ.EXAMPLE.COM
which some Internet mailers would have trouble parsing.
For the SMTP-DECnet gateway to work in the SMTP-to-DECnet direction, other hosts on your network must be told that mail for host names under the DECNET-DOMAIN should be sent to the gateway host. If you use Domain Name Service, the easiest way to do this is to set up a wildcard MX record for the DECNET-DOMAIN. In our example, the MX record looks like this:
*.DNET.EXAMPLE.COM. IN MX 0 HQ.EXAMPLE.COM.
This MX record causes other hosts on the Internet to send mail destined for any host under DNET.EXAMPLE.COM to node HQ. The gateway automatically recognizes the DECNET-DOMAIN in the host-name part of the address, rewrites the address to its DECnet form, and sends it through VMS MAIL.
If you do not use DNS, you must add a fully qualified host name for each DECnet node to your host tables. In our example, a return message to user JOHN on node WHARFIN would be addressed to:
JOHN@WHARFIN.DNET.EXAMPLE.COM.
When HQ receives that message, it translates the address to its DECnet form:
WHARFIN::JOHN
and sends the message to that address using VMS MAIL.