Using Notes/Domino SMTP with a DMZ

Part 2

We conclude our two-part article series about setting up a DMZ to help protect your company's resources with a look at several different scenarios for hosting Domino servers in the DMZ to control inbound and outbound SMTP mail traffic.

Share:

David Bell, Senior IT Architect, IBM, Software Group

David Bell is a Senior IT Architect with the IBM Software Group, specializing in services for the Lotus Software brand of products. In that capacity, he is responsible for anticipating and resolving technical issues that arise in the course of consulting engagements and for designing, building, and implementing messaging infrastructures that meet customer needs. He works with customers to facilitate the formulation and execution of information strategies that are innovative and well aligned with their business goals. David has been working with Lotus Notes and Domino since the 1990s, designing and implementing architectures for organizations of all sizes.



Timothy Speed, Senior IT Architect, IBM, Software Group

Timothy Speed is an infrastructure and security architect for IBM Software Services for Lotus (ISSL). Tim has been involved in Internet and messaging security since 1992. He also participated with the Domino infrastructure team at the Nagano Olympics and assisted with the Lotus Notes systems for the Sydney Olympics. His certifications include MCSE©, VCA (VeriSign Certified Administrator), Lotus Domino CLP Principal Administrator, and Lotus Domino CLP Principal Developer. Tim has also co-authored four books: The Internet Security Guidebook, ISBN: 0122374711, February, 2001; The Personal Internet Security Guidebook, ISBN: 0126565619, October, 2001; Enterprise Directory and Security Implementation Guide: Designing and Implementing Directories in Your Organization, ISBN:0121604527; and Internet Security: A Jumpstart for Systems Administrators and IT Managers, ISBN 1555582982.



15 November 2004

Also available in Japanese

In Part 1 of this article series, we began our discussion of how to configure Lotus Notes/Domino to route SMTP mail through a DMZ. We continue this theme in Part 2, examining in detail how Domino servers can be hosted in the DMZ to provide the first point of relay for inbound traffic and the last point of relay for outbound traffic. Along the way, we present several different example configuration scenarios. As with the first article, experience with administering Lotus Notes and Domino will help you understand the concepts we discuss. And if you haven't already read Part 1 of this series, we suggest you do so now.

Domino servers in the DMZ

Security is always a high priority when deploying services that will be accessible to other systems beyond your control. Hosting Domino servers in a DMZ is no exception. The following are best practices that you should use when deploying Domino servers in a DMZ:

  • Lock down the operating system and disable all unnecessary services.
    The only connectivity to your Domino servers from the outside should be on port 25 to allow SMTP mail routing. From the internal network, Notes NRPC traffic is required to allow administrators access to manage the servers (and potentially for replication of directory information). You can use an internal pass-thru server as a proxy to allow only one IP address through the firewall to the DMZ.
  • Disable all unneeded Internet protocol ports.
    By default, port definitions on Domino Server documents are enabled. All ports should be disabled except for the SMTP ports.
  • Run only the necessary Domino server tasks.
    Domino SMTP servers require a core set of tasks; no others should be running.
  • Modify the server SMTP greeting.
    Do not advertise the mail system used to potential hackers. Set the SMTP welcome banner to a generic greeting that does not show Lotus Domino and its version information. Use the Notes.ini variable SMTPGREETING to do this. For example, set SMTPGREETING="ESMTP Service ready at %s" where %s is replaced with the system date and time.
  • Do not use the internal certifiers to register the Domino servers.
    Create a new certifier structure for these servers and cross-certify these servers for access by administrators and internal Domino servers. Use generic naming conventions rather than following the internal structure. Again, this is to minimize the amount of information about your internal environment that is available to the outside world. For example, these servers could be SMTP01/SERVERS/SMTP.
  • Minimize the available directory information hosted on the servers.
    It is not a good idea to have a full replica of the internal Domino Directory in the DMZ. If security is compromised, this could provide a treasure trove to spammers or hackers. Place the DMZ servers in their own domain so that the only entries contained in the Domino Directory are Server documents and a few groups that may be necessary for configuration. Following the same principles as the certificate hierarchy, choose a generic domain name such as SMTP.
  • Use an Extended Directory Catalog if address verification is required.
    To perform address verification of inbound mail, the Domino SMTP servers need a directory. Again, rather than publishing the internal Domino Directory, create an Extended Directory Catalog on internal servers that contains only user name and Internet address information. This can then be replicated to the Domino SMTP servers and referenced through Directory Assistance. Publish only the minimal information necessary to allow the servers to perform their tasks. (We discuss this type of configuration later in this article.)

Routing in and out of the DMZ

After your servers are deployed in the DMZ, you need to configure them to allow SMTP mail routing in and out.

Outbound routing

