Mail Routing with Internet Addressing Enabled

Now that you understand the concepts behind GroupWise Internet addressing, this section discusses the flow of email through an Internet addressingenabled GroupWise system.

Outbound Email

Internet addressingaware (or IA-aware) clients (GroupWise 5.5x and newer clients) allow mail with Internet addresses to be routed internally or to Internet users without the use of addressing rules or external domain definitions. Without Internet addressing enabled (and no addressing rules in use), messages sent to users with Internet-style addresses are flagged as undeliverable when mail is sent from the client.

With Internet addressing enabled, the client performs less lookup on recipient addresses. Messages with Internet-style addresses are pushed on by the client to be resolved by the POA, MTA, or GWIA. Note, though, that each component in an IA-aware GroupWise system is capable of parsing Internet address information to some extent, including the GroupWise client. Each component (client, POA, MTA, and GWIA) will do the best it can to resolve the address from its perspective.

If the POA cannot resolve an address, it pushes the message to the domain MTA. If the message is addressed to an Internet address, and the domain MTA cannot resolve the message to one of its post offices or an address internal to the system, the message will be routed to the default routing domain for a GWMTP lookup by the MTA there (you can find more on GWMTP in Chapter 34). If the recipient address cannot be resolved with a GWMTP DNS lookup, the message will be routed to the default GWIA for transfer to the Internet.

Inbound Email

When a message arrives at a GroupWise system from the outside world, it does so in one of two ways:

• Direct MTA-to-MTA transfer via GWMTP (see Chapter 34)

• SMTP/MIME transfer via the GWIA

Note

Messages can also come in through another GroupWise gateway, but typically those are not going to be outside-world messages. Most other gateways, such as the Exchange gateway or the Lotus Notes gateway, are handing explicitly addressed messages to the GroupWise MTA, so the messages can be treated as internal to the GroupWise system.

When a message comes in via GWMTP, the MTA receiving the message will process the message by sending it to the GroupWise domain within the GroupWise system of which the recipient is a member. The recipient's domain routes the message to the recipient's POA, which delivers the message to the recipient's mailbox.

When a message comes in through the GWIA, via SMTP/MIME, it is processed with the flow described in Figure 16.9. The GWIA checks the domain portion of the recipient address for user alias, post office alias, foreign ID, or Internet domain name matches. If GWIA does not find a match for the recipient domain address, it will route or relay the message to an appropriate Internet mail host for the specified domain, or it will send an undeliverable message back to the sender.

Figure 16.9. An example of the parsing and lookup process

Assuming that a match was found (that is, the message must be delivered to this GroupWise system), the second level of resolutions involves checking the username portion of the recipient mail address to determine whether a unique match can be found.

Note

The GWIA is fully backward compatible for resolving traditional GroupWise addressing, in addition to using the flexible rules of Internet addressing resolution.

This section explores this address resolution process in more detail.

Following is the logic that the GWIA uses in routing in-bound Internet email:

1.	Compare user@domain (the entire string, not just the user portion) against user Gateway aliases defined at the GWIA. If there is a match, the message can be passed directly to the MTA to be routed to the user. If there is no match, move to step 2.
2.	Compare the user portion of the address against user Gateway aliases defined at the GWIA. If there is a match, move to step 3. If not, move to step 4.
3.	Compare the domain portion against post office aliases, Internet domain names, or foreign IDs defined for this system or assigned to the GWIA. If there is a match, the message is passed to the MTA to be delivered. If not, the message does not belong to this GroupWise system and will be passed to the Internet (or passed to another host if the GWIA is configured to allow the feature called Forward Undeliverable Inbound Message to Host). Otherwise, the message is discarded. Note If the message arrived at the GWIA from the MTA (that is, it came from inside the system), it will still be checked to determine whether it belongs on this system, using steps 1 through 3. This is how messages addressed by non-IA-aware components to recipients on this system are handled.
4.	Does user@domain match up with a UserID@Post office alias string? If so, the message is passed to the MTA for delivery. If not, go to step 5.
5.	Compare the domain portion of the address against the Internet domain names defined on the system and against the foreign ID assigned to the GWIA. If there is a match, move to step 6. If not, the message is delivered to the Internet. Note Steps 1 through 5 checked out aliases, which are shortcuts to address resolution. Anything that makes it to step 6 is not going to match up to a user or post office alias, but does match up with this system's Internet name or names.
6.	After the message is known to belong to the system, a parsing engine tries to uniquely resolve the user portion of the address with a GroupWise user. The parser engine compares the user portion of the recipient address (everything on the left side of the @ symbol) with the following GroupWise information: Free Form/User Override set: The contents on the left of the @ sign are checked for any matches defined on the Internet Addressing properties page of a user object. The free-form override setting is one way to give a user an Internet address that does not comply with the system defaults. This setting is on the Internet Addressing properties page of any user object. The free-form field is the second field below the Preferred Address Format field. If a match is found here, the system has a unique match. For an example, take a look at Figure 16.7. UPD resolution: The address is parsed and compared against the address book for matches in User.PostOffice.Domain format. If the user portion has fewer than three segments (that is, there aren't two dots in the user portion), it will be compared in User.PostOffice, or just User, format. DPU resolution: The address is parsed and compared against the address book for matches in Domain.PostOffice.User format. Again, if the string is not long enough, it will be compared in PostOffice.User format. Name-based resolution: The address is parsed and compared against the address book for matches to FirstName.LastName, LastName.FirstName, and FirstinitialLastName. Note FirstinitialLastName format is not enabled by default in a GroupWise system, and will not be looked up unless the administrator has enabled it.
7.	If there are no matches for the parsed user portion of the address, the message becomes undeliverable. If there are matches, even partial matches, move to step 8.
8.	A preference filter is applied, and if the parsed address is unique at any level of preference, it is delivered. Partial addresses are passed to the MTA for complete resolution at the MTA or POA level. If the parsed address is not unique, the message is undeliverable.

The process that the GWIA uses to get a message to a recipient is quite complex. The flexibility that GroupWise gives you for defining a user's address format is what makes the process so complex.