You may already be familiar with the SMTP MTA, because it's been available as a free add-on component to Domino since the summer of 1996. Now with Release 4.6, the SMTP MTA is included as a native component of the core Domino server. "Given it's importance to customers, it was clear that with Domino 4.6, the SMTP MTA should be shipped as part of the server package and installed as part of the server installation," says Paul Wattenberger, Director of Communications Server Development. "This [integration] simplifies the installation process, and greatly simplifies the configuration/setup process."

This article explains more about what the SMTP MTA is, and what the integration with Domino brings you, including an overview of how mail messages travel between Notes and the Internet via the MTA. For examples on setting up the SMTP MTA in your organization, please see the book Planning your Domino System, part of the documentation that is shipped with your Domino 4.6 server. For specific information on using the SMTP MTA, see the book Extending your Domino System. (Both books are also available as part of the Domino Administration Help.)

What is the SMTP MTA?
The SMTP MTA allows the Domino server to transfer Simple Mail Transfer Protocol (SMTP) messages between SMTP networks (both Internet and intranets) and Notes, X.400 and cc:Mail users. Other Internet mail clients that use Domino as a message store, such as POP3 and IMAP clients, also require SMTP support for transferring messages.

The SMTP MTA is designed to help organizations connect to customers, partners and suppliers over public networks. The MTA also provides organizations with the ability to securely link Domino networks over public carriers, thereby reducing the resources (time and money) needed to set up and maintain an inter-enterprise messaging system. Some firewalls allow only specific applications, like SMTP, to access the Internet's TCP/IP capability. In cases like this, where SMTP is the only TCP/IP protocol available between two Notes environments, the MTA can encapsulate Notes mail messages over the SMTP network. This provides high-fidelity transfer of Notes mail messages when connected to an SMTP backbone.

Based on standards
The SMTP MTA is based on several Internet Request for Comments (RFCs), including:

• RFC821 Simple Mail Transfer Protocol
• RFC822 Standard for the Format of ARPA Internet Text Messages
• RFC1521 MIME: Part I (message bodies)
• RFC1522 MIME: Part II (message headers)
• RFC974 Mail routing and the Domain System
• RFC1123 Requirements for Internet Hosts - Application and Support

Both gateways and MTAs can act as protocol converters, moving messages from one system to another, and converting message formats, addresses, attachments and/or message content. But only MTAs provide native message delivery from one system to another. MTAs are multi-threaded, and offer a higher level of functionality than gateways by providing scaleable, high-performance routing of messages in their native format. For example, an MTA can route a message across several mail systems to its destination without needing to disassemble and reassemble it at each juncture. Instead, MTAs perform message relaying, encapsulating the message and sending it over the infrastructure in its native format. Gateways, on the other hand, must disassemble and reassemble all of the messages they receive. Doing so reduces the reliability, performance and accuracy of the messaging system. Because gateways do not encapsulate the native Notes message format, they cannot provide full message fidelity, and message richness is degraded. Consequently, messages may lose some or all of their formatting.

The goal of an MTA is to make the connection seamless and to make messages flow as smoothly in a heterogeneous environment as they would in a homogenous environment. The major example is in the use of the "reply to all" capability. With an MTA, "reply to all" will work consistently even for messages sent to several different locations. For example, when a Notes user sends a message to recipients in multiple Notes domains -- out on the Internet, in cc:Mail (through the cc:Mail MTA) and in X.400-based networks (through the X.400 MTA) -- any one of the recipients can do a "reply to all" and be confident that all of the original recipients and the sender get the message. With a gateway, the "reply to all" may not work, because the gateway can't relay messages.

Integration with the Domino server
Speaking from a development perspective, Paul Wattenberger says "making the SMTP MTA part of the server enables us to more tightly integrate Internet protocol support into Domino. As part of the server, we can make full use of the services within Domino to provide increased function and higher throughput." These services include support for dial-up connections to an Internet Service Provider for customers that don't have a dedicated Internet connection. Integration also means the SMTP MTA can be installed and configured in a central location using the Domino Public Address Book. Administration of the MTA can be done from within Domino, taking advantage of the logging and tracing capabilities that already exist for other core Domino services.

In addition, Domino 4.6 includes a new "Internet message storage" field in users' Person documents, which allows a RFC822/MIME message to be stored in its whole (unconverted) format in the Notes object store. This provides 100 percent message fidelity when mail is rendered by a POP3 or IMAP client. For more information on this MIME support, see the article "MIME Support in Domino 4.6."

Install and configuration
The SMTP MTA is now automatically installed during the standard Domino 4.6 server installation. Then, using the new Setup database, you can simply select "Internet mail packages" as an audience for your server, and the SMTP MTA is automatically configured for you.

Depending on your needs, you may also need to create or edit the following documents in the Public Address Book:

