This chapter provides administrators with instructions for addressing mail and for address resolution. Intelligent Messaging allows for simple addresses and for REMA style addresses. This chapter also includes instructions for routing mail to remote Intelligent Messaging servers; an explanation of forced-message routing and instructions for how and when to use it; and examples of message routing.
When composing a message, the user specifies the names of recipients who are to receive the message. Once the message is sent, Intelligent Messaging uses the names entered in the address fields to determine where to deliver the message. This process is known as address resolution. The mail service transfer agent is responsible for resolving all the addresses associated with the message.
Note Intelligent Messaging 4.0 supports an unlimited number of recipients. Other versions of Intelligent Messaging have a 1000-character recipient limit.
Intelligent Messaging allows users to specify addresses in two formats:
This chapter describes how Intelligent Messaging handles these address formats.
The majority of mailing addresses used in mail messages are the StreetTalk names of the recipients. A StreetTalk name is an individual username, nickname, list name, or pattern in this format:
item@group@organization
Example of StreetTalk Names Used as Message Recipients
The following StreetTalk names can be used as message recipients in the address fields of a message:
Theodore M. Daley@Finance@WCTUS TedD@Finance@WCTUS AdminList@Research@WCTUS *@Sales@WCTUS *@*@WCTUS
StreetTalk names are simple because they require no knowledge of destination mail services or gateways by the user. Usually StreetTalk names refer directly to actual users.
How the Transfer Agent Resolves an Address
When an Intelligent Messaging mail service encounters a StreetTalk name in the message address field, the transfer agent resolves the address to one or more StreetTalk usernames, as follows:
Each nickname is converted to the corresponding formal StreetTalk name. Each list is enumerated into individual StreetTalk names. Each pattern is resolved into a list of individual StreetTalk names.
For each StreetTalk username, the transfer agent does the following:
1. Obtains the name of a mail service from the user profile.
2. Transports the message to the appropriate destination mail service.
Intelligent Messaging accepts REMA (Remote Electronic Mail Address) addresses, also known as mail gateway addresses, as message recipients.
Mail gateways enable different mail systems to exchange messages. Gateways generally consist of a computer and associated software that interconnect two mail systems. A mail gateway performs the necessary protocol conversion to pass messages from one mail system to another.
For example, a mail gateway could connect an Intelligent Messaging mail system to an Internet mail system.
To exchange mail through the gateway, users need to know the mailing addresses of the users on the destination mail system.
Note If your Intelligent Messaging mail service is running on a StreetTalk for Windows NT server, you need to be aware that your StreetTalk for Windows NT server does not act as a mail gateway. For example, you cannot use an Intelligent Messaging mail service on a Windows NT Server to send and receive SMTP mail. If your network requires a mail gateway, you must install and configure an Intelligent Messaging mail service and the gateway software on a native VINES Server.
REMA addresses use the following format:
transfer-service-name [local-name]
When an Intelligent Messaging mail service encounters a REMA address in the message address field, the mail service transfers the message to the service named by the first transfer-service-name in the address.
transfer-service-name is the StreetTalk name of another Intelligent Messaging mail service or a mail gateway service that transfers mail between Intelligent Messaging mail and the target mail system. If the destination is an Intelligent Messaging mail service, you can use the server name where the service resides in place of the service's StreetTalk name. local-name is either an address in a format recognized by the transfer-service-name or another REMA address to be processed by the transfer-service-name. It is the address of the user to whom you are sending the mail message. It must be enclosed in brackets. This address can be a StreetTalk name as described in "Simple Addresses" earlier in this chapter. Or, the address can have a format that is determined by the target mail system. In this case, the transfer-service-name must be a mail gateway service.
REMA addresses can be nested. Each nested address must use the REMA syntax, and the local-name must be a StreetTalk name. A REMA address can contain a maximum of 512 characters.
Make sure that gateway addresses are valid and that the correct number of opening and closing brackets are included. If a problem arises, you may have to verify addresses with an administrator of the target mail system.
Examples of REMA Addresses
Example 1
MS@Server8@Servers [Ed Hirsch@Faculty@Univ]
MS@Server8@Servers is the StreetTalk name of the Intelligent Messaging mail service. Ed Hirsch@Faculty@Univ is the StreetTalk name of the recipient on the target mail system.
Example 2
StarGate@Support@Star [Gary Tyson]
StarGate@Support@Star is the StreetTalk name of the gateway service. Gary Tyson is recognized by this service as the recipient address on the target mail system.
Example 3
TelexGate@Sales@XYCorp [361283]
TelexGate@Sales@XYCorp is the StreetTalk name of the gateway service that supports a connection to a telex-style mail system. 361283 is recognized by this service as the recipient address on the target mail system.
Example 4
SMTPGate@Mktg@WCTUS [Jan Rath@Univ.edu]
SMTPGate@Mktg@WCTUS is the StreetTalk name of the gateway service that supports a connection to an Internet (or SMTP) mail system. Jan Rath@Univ.edu is recognized by this service as the recipient address on the target mail system.
Simplifying the Use of REMA Addresses
Users can enter REMA addresses directly into the address fields of messages. However, REMA addresses can be lengthy. To make REMA addresses easier to use, you can include them in users' address books. Refer to the user documentation for the mail application for instructions on using the address book.
You can also create an alias user to make REMA addresses easier to use. Do this in either of two ways:
Map a StreetTalk username to a REMA address through the user profile. Create an STDA inclusion parameter.
The next sections explain these two methods.
Mapping a StreetTalk Username to a REMA Address
To create an alias REMA address using a StreetTalk username:
1. Create a StreetTalk group in your organization. For information on adding groups, refer to Managing Users and StreetTalk.
2. Within the group, create an alias user for each REMA address you want to use.
3. Access the user profile of each alias user you create, and specify a SETMAIL profile command that uses the user's REMA address in place of the mail service name.
Instruct users that instead of the lengthy REMA addresses, they can enter these alias usernames in the address fields when addressing messages through a gateway or to a remote mail service. Mail sent to the StreetTalk names goes to the appropriate gateway or remote address.
Example-Using a StreetTalk Username
Jennifer O' Brien is an architect at Lehman Associates, where an Intelligent Messaging mail service is used. Using the SMTPgate gateway, Jennifer and several co-workers frequently send mail to Tina Powers, an engineer at Palmer Systems.
They perform the following steps:
1. Jennifer creates a group called Eng@Palmer.
2. Within that group, she creates a user named Tina@Eng@Palmer.
3. She includes the following SETMAIL command in the user profile:
setmail SMTPgate@Eng@Lehman[Tina Powers@Palmer.com]
where SMTPgate@Eng@Lehman[Tina Powers] is Tina's gateway address.
4. To address mail to Tina, she either types the following address, or selects it from the names listed in STDA:
Tina@Eng@Palmer
Note Alternatively, Jennifer could create an entry in her address book for this mail gateway and type the label in the address field.
Using an STDA Inclusion Parameter
STDA inclusion parameters let you include non-StreetTalk names, such as REMA addresses, in the STDA database. To create an alias REMA address using an STDA inclusion parameter:
1. Create an STDA inclusion parameter.
2. Within the inclusion, include the REMA address you want to alias.
Note For information on preparing an inclusion parameter, refer to Managing Users and StreetTalk.
Instruct users that instead of entering the lengthy REMA addresses, they can select the inclusion parameter label from the names listed in STDA when addressing messages through a gateway or to a remote mail service. Mail sent to the STDA inclusion parameter goes to the gateway or remote address.
Example-Using an STDA Inclusion Parameter
Jennifer O' Brien frequently sends mail to several architects at another company. To create and use an inclusion parameter, she performs the following steps:
1. She creates an STDA inclusion parameter called Elise@Acme and adds it to the database of an STDA service. The inclusion parameter is shown below:
Label: Elise@Acme
Desc: Architects at Acme
Addr: SMTPgate@Eng@Lehman[Elise Megan@Acme.com]- SMTPgate@Eng@Lehman[Elise Megan@Acme.com]
is a gateway address.2. When Jennifer sends mail to Elise, she selects Elise@Acme from the names listed in STDA.
Alternatively, Jennifer could create an entry in her address book for this mail gateway and type the label in the address field.
Note Users may get unexpected results from addressing a mail message if they have a personal address book entry label that matches an STDA inclusion parameter label retrieved from the STDA database. For more information, refer to the section on verifying mail addresses in Managing Users and StreetTalk.
Routing Mail to Remote Intelligent Messaging Servers
Network mail automatically chooses the best route for exchanging messages, based on the way the servers in the network are connected. Servers that communicate through serial links can have permanent, temporary, or restricted connections. Each type of connection is described in Table 4-2.
You can exchange mail with users on remote servers through all three types of serial links. However, mail delivery may be interrupted if one link in a series of temporary or restricted links is temporarily inactive. To guarantee delivery of mail through serial links with temporary or restricted connections, use the mail feature, forced message routing.
The following sections explain routing of mail over the different types of links and provide instructions for formatting and using forced routing addresses.
When to Use Forced Message Routing
Forced message routing lets you store a mail message in the mail services of intermediate servers. The mail services of the intermediate servers forward the message until it reaches its target server.
Use forced mail routing to:
Guarantee delivery across restricted access links Force mail messages to route to their destination following a specific path Reduce the cost of transferring messages
You can exchange mail between two servers that are connected by a temporary link, because mail is automatically transferred when the link is active. You can also exchange mail between two servers that have no direct link if both servers are linked to an intermediate server that has, at minimum, a temporary link to both servers.
To guarantee delivery, you can use the forced message routing feature. Forced message routing delivers the message, even if the temporary links are not active at the same time.
For example, if servers A, B, and C have temporary connections to one another, and you want to send a message from A to C, you can force route the message to server B. The message is stored in the mail service on server B until it can be forwarded to server C.
The forced message routing feature also guarantees delivery across restricted access links. Restricted access means that the two servers exchange only mail messages. StreetTalk names and resources on the two servers remain separate. Forced message routing exchanges messages between restricted access servers, even though no other resources on the servers can be shared. For detailed information on using forced routing with restricted access links, refer to "Routing Mail on Restricted Access Servers" later in this chapter.
Routing Messages Through a Specific Path
If you exchange mail between two servers that are connected by a variety of paths, you can force mail messages to route to their destination following a specific path. For example, you can send mail to a particular server through a high-speed link, rather than a slow-speed link.
In most cases, you should let the mail service do the routing for you. Mail looks for the shortest possible path that is available. If one link in the shortest path is unavailable, mail routes the message over the best available path.
Reducing the Cost of Transferring Messages
If you exchange mail between two servers that are connected by a slow-speed link, you can reduce the network cost of transferring messages over the link. For example, you can prevent an originating mail service from sending multiple copies of the same message over the slow link. Instead, force route one copy of the message over the high-cost line and have the destination mail service make the multiple copies.
To use forced message routing, follow these guidelines:
Know the topology of the servers in the network. Ensure that the servers in the path you plan to use are connected and that the mail services are available. Know the names of the routing servers or their corresponding mail services. Know the StreetTalk names of the users on the target mail services. Use the service name cache to further reduce the network cost of transferring messages. This is especially important when using nicknames in the transfer service name field of the REMA address.
Forced message routing requires the REMA-addressing format, which is described in the next section.
Formatting Forced Routing Addresses
Forced message routing requires the REMA-addressing format:
transfer-server-name [local-name]
transfer-server-name is the name of the server through which you route the message. transfer-server-name must be running a mail service. Although you may specify the StreetTalk name of the mail service on the server through which you route the message as the transfer-server-name parameter, it is recommended that you use the name of the server. local-name is the StreetTalk user, list, or nickname to whom you send the mail message. It must be enclosed in brackets.
You can route mail through more than one server. You need to include only intermediate routing servers in the address; you do not need to include the destination server. All servers that are listed after the first routing server in the address must be nested in brackets, as follows:
server-name1[server-name2[StreetTalk name]]
Managing the Use of Forced Routing Addresses
Users can enter forced routing addresses directly into the address fields of messages. Like other REMA addresses, forced routing addresses can be lengthy. As an administrator, you can make REMA address easier to use. Refer to "Simplifying the Use of REMA Addresses" earlier in this chapter for instructions.
Make sure that addresses are valid and that the correct number of opening and closing brackets are included in the address. If there is a problem sending mail, you may have to verify server, mail service, and recipient names with administrators of the routing and target mail services.
When a remote server is linked to your network, users at that site can attempt to use your network resources. Administrators can protect network resources with appropriate access rights lists, or by restricting links between servers. Restricted links are discussed in "Routing Mail on Restricted Access Servers" later in this chapter.
The following examples illustrate Intelligent Messaging's forced message routing feature. They illustrate the feature used over temporary links, permanent links, and WANs.
Examples of the Forced Mail Routing Feature
Andre Girouard at WCTCA in Winnepeg wants to send a message to Hans Kruspig at WTCDE in Frankfurt. Andre' s mail service resides on server CAWIN001 and Hans' on server DEFRA002. Andre must route the message through the remote server USCHI001, which connects to CAWIN001 and DEFRA002 at different times.
CAWIN001 connects to USCHI001 from 9 a.m. to 12 a.m. DEFRA002 connects to USCHI001 from 2 p.m. to 5 p.m.
Andre includes this address in the message address field:
USCHI001 [Hans Kruspig@Sales@WCTDE]
USCHI001 is the name of the routing server. When the link between USCHI001 and CAWIN001 is active, CAWIN001 transmits the message to USCHI001. USCHI001 holds the message until the link is active between DEFRA002 and USCHI001. When the link between USCHI001 and DEFRA002 is active, the message is forwarded to Hans Kruspig's StreetTalk name, Hans Kruspig@Sales@WCTDE.
Jorg, at ARBUE001, wants to send mail to Elvira at DEFRA004 but has no active link to DEFRA004.
Server BEBRU003 has permanent links to DEFRA004, USCHI002, and ARBUE001. Jorg can send mail to Elvira by force routing the mail over a permanent link to BEBRU003. He could type BEBRU003 followed by [Elvira Schmidt@Forshung@WCTDE].
Figure 4-2 Forced Routing Over a Permanent Link shows server BEBRU003 connected to 3 servers by a permanent link to each.
Example 3 - Multiple Users Over a WAN
Lynn Gill wants to force route a message from server BEBRU001 over a slow-speed link to multiple destinations. Server USCHI002 is on the receiving end of the slow-speed link and is connected to servers USCHI003, USCHI004, and USCHI005 on a LAN. She wants to send the message to members of the Accounting department, whose mail service resides on USCHI003, to employees working in the Chicago Sales office, whose mail service resides on USCHI004, and to members of the Corporate Education department, whose mail service resides on USCHI005.
Figure 4-3 illustrates this network configuration.
Lynn enters these addresses in the address field:
USCHI002 [Accntng@Admin@Corp],
USCHI002 [ChiSales@Sales@Corp],
USCHI002 [Instruct@EdDept@Corp]
The mail service transports a single copy of the message to USCHI002 on the receiving end of the slow link. The mail service on USCHI002 makes a copy of the message for each of the destination mail services on USCHI003, USCHI004, and USCHI005, and transfers each copy to its intended recipient.
By force routing the message, Lynn prevents the origination mail service (on BEBRU001) from sending three copies of the message over the slow link. Instead, only one copy of the message is sent over the high-cost line and is copied to the three recipients over the low-cost LAN.
Routing Mail on Restricted Access Servers
If security is important to all or part of your network, you can restrict access to network servers. You can set up two servers with a restricted access serial link. Restricted access means that the two servers exchange only mail messages. StreetTalk names and resources on the two servers remain separate. Restricted access can apply to both permanent and temporary links. For information about setting up remote servers with restricted access, see Managing VINES Security.
To send mail across restricted access links, you must:
Use the forced message routing feature Include, in the routing address, the names of the servers on the sending and receiving ends of the restricted link
The REMA-addressing format is required to address mail between two servers with restricted access:
sending server-name[receiving server-name[StreetTalk name]
sending server-name is the name of the server on the sending end of the restricted link. receiving server-name is the name of the server on the receiving end of the restricted link. You must specify the server name. You cannot use the mail service name. StreetTalk name or nickname (local name) of the user to whom you are sending the mail message. You can also use a StreetTalk list as the recipient address. Enclose the recipient address in brackets.
Examples of Forced Message Routing to Restricted Access Servers
The following two examples illustrate the forced message routing feature on restricted access servers. The first example uses a configuration with a single, restricted access serial link. The second example uses a configuration that has two restricted access serial links and a LAN.
Example 1 - Single-Link Configuration
Luta Franken at WCTDE in Frankfurt wants to force route a message from server DEFRA001 over a restricted access link to David Berger, whose mail service is on server DEFRA002.
Luta enters this address in the address field:
DEFRA001[DEFRA002 [David Berger@Personnel@WCTDE]]
DEFRA001 is the name of the server on the sending end of the restricted link. DEFRA002 is the name of the remote server on the receiving end of the restricted link. DEFRA002 is also where David Berger's mail service resides. [David Berger@Personnel@WCTDE] is David's StreetTalk name.
Example 2 - Two Restricted Links and a LAN
Dennis Heath wants to force route a mail message from server USCHI011 over two restricted access links to Linda Meyer on USCHI013.
USCHI012 and USCHI013 are both on the receiving end of the restricted link. Therefore, Dennis must enter both server names with Linda's StreetTalk name in the address field:
USCHI011[USCHI012 [USCHI013 [Linda Meyer@Admin@WCTUS]]]
USCHI011 is the name of the sending server on the restricted link. USCHI012 is a receiving server which also sends the mail message to USCHI013. USCHI013 is the name of the receiving server on the restricted link. USCHI013 is also where Linda Meyer's mail service resides. [Linda Meyer@Admin@WCTUS] is Linda's StreetTalk name.
Dennis also wants to force route a mail message to Erick Landon, whose mail service is on USCHI014. As shown in Figure 4-6, USCHI014 has a LAN connection to USCHI012. Dennis enters this address in the address field:
USCHI011[USCHI012[Erick Landon@Sales@WCTUS]]
USCHI011 is the name of the server on the sending end of the restricted link. USCHI012 is the name of the server on the receiving end of the restricted link. USCHI014 is not required in the routing address because the message is routed automatically over the LAN connection.