Let’s look at outbound first. The internal Domino servers must be able to route mail to the SMTP gateways. There are two ways to do this: via NRPC or via SMTP connections. NRPC is the standard that Domino servers use for mail routing and replication and requires port 1352 access through the internal firewall. The SMTP servers should not be in the same domain as the internal servers; therefore, they cannot share a Notes Named Network, so mail routing connection documents are required.

A simpler way is to allow one or more internal Domino servers to route SMTP to these servers in the DMZ over port 25. A relay should be specified for each internal Domino server that will send to these servers in the DMZ. The relay host name should resolve in the internal DNS to one or more MX records, thereby allowing for redundant routing paths.

Part 1 of this article series showed an example using a different SMTP TCP port between the DMZ Internet facing servers and the internal trusted network servers. If this is a requirement for your company, use a port list TCP 2222. This rule can also be accommodated by using Notes NRPC between the two groups of servers. The Internet facing servers listen on TCP port 25 (per the standard), and traffic that traverses the internal part of the DMZ is routed via TCP port 1352.

Inbound routing

Inbound routing from the Internet to the SMTP servers is achieved using MX records in the external DNS that determine to which server or servers the inbound mail is routed. Once the message reaches the Domino SMTP servers in the DMZ, the next hop must be determined for the message to continue on its inbound path. At this point, we simply want the servers to send all inbound mail they accept to one or more internal Domino servers.

This is a job for a smart host. This is a very simple way to tell the Domino servers in the DMZ to hand over all mail for internal SMTP domains that they accept to a specific relay address. This relay address should relate to one or more MX records in the DNS to control priority over the routing path in scenarios where redundant paths are available.

Routing scenarios

The following scenarios and diagrams illustrate these concepts. In these diagrams, red paths indicate primary routes and blue indicate a backup route used in the event of failure on the primary path.

Scenario A: Single point of presence, multiple SMTP servers
In this scenario, SMTP1 is the primary outbound path, and SMTP2 is the primary inbound path. Each acts as a backup path for the other in the event of server failure.

Figure 1. Single point of presence, multiple SMTP servers
Single point of presence, multiple SMTP servers

The inbound routing flow is as follows:

  1. The mail servers look up acme.com in the DNS and find two available hosts, SMTP1 and SMTP2.
  2. SMTP2 has the lowest MX preference as the preferred inbound mail relay, so mail is routed to SMTP2 (provided it is available). Otherwise, mail is routed to SMTP1.
  3. SMTP1 and SMTP2 resolve the smart host entry of inbound.acme.com and find two possible next hop hosts, HUB1 and HUB2.
  4. Provided HUB1 is available, the SMTP server relays to it and uses HUB2 if it is not.
  5. After it reaches HUB1 or HUB2, regular Notes mail routing occurs.

The outbound routing flow is similar:

  1. HUB1 or HUB2 has mail destined for an external Internet address.
  2. They resolve their relay host entry outbound.acme.com and find two available hosts, SMTP1 and SMTP2.
  3. The preferred outbound server, SMTP1, has a lower MX preference. Therefore, the mail is routed there (provided it is available); if not, the HUB server will route to SMTP2.
  4. The SMTP server queries DNS for the domain of the recipient (destination.com) and connects to the host depending on the MX records returned.

The MX record weights do not have to be biased to one server versus another. If you want to have both inbound and outbound mail distributed evenly between the servers, then make the MX record preferences the same for each pair of servers.

It is common practice to separate inbound and outbound routing because it simplifies troubleshooting under normal circumstances. Single servers at each of these points would represent the simplest configuration possible. Having more than one server at each point provides some resilience against server failure.

Scenario B: Multiple points of presence, multiple SMTP servers
To protect against major site failure, such as ISP network connections or a disaster, a more complex scheme is required. This is where multiple points of presence really provide benefit. In this scenario, we are talking about two points of presence specifically, but the architecture can be extended multiple times to cover more if required.

If the mail domain name is a single entity (such as acme.com) and is not "sub-domained" (for example, us.acme.com and eu.acme.com), then mail has to be delivered to a primary point of presence with backup paths. If there are sub-domains, then mail for each sub-domain should be routed to the appropriate local point of presence as a primary and other points of presence for backup.

In the following example, the domain is acme.com, and all mail is delivered to a single point of presence unless there is a failure.

Figure 2. Inbound routing for Scenario B
Inbound routing for Scenario B

