Understanding the Parsing and Lookup Process

In the flow in the preceding section, the GWIA reached a point in step 6 where it had to parse the user portion of an Internet-style address, and then perform a lookup to determine whether there were any matches. It is important that you understand the rules behind the parse and lookup, because they will affect the decisions you make when implementing Internet addressing on your GroupWise system.

Every component on an IA-aware GroupWise system can perform the parsing and lookup operations described next and outlined in Figure 16.9. When messages come in to the system through the GWIA, the GWIA parses and looks up. Messages coming in through the MTA via GWMTP will have their addresses parsed and looked up by the MTA.

In the process shown in Figure 16.9, an Internet-style address has been handed to a GroupWise component, and that component has reached the point where it must parse the user portion of the address. The balance of this section explores the process.

Following is the parsing process that GroupWise uses to determine the correct recipient of a message:

1.	GroupWise begins with a parse and lookup for matches in UPD (User.PostOffice.Domain) format. If the user portion of the address has fewer than three components, GroupWise will perform a User.PostOffice or a user lookup. If there is one and only one match, GroupWise delivers the message. If there is more than one match, GroupWise goes to step 3. If there are no matches, GroupWise continues with Step 2.
2.	GroupWise now parses and looks for matches in DPU (Domain.PostOffice.User) format. This is the legacy addressing format used by GroupWise. Again, if there are fewer than three components to the user portion of the address, GroupWise will perform a PostOffice.User lookup. There's no need to do a user lookup, thoughGroupWise did that in step 1. If there is one and only one match, GroupWise delivers the message. If there are multiple matches, GroupWise goes to step 3. If there are no matches, GroupWise goes to step 4.
3.	Messages will be delivered to the closest match. If one of the matches is on the same post office as the component doing the parsing and lookup, that match will be chosen above other matches. If there is only one preferred match, the message will be delivered. If there is more than one match (that is, there are no preferred matches), the message becomes undeliverable or ambiguous. If the GWIA, the POA, or the MTA reaches this point, the message is undeliverable. If the client reaches this point, however, the user might be prompted to resolve the ambiguity.
4.	GroupWise now checks the usernames. GroupWise looks for matches in First.Last, Last.First, Firstinitial.Last, and three-part name format and will check all possibilities at once. If there is one and only one match, the message is delivered. If there is more than one match (for example, the message is addressed to James.Howard, and you have a Howard James and a James Howard on the system), the message is ambiguous or undeliverable. No delivery preferences are applied. If there are no matches, the message becomes undeliverable.

Parsing Usernames

It might be helpful at this point to look deeper at step 4 from the preceding section. Here is the logic followed when a GroupWise component parses the user portion of the address for matches with users' full names:

1.	Replace all periods left of the @ sign with spaces.
2.	If there is more than one space, see step 7.
3.	Assign the text left of the space to Part_A.
4.	Assign the text right of the space to Part_B.
5.	Search the given and last names for all users in the GroupWise system. Compare the following combinations, and select all matches: Given=Part_A Last=Part_B Given=Part_B Last=Part_A
6.	Skip to step 11.
7.	Assign the text left of the first space to Part_A.
8.	Assign the text between the first space and the second space to Part_B.
9.	Assign the rest of the text to Part_C.
10.	Search the given and last names for all users in the GroupWise system. Compare the following combinations, and select all matches: Given=Part_A Last=Part_B Part_C Given=Part_A Part_B Last=Part_C Given=Part_C Last=Part_A Part_B Given=Part_B Part_C Last=Part_A
11.	If no matches exist, skip to step 16.
12.	If a unique match is found, skip to step 17.
13.	External users who match are eliminated if internal matches exist.
14.	Matches outside the local GroupWise domain are eliminated if matches exist in the local GroupWise domain.
15.	If a unique match is found, skip to step 17.
16.	The message is undeliverable because no match is found.
17.	Deliver the message.

Understanding parsing scenarios is most likely to be important in larger GroupWise systems, and in GroupWise systems that do external system synchronization with one another.

Parsing Scenarios

Here are a couple of sample scenarios to let you see how these pieces fit together, beginning with the following:

• A message is addressed to [e-mail].

• User Mike Sales exists in the CORPPO post office.

• There is a post office called Sales on the system somewhere.

• No user or post office aliases exist.

Here's what will happen. The GWIA for WorldWide Widgets will decide that the message belongs on this system and will attempt to resolve the user portion of the address. Now walk through the logic in the following steps:

1.	The string mike.sales is compared against the address book for UPD matches. Because there are only two parts to the string, it compares mike for user matches and sales for post office matches.
2.	A partial match is found. There is a post office called sales on this system.
3.	The message is routed to the sales POA for resolution of the remainder of the address.
4.	The sales POA looks for a user ID mike on the local post office and finds none. The message is undeliverable. Note here that having post office names that match usernames can cause problems for messages addressed in First.Last or Last.First format.

And now for the second scenario, note the following:

• A message is addressed to [e-mail].

• A user with the first name Marcel and the last name de Korte exists in the CORPPO post office.

• No user or post office aliases exist.

In this case, the GWIA for WorldWide Widgets will end up attempting to resolve the user portion of the address as a three-part name:

1.	The GWIA looks for a user ID marcel on the post office de in the domain korte. No matches are found. The names de and korte do not match any post office or domain names on this system.
2.	The GWIA looks for a user ID korte on the post office de in the domain marcel. No matches are found. The names de and marcel do not match any post office or domain names on this system.
3.	The GWIA looks for users with the following names: First=Marcel, Last=de Korte First=Marcel de, Last=Korte First=Korte, Last=Marcel de First=de Korte, Last=Marcel
4.	One match is found, and the message is delivered to user Marcel de Korte.