• The Server document -- for identifying the MTA to the server upon which it resides.
• The Global Domain document -- for instructions on converting Notes mail addresses to SMTP addresses.
• The Foreign SMTP Domain document -- for defining the relationship between the Notes domain and the external mail system.
• The Server Connection document -- for creating a logical link between the MTA and the Foreign SMTP domain.

Message management
The Domino SMTP MTA is fully integrated with Domino management, routing, directory, security, log/trace, transport and message conversion services. For example, the SMTP MTA automatically sends statistical information to Notes.

You can monitor and control the MTA from:

• The Domino administration panel
• Lotus NotesView
• Any SNMP-compliant management platform

Message Addressing
Because the SMTP MTA is tightly integrated with the Domino server and offers native support for SMTP addresses, it offers flexible, easy-to-use addressing support. Notes client users can simply type an address on the "To:" line of a message, without the need for modifiers or suffixes, because the Domino MTAs provide native support for these address types. An SMTP address can also be entered directly into the Domino Public Address Book. Domino allows organizations to define how its users' Internet addresses are mapped to names in the Domino directory, accommodating virtually any enterprise e-mail naming policy. For example, my e-mail address can be: ckraut@electra.com, Carolyn_Kraut@electra.com, carolynk@development.electra.com, "Carolyn Kraut" <carolynk@electra.com>, and so on.

Examples of the level of support that native standards-based addressing offers Notes users and Domino administrators include:

• Notes users can optionally be addressed using multiple Internet domain names; for example, jane@acme.com can also be addressed as jane@justmerged.com. So, information about users need not change each time the organization changes. This feature also allows creation of "simple" business card addresses that are independent of the network topology.
• The MTA's administrative management domain services can be configured to restrict access to users in local Domino domains within a Lotus global domain, or to provide unrestricted access for any user with mail connectivity to the Domino network. Domino domains can reside in multiple Lotus global domains, enabling administrators to control who can send mail to whom and to specify who is permitted to incur charges on the public network.

Well, maybe it's not that simple. The SMTP MTA part of the above process consists of a number of Notes tasks and databases that are used to process messages, making the SMTP mail connection as scaleable as possible through the use of multiple processes.

As shown in the following flowchart, the Outbound Message Converter first polls SMTP.BOX at regular intervals for new outgoing messages. The Outbound Message Conversion task converts the Notes message into SMTP format, making it ready for transmission. The message is then copied into the Outbound Work Queue, and the original message in SMTP.BOX is marked as "pending." The message is then passed to the Outbound Session Controller, which controls the transport of the converted messages to their respective SMTP destinations. It launches or notifies one or more session handlers to perform the transport of the message or messages to each destination -- grouping messages together by location whenever possible. By default it can launch three handlers, but can be configured to launch up to 8 handlers. These handlers perform the actual tasks of connecting to the destination or next hop in the SMTP system.

Messages are then delivered, and errors either temporary or permanent are passed back. The handlers then change the state of the message in the Outbound Work Queue to "sent." Finally, the Delivery Report Task removes the message from the Outbound Work Queue and SMTP.BOX. If the message handler is unable to deliver a message because the destination is unavailable, the message is requeued and resent later. If the message cannot be delivered because the host is unknown, or the addressee is unknown, a delivery failure report is sent to the sender of the message.

Mail Routing from the Internet to Notes
When mail comes in from the Internet to a Notes mail user, it follows a similar path to the one followed by a message going out to the Internet. As with outbound processing, the central goal is to make the SMTP mail connection as scaleable as possible through the use of multiple processes.

As shown in the following flowchart, the Inbound Session Controller controls the receiving of messages from other SMTP systems via TCP/IP. It listens on the SMTP well-known port 25 and accepts the initial incoming connection. It then launches or notifies an Inbound Session Handler to take the connection so that it can listen for a new connection. Like the Outbound Session Controller, the Inbound Session Controller can launch three session handlers by default. It can also be configured to launch a maximum of 8 session handlers. The Inbound Session Handler accepts the inbound message and places it in the Inbound Work Queue still in SMTP format. The Inbound Message Conversion task converts the message into Notes format. It also converts the destination user address to Notes format and checks to see if the address is deliverable. If the message can't be converted or the address is not deliverable, it will indicate that delivery has failed. A Non-delivery Report will then be generated. If the message is not destined for Notes, it will put the message into the work queue for the Outbound Transport.

As stated earlier, the SMTP MTA can store the message in its original MIME format, depending on the setting of the "Internet mail storage" field in the user's Person document. Again, for more information on MIME, see the article "MIME support in Domino 4.6."

Conclusion
The Domino SMTP MTA is a powerful tool that makes sending Internet mail easier for your users, with the benefits of greater reliabilty and better message fidelity. And now that it's integrated with Domino, you can readily install, configure, and maintain the MTA for your organization.

Copyright 1997 Iris Associates, Inc. All rights reserved.