The inbound routing flow is as follows:

  1. Mail servers look up acme.com in the DNS and find four available hosts, SMTP1 through SMTP4.
  2. SMTP2 has the lowest MX preference as the preferred inbound mail relay, and mail is routed to SMTP2 (provided it is available).
  3. If SMTP2 is not available, then SMTP1 is the next preferred inbound relay. If this is also unavailable, SMTP4 is the next preferred, then finally SMTP3.
  4. If mail is relayed to SMTP1 or SMTP2, they resolve the smart host entry of inbounda.acme.com and find four possible next hop hosts, HUB1 through HUB4 with HUB1 preferred, followed by HUB2, HUB3, and finally HUB4.
  5. If mail is relayed to SMTP3 or SMTP4, they resolve the smart host entry of inboundb.acme.com and also find four possible next hop hosts, HUB1 through HUB4 with HUB3 preferred, followed by HUB4, HUB1, and finally HUB2.
  6. If the preferred HUB server is available, the SMTP server will relay to it. Otherwise, it uses the alternates in the order of the MX preferences.
  7. After reaching the internal HUB layer, regular Notes mail routing occurs.

The outbound routing follows accordingly.

Figure 3. Outbound routing for Scenario B
Outbound routing for Scenario B

In Figure 3:

  1. HUB1 through HUB4 have mail destined for an external Internet address.
  2. If HUB1 or HUB2 receives the mail, they resolve their relay host entry outbounda.acme.com and find four available hosts, SMTP1 through SMTP4 with SMTP1 as the primary route, followed by SMTP2, SMTP3, and finally SMTP4.
  3. If HUB3 or HUB4 receives mail, they resolve their relay host entry outboundb.acme.com and find four available hosts, SMTP1 through SMTP2 with SMTP3 as the primary route, followed by SMTP4, SMTP1, and finally SMTP2.
  4. If the preferred SMTP server is available, the HUB server relays to it. Otherwise, the HUB server uses the alternates in the order of the MX preferences.
  5. The SMTP server queries DNS for the domain of the recipient (destination.com) and connects to the host depending on the MX records returned.

The basic concepts are similar to Scenario A, just a little more complicated. All servers have more choices as to where to send mail addressed to acme.com in the event of a failure. This provides a very resilient architecture that can cope with failures ranging from an individual server up to the entire site or point of presence.

The other main difference between Scenario A and Scenario B is that the SMTP relay host entries need to be different for each point of presence so that routing to and from each point of presence can be controlled independently. Again, MX preferences can be made equal to balance routing rather than splitting preferred and backup paths.

Using a smart host

A smart host does for inbound mail routing (local domain recipients) what a relay host does for outbound mail routing (external domain recipients). The smart host entry is specific to each server and is configured on a server configuration document. Where a set of servers has the exact same choices for next hop relays, the same smart host entry can be used for multiple servers.

However, as we discussed previously, when you need different routing preferences (or costs) for a set of hosts, you must use multiple smart host entries that each resolve to a unique set of MX preferences. The entry for the smart host relay can be found on the Server Configuration document Router/SMTP Basics tab.

Figure 4. Router/SMTP Basics tab
Router/SMTP Basics tab

In addition to specifying the Local Internet domain smart host value, you must enable the option "Smart host is used for all local Internet domain recipients" to indicate that the server should relay all local mail to the smart host. If not, the Domino server will only relay mail for recipients it cannot find in all available directories. If address verification is being done using an Extended Directory Catalog (as described later in this article), then the only messages accepted must have an entry in the directory. You want Domino to relay these messages to the smart host, which it would not do without this setting enabled.


Configuration examples using a DMZ

In this section, we present two examples of setting up Domino servers with DMZ: Domino servers without directories containing user information and Domino servers with user directory information.

Domino servers without user directory information

In this case, the Domino servers are configured to act as relays and cannot do any email address verification because they do not have access to any user directory information. As stated previously, you do not want a replica of the internal production domain directory in the DMZ. The following diagram illustrates this configuration.

Figure 5. Domino servers without user directory information
Domino servers without user directory information

The Domino Directory on the Domino SMTP servers will not contain any user information over and above what may be required for authentication of administrators. No information from the internal Domino Directory is published in the DMZ.

Domino servers with user directory information

It is usually desirable to perform some kind of address verification of incoming mail to ensure that spam mail (which is often addressed to randomly generated email addresses) is blocked at the earliest point. Only mail to legitimate internal recipients should be passed along. To do this, the Domino SMTP servers must have a directory against which they can compare addresses for validation to distinguish those that are legitimate and to reject others that are not.

Once again, security of information is a high priority. If you don’t want to replicate the internal Domino Directory onto these servers, then which directory can they use for the address verification? In this case, the Extended Directory Catalog (EDC) is a simple and effective solution. Using an EDC provides the following benefits:

  • Control over which information is extracted from the internal directory and published in the EDC.
  • A built-in mechanism to create and maintain the directory, the Directory Cataloger task.
  • Replication is a robust and easily implemented distribution mechanism.

So how would this differ from using Domino servers without user directory information? Figure 6 shows the architecture.

Figure 6. Domino servers with user directory information
Domino servers with user directory information

The Directory Cataloger task is responsible for maintaining the EDC on a server that is in the internal domain and has access to the source directories from which user information needs to be aggregated. However, not all internal directory information is aggregated into the EDC.

