The Simple Mail Transfer Protocol (SMTP) is a standardized text-based protocol for transferring electronic mail messages across diverse network environments. Defined by RFC 821 and extended by RFC 2821, SMTP provides a reliable and efficient mechanism for email communication in a client-server architecture.
This chapter describes how to configure MultiNet to send and receive email with SMTP. Incoming messages are handled by the MultiNet SMTP server, while outgoing messages are processed by an OpenVMS symbiont.
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. You can enable the SMTP service with these commands:
$ MULTINET
CONFIGURE /SERVER
MultiNet
Server Configuration Utility 5.6
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>ENABLE SMTP
SERVER-CONFIG>RESTART
Configuration
modified, do you want to save it first ? [YES] RETURN
[Writing
configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600046
SERVER-CONFIG>EXIT
$
The following example shows how to disable the SMTP service:
$ MULTINET CONFIGURE/SERVER
MultiNet
Server Configuration Utility 5.6
[Reading in configuration from MULTINET:SERVICES.MASTER_SERVER]
SERVER-CONFIG>DISABLE SMTP
SERVER-CONFIG>RESTART
Configuration modified, do you want to save it first ? [YES] RETURN
[Writing configuration to MULTINET_COMMON_ROOT:[MULTINET]
SERVICES.MASTER_SERVER]
%RUN-S-PROC_ID, identification of created process is 20600046
SERVER-CONFIG>EXIT
$
For more details on configuring and controlling MultiNet servers, see Chapter 9, Configuring MultiNet Services.
The MultiNet SMTP server is restarted with this command:
$ @MULTINET:START_SMTP.COM
The above command will restart the service across every node of a VMScluster. If you would like to restart the SMTP server on only the local host, run this command:
$ @MULTINET:START_SMTP_LOCAL.COM
The MultiNet SMTP configuration is stored in the START_SMTP.COM and START_SMTP_LOCAL.COM startup command procedures. Use the MULTINET CONFIGURE /MAIL command to edit these files. Changes won’t take effect until you restart the MultiNet SMTP service or reboot the system.
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.
5. Restart the SMTP services or reboot your system for the modified configuration to take effect.
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. |
|
FORWARD-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. |
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:
message 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.
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_file] -
_$ [/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_file 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. 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.
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.
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
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@EXAMPLE.COM, use the command:
$ DEFINE MULTINET_SMTP_REPLY_TO "FNORD@EXAMPLE.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.EXAMPLE.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.
|
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.