HP 3000 Manuals HP 3000 Manuals
Domains and Addressing Within a domain, all users share a number of attributes. In an ADMD, an O/R addressmay consist solely of Country, ADMD, and Personal name. In a PRMD, there may be no ADMD name, but there is a PRMD name. In a PRMD, other attributes are normally specified to reflect the organizational structure and to allow routing to take place between the MTAs in the PRMD. Any of the attributes can be used to specify the routethe message should take from the MTA. Users whose UAs are associated with the same MTA should have a unique combination of Organizational attributes within the domain. For example, Figure 2-5 illustrates a scenario with four MTAs in a PRMD. Note that MTA 1 is not connected directly to MTA 4, so any messages it sends to MTA 4 must be routed through an intermediate node. The message can be routed through MTA 2 or MTA 3.Figure 2-5. O/R Address and Routing Between MTAs in a domain, a routing algorithmis set up which determines the path that a message for a particular recipient takes through the MTS. For the example shown in Figure 2-5, the algorithms for each of the MTAs are: MTA 1 If Org. Name=A and Org. Unit=1 then UA is local If Org. Name=A and Org. Unit=2 then UA is on MTA 3 (Route to MTA 3) If Org. Name=A and Org. Unit=3 then UA is on MTA 3 (Route to MTA 3) If Org. Name=B then UA is on MTA 2 or MTA 4 (Route to MTA 2) MTA 2 If ORG. Name=B and Org. Unit=1 then UA is local If Org. Name = B and Org. Unit=2 then UA is on MTA 4 (Route to MTA 4) If Org. Name=A and Org. Unit=1 then UA is on MTA 1 (Route to MTA 1) If Org. Name=A and Org.Unit=2 then UA is on MTA 3 (Route to MTA 3) If Org. Name=A and Org. Unit=3 then UA is on MTA 3 (Route to MTA 3) MTA 3 If Org. Name=A and Org. Unit=2 the UA is local If Org. Name=A and Org. Unit=3 then UA is local If Org. Name=A and Org. Unit=1 then UA is on MTA 1 (Route to MTA 1) If Org. Name=B and Org. Unit=1 then UA is on MTA 2 (Route to MTA 2) If Org. Name=B and Org. Unit=2 then UA is on MTA 4 (Route to MTA 4) MTA 4 If Org. Name=B and Org. Unit=2 then UA is local If Org. Name=B and Org. Unit=1 then UA is on MTA 2 (Route to MTA 2) If Org. Name = A the UA is on MTA 1 or MTA 3 (Route to MTA 3)
NOTE For MTA 4, it is better to route a message for Org. Name "A" through MTA 3, which extracts its own recipients and forwards the message to MTA 1. Routing the message through MTA 2 would be more expensive.
The example shown in Figure 2-5 illustrates routingwithin a domain. The routes that are added to connect to other domains depend on some additional issues. In adding a route to an ADMD, the primary issue is cost. The nature of the subscription to a public service varies between ADMDs. Charging may be on the number of users connected, the number of addresses connected, or many other variations. The precise conditions obviously have an impact on the choice to be made. The other primary consideration is that of performance. If a message is eventually to be routed to the public service, it is best to minimize the number of "hops"that must be made internal to the domain. In the example in Figure 2-5, it is best to have a single connection to MTA 3, since that would mean at most one "hop" within the domain. Remember that MTA 3 may become saturated if too many messages are being routed through it, since it is also relaying all messages between MTA 1 and MTA 4. The optimum situation is to have as many interconnections as possible within the domain to minimize hops. However, this obviously makes for a more complex configuration. Another consideration in deciding the configuration is that of security. You, as Network Administrator, must explicitly allow any route out of the domain. You can control exactly which domains can be accessed from the local domain. These domains may be adjacent with at least one MTA in the local domain connected to at least one in the adjacent domain, or domains may be accessed through intermediate domains. For example, if you want a connection to another PRMD called "Y," add to the algorithm for MTA3 the following: IF PRMD=Y then UA is in Private Domain Y (Route to MTA in domain "Y") If users in the local domainwant to route to a domain "Z" which is not adjacent to the local domain but can be reached through domain "Y" (typically if "Y" is an Administration domain), another additional entry can be made in the algorithm for MTA 3: IF PRMD=Z then UA is in Private Domain Z (Route to MTA in domain Y) This routes all messages for recipients in the domain "Z" through domain "Y." This assumes that domain "Y" is able to route forward to domain "Z," but does not imply that "Z" is adjacent to "Y." It may be that the message passes through several other "hops" before eventually arriving at domain "Z." The only requirement is that at each stage the relaying domain knows how to route to the destination domain "Z." Also note that unless an additional entry is made for each MTA in the local domain, either to MTA 3 or a direct connection to domain "Y," users on these MTAs are not able to send messages to domain "Y" or "Z." In this way, access to other domains can be controlled on a per MTA basis. Choosing the Addressing Scheme in the Local Domain When you decide the addressing scheme to be used within the domain, it is important to consider future expansion. If a domain consists of a single MTA, it is possible to specify only PRMD and Personal name in the UA O/R names. However, if a second MTA is added at some stage, there is no easy way of routing between the two MTAs since both have the same PRMD and their attributes are the same for the Personal names. It is better from the beginning to at least specify the Organization Name and possibly one Organizational Unit. When additional MTAs are added, you can add a route for the new MTA, based on the Organization Name or Unit allocated. Incorrectly Configured Domains If a domain is incorrectly configured, there is the possibility that loopingmay occur. For example, if MTA 3 was configured to route messages for MTA 4 through MTA 1, then a message sent from MTA 1 for MTA 4 would arrive once more at MTA 1. This results in a nondelivery notificationto the sender of the message with a "Loop detected" error message. Examination of the configuration of the MTAs in the route should reveal the problem. Loops detected in other domains require a more detailed examination of the nondelivery reportthat is returned, which includes the domain that issued the notification. With a sensible approach to routing, this situation can easily be avoided.
![[]](../../pic3k/M011985/FFN83c50.gif)