To create an EDC, create a new database based on the standard Domino Directory template. (We call our example database smtpedc.nsf.) This is different from creating a mobile directory catalog, which is compressed and requires full-text indexing for lookup performance. The EDC contains all the views typically associated with the standard Domino Directory against which lookups can be performed.

After you create this database, set a very restricted ACL. This table shows examples of the required ACL entries:

ACL Entry NameAccess LevelAdditional Roles
- Default -No AccessNone
AnonymousNo AccessNone
AcmeAdministratorsManagerDelete documents
*/SERVERS/SMTPManagerDelete documents
HUB1/SERVERS/ACMEManagerAdministration server
Delete documents

NOTE: */SERVERS/SMTP is required if the servers in the DMZ replicate the EDC with each other.

Last, you need to create an EDC configuration document.

Figure 7. Creating an EDC configuration document
Creating an EDC configuration document

On the Basics tab, in the "Additional fields to include" option, select InternetAddress. (This is what the server will compare against incoming recipient names.) In the "Restrict aggregation to server" field, specify the server responsible for the aggregation and reports of the processing that should be sent to administrators to monitor problems.

Figure 8. Extended Directory Catalog Basics tab
Extended Directory Catalog Basics tab

On the Advanced tab, you can enter a selective replication formula to restrict source content even further. In this case, we only want to aggregate user, group, and mail-in database entries that contain a valid Internet address value. This can be used as a control to allow Internet mail reception only for a subset of these entities.

Figure 9. Extended Directory Catalog Advanced tab
Extended Directory Catalog Advanced tab

The formula can be further enhanced to use the “Allow foreign directory synchronization” flag that appears on directory entries as another way to control which entries are aggregated.

In the Server document of the designated aggregation server, your EDC must be listed as a catalog to be processed along with an aggregation schedule. To do this, enter its filename into the Directory Catalog filenames field.

Figure 10. Directory Catalog filenames
Directory Catalog filenames

Then you can replicate the EDC to the DMZ on a scheduled basis to keep this information current. One point to note here is that the directory catalog aggregation schedule and replication schedule together determine how long it will take for new users to be recognized as valid recipients.

The Domino SMTP gateways now must be able to reference this secondary directory. A simple Directory Assistance setup is required to enable this. Create a Directory Assistance database on one server in the DMZ. In our example, we call this dmzda.nsf. This database, once configured, should be replicated to each SMTP server.

In the Directory Assistance database, create an entry to point to the EDC. On the Basics tab, enter a descriptive domain name and ensure the entry is enabled.

Figure 11. Directory Assistance Basics tab
Directory Assistance Basics tab

In the Replicas tab, enter an asterisk (*) in the server name field that allows the server to reference any available replica. Then enter the EDC database name and ensure it is enabled here too.

Figure 12. Directory Assistance Replicas tab
Directory Assistance Replicas tab

In the Server document of each Domino SMTP server, add the Directory Assistance database name to the appropriate field.

After you update the Server documents, restart the servers for the change to take effect. To validate that the directory is being referenced after the server restart, enter SHOW XDIR at the server console. You should see output similar to the following.

Figure 13. SHOW XDIR output
SHOW XDIR output

After you configure the EDC and Directory Assistance, you can enable address verification. To do this, in the SMTP Server Configuration documents, go to the Router/SMTP Basics tab and set the address lookup to Fullname only. This forces the server to use the full Internet email address for lookups and prevents it from splitting off the local part and doing local part name matching. Then on the Router/SMTP -- Restrictions and Controls -- SMTP Inbound Controls tab, set the option to verify local domain recipients to enabled.

The Domino SMTP servers will now perform address verification against the EDC you have created and configured. Test the servers by sending email to them using combinations of known good and invalid recipient addresses and watch the server console as the bad ones are rejected for policy reasons. Those that are valid should be routed to the internal domain.


Your choices

This article series has discussed several scenarios for how to configure and set up a secure Domino-based SMTP service. As you have seen, there are many different components that are available for you to use. These include:

  • An isolated trusted corporate network
  • A DMZ to isolate your trusted network away from the untrusted Internet
  • A world-class SMTP service via Lotus Domino
  • Advanced Domino SMTP security features, including relay and spam prevention and DNS blacklisting
  • Various DMZ configurations
  • DNS settings via MX records
  • Notes Named Networks
  • Disaster recovery configurations

You can mix and match these choices to build the SMTP architecture that meets your business needs.

Today SMTP is the email of choice. However, most end users may not know and/or care about this fact. Therefore, it is up to you to build a secure and effective solution. Lotus Domino provides the tools and features that allow you to do this.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into IBM collaboration and social software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Lotus, Security
ArticleID=31750
ArticleTitle=Using Notes/Domino SMTP with a DMZ
publish-date=11152004