Thứ Sáu, 22 tháng 3, 2013

What is Lotus Sametime?

IBM® Lotus® Sametime® consists of client and server applications that enable a community of users to collaborate through instant messaging and online meetings over an intranet or the Internet. Lotus Sametime Entry is an offering targeted at helping organizations get started with instant messaging.
Members of the Lotus Sametime community use collaborative activities such as awareness, chat, screen sharing, and real-time audio/video capabilities to work together.
Awareness – Lotus Sametime awareness technology lets members who have logged in to Lotus Sametime to see all other members who are logged in. The names of online users display in "awareness lists" in Lotus Sametime applications. From these awareness lists, members of the community can chat through instant messaging sessions or start meetings that include chat, screen-sharing, polls, the ability to send Web pages to other users, and audio/video capabilities.
Meeting rooms – While awareness lists support instant collaboration with other online users, the Lotus Sametime Meeting Room Center provides a central meeting place for members of the community. In the Meeting Room Center, users can create meeting rooms and use them whenever they want to meet with their colleagues. Users access the Lotus Sametime Meeting Room Center with Web browsers or from the Meetings panel in the Lotus Sametime Connect client.
Instant messaging – The Lotus Sametime client is a Java™ application that uses the Eclipse-based IBM Lotus Expeditor. The Lotus Sametime client leverages the Eclipse plug-in framework to provide developers with extensibility features that go far beyond those available in previous Lotus Sametime releases. Partners, independent software vendors (ISVs), customers, and internal developers use these features to integrate with the Lotus Sametime client to extend its capabilities.
Instant meetings – Instant meetings are meetings that Lotus Sametime Connect users can create on the fly, and are perfect for quick meetings when you don't need to save the meeting room, its content, and related information.
Voice chat – The Lotus Sametime client allows users to talk to other Lotus Sametime users through their computer's audio features and Voice-over-IP (VoIP) technology. VoIP is becoming increasingly popular, since it allows users anywhere in the world to talk inexpensively. Voice-over-IP allows users to click the microphone icon to call another user for instant voice chats over the intranet.
Telephony– Voice chat is one of two telephony capabilities in the Lotus Sametime IM client. The other is click-to-call (also called click-to-dial), which allows a user to instantly create a telephone conference with one or more other users. In both cases, a user invites other users in a chat window or on the buddy list to join a call, and the invitees are given the opportunity to either join or decline. Those users who choose to join can connect to the call by clicking an icon. If voice chat is used to initiate the call, all connected parties communicate using their computer's microphone and speakers. If click-to-call is used, a third-party telephony service calls each user at the appropriate number.
Video chat – Users who are equipped with video components can see each other on their screens during a chat.
Location awareness – Lotus Sametime includes location awareness of the user, and an extensible resource area at the bottom of the left pane that can be customized to reflect different locations.
Connect to public IM networks – Lotus Sametime provides for connectivity to outside instant messaging providers such as AOL's AIM, Yahoo! Messenger, Microsoft® Office Communications Server, and Google Talk communities through IBM's Lotus Sametime Gateway. Through the gateway, users can share presence information and can participate in text-based IM conversations.
Contact information – The Business Card features provides the user with telephone number, e-mail address, photo, name, title, and location displayed in the Business Card hover-over feature and in the chat window. Business cards can be provided by the Lotus Sametime Community Server or a Lotus Connections server.
Emoticons – Lotus Sametime includes emotionally-expressive icons such as smiley faces.
Customizing – Your company name can be added to the Instant Messaging window.
File transfer – Users can send files.
Quick find – Users can start typing name in the Quick Find box to find a person they want to chat with, and then click the name to initiate a chat.
Time stamp – The time of day is provided in the Chat window along side the text.
Polling– A user can poll members of a group to provide brief feedback to questions.
Policy– Users can be assigned access to different features in Instant Messaging, such as voice chat, creating meetings, transferring files, IP telephony. Policy settings govern their access.
The two primary Lotus Sametime client applications are the Lotus Sametime Connect client and the Lotus Sametime Meeting Room. The Lotus Sametime Connect client contains a presence list that displays selected members of the community who are online. FromLotus Sametime Connect, a user can collaborate by sending instant messages or by starting an instant meeting with any other online member of the community.
The Lotus Sametime Meeting Room runs in a user's Web browser whenever the user attends a meeting. The Lotus Sametime Meeting Room contains components that support the full range of Lotus Sametime collaborative activities, including interactive audio and video.
Lotus Sametime Standard and Lotus Sametime Entry
Lotus Sametime Standard is the full Lotus Sametime product offering, Lotus Sametime Standard provides awareness, instant messaging, and meeting room functionality.
Lotus Sametime Entry is a limited offering, providing a core set of awareness and instant messaging capabilities either from stand-alone Lotus Sametime clients or from within Lotus Notes®. Lotus Sametime Entry does not support meeting rooms. In addition, Lotus Sametime Entry is sometimes packaged with other IBM products.
You can expand your real-time collaboration capabilities in Lotus Sametime Entry by purchasing the Lotus Sametime Standard server to add meeting room capabilities and a richer instant messaging client to your environment.
The following table compares the features of Lotus Sametime Entry and Lotus Sametime Standard.
Capability Available with Lotus Sametime Entry Available with Lotus Sametime Standard
Presence yes yes
Instant Messaging chat yes yes
N-way (group) chat yes yes
Sort contact list yes yes
Show short names yes yes
Show those online only yes yes
Time stamps on chats yes yes
Chat history yes yes
Rich text yes yes
Emoticons yes yes
Emoticon palettes yes yes
Business card display yes yes
Contact type ahead yes yes
Spell check in chat yes yes
Standalone Sametime Connect client yes yes
Microsoft Office integration yes yes
Meeting rooms and instant meetings no yes
Sametime toolkits no yes
Sametime gateway (to public IM) no yes
Sametime mobile access no yes
Selective 'who can see me' no yes
Alerts setting no yes
File transfer no yes
Telephony (with 3rd party) no yes
Voice chat no yes
Video chat (native point-to-point) no yes
Multiple communities no yes
Geographic locating no yes
Screen capture tool no yes
Selective do-not-disturb status no yes
Lotus Sametime plug-ins no yes

Controlling spam: Advanced SMTP settings in Lotus Domino (Part 2)

In the ongoing battle to control unwanted and unsolicited emails, corporations are spending millions, even billions, of dollars for technology to prevent spam mail from infiltrating their users' inboxes. While spam mail may no be preventable, Lotus Notes and Domino has been implementing measures that assist organizations in controlling it. In part one of this article series, we discussed the Configuration Settings document, server mail rules, and inbound SMTP commands and extensions. Each of these measures can help you to prevent unwanted email from reaching your users. In the final part of this series, we look at settings in the Server document and at Domino server Notes.ini variables that affect SMTP and the mail router. Last, we look ahead at Lotus Notes/Domino 7 anti-spam features, such as whitelists, server mail rule enhancements, and more.
This article series is intended for experienced Domino administrators. If you have not already, read part one of this series.
Server document
In the previous article, we covered the Configuration Settings document inbound relay controls, DNS blacklist filters, and other SMTP controls. But the Configuration Settings document isn't the only document to help you control spam mail. The Server document SSL settings can also help.
SMTP sessions conducted over a standard TCP/IP channel are vulnerable to eavesdropping because the uuencoded transmission can be easily intercepted. To protect SMTP communications, servers can use transport-layer security (TLS), more commonly known as SSL encryption, to provide privacy and authentication. Enabling SSL is done through the Server document Ports - Internet Ports - Mail tab as shown in Figure 1.

Figure 1. Enabling SSL for SMTP Inbound
Enabling SSL for SMTP Inbound
Some servers support SSL for SMTP communications by sending and receiving SMTP traffic through the SSL port (port 465 by default) only. However, because this requires that both the sending and receiving servers support SMTP over SSL, this solution isn't always practical.
To provide SSL security for SMTP transfers over TCP/IP, Lotus Domino supports the use of negotiated SSL. In a negotiated SSL scheme, the sending and receiving hosts each use the SMTP STARTTLS extension, defined in RFC 2487 and RFC 3207, to signal their readiness to negotiate an SSL connection. The receiving server displays the STARTTLS keyword in response to the sending server's EHLO command. The sending server issues the STARTTLS command to request the creation of a secure connection. After the initial TLS handshake completes successfully, the two parties proceed to set up an SSL channel between them. Both the sending and receiving server must possess SSL certificates.
Above the SSL port information is also a setting called the "Enforce server access settings" field. When this field is enabled, access to the SMTP listener is controlled by the server access settings on the Security tab of the Server document. Users and servers that are not allowed to access the server cannot send mail to the SMTP port. For this option to be effective, you must enable authentication for the port.
Notes.ini variables
Along with configuring SMTP through a Notes GUI, some SMTP settings can be applied through server Notes.ini variables. The following section lists some Notes.ini variables that you can use to help prevent spam mail and to configure SMTP and Router restrictions. All the Notes.ini settings listed in this article apply to the Domino server only.
This variable lets you define whether or not the SMTP task requires addresses that appear in MAIL FROM commands or RCPT TO commands must conform to the 821 standard (must contain <>). Set this to 1 to enforce the 821 standard; the default setting of 0 does not enforce the standard.
This variable lets you compose the text message that is sent to SMTP clients when they connect to the SMTP server. You must include the string "%s" within the message. (This string is replaced with the current date/time when the connection is made.) By default, the SMTPGreeting is "host-name ESMTP Service (Lotus Domino build-name) ready at %s".
If you set this variable to 1, the SMTP task requires all protocol text be terminated by carriage return and line feed (CRLF) as defined by the 821 standard. If you set this variable to 0 (the default setting), the 821 standard is not enforced, and line feed (LF) is accepted as a line terminator.
The SMTP listener task conforms to RFC 2821, requiring a carriage return and a line feed. You can change this functionality with the SMTPNonStandardLineTermination variable. If you set the variable to 0, the SMTP listener task requires a carriage return and line feed (CRLF). If you set it to 1, the SMTP listener task requires a carriage return (CR) or a line feed (LF).
This variable forces SMTP to bind to a specific TCP/IP port other than the first port listed in the PORTs variable of the server's Notes.ini file, which is the default behavior. You may want to use this variable with a server that has multiple network interface cards.
This variable allows you to define how frequently (in minutes) Domino checks the Configuration Settings document for updates. The default value is 2.
This determines how the SMTP task handles connections if authentication is required and populates the hosts in the "Allow connections only from the following SMTP internet hostnames/IP addresses" field. If you specify 0, the SMTP task requires authentication, and hosts in the "Allow connections only from the following SMTP internet hostnames/IP addresses" field are denied. If you specify 1, the SMTP task requires authentication, and hosts in the "Allow connections only from the following SMTP internet hostnames/IP addresses" field are exceptions that are allowed to connect.
Each SMTP protocol exchange has a timeout wait value. If a client doesn't respond within this period, the connection terminates. You can increase the timeout period by defining a multiplier value with the SMTPTimeoutMultiplier variable. For example, if you set this to 5, all timeout periods are increased by a factor of 5. The default is 1.
This variable lets you determine whether or not the Router returns delivery status notifications (DSNs) for messages received over SMTP with null RFC 821 reverse paths. By default, this is set to 0, which tells the Router not to return a failed DSN. In this case, the Router creates the nondelivery report, but marks it as DEAD. (You can later delete or release these messages.) If you set this variable to 1, the Router creates and sends the delivery status notification. In addition, if you set this variable to 2, the Router does not create a delivery status notification.
This variable lets you set the default timeout (in seconds) for SMTP Inbound Sender Control in the "Verify Sender's Domain in DNS" field. By default the timeout value is 30 seconds.
This variable tells SMTP to drop a connection when the error count for that connection exceeds an administrator-defined number of errors. If SMTP sessions are opened by clients that fail to acknowledge a close command, this variable lets the session terminate. The default depends on available resources and the number of SMTP connections.
The Router generates SMTP DSN Relay reports when it is unable to forward delivery confirmation requests to the next SMTP hop, including when the current Router has outbound DSN disabled in the Configuration Settings document. To disable SMTP DSN Relay reports, set the variable to 1. The default is 0, letting the Router send a relay report if outbound DSN has been disabled.
This variable determines whether the Router allows or denies mail addressed to a group. The default value of 0 allows the Router to expand groups and forward email to group members. To keep the Router from expanding groups, set this variable to 1. The Router returns the message as a failure report to the sender, stating that the message was rejected for policy reasons.
This variable determines whether or not SMTP uses directory catalog lookups. This prevents users listed in the directory from receiving inbound Internet mail on this server. The default value of 0 enables the Router to use any of the Extended Directory Catalogs referenced in its configuration. If you set this variable to 1, the Router cannot use any of the Extended Directory Catalogs referenced in its configuration when doing lookups for inbound Internet mail.
This variable sets the maximum number of characters the SMTP task accepts. The default is 1,200 characters.
This variable determines how many addresses can be added when the SMTP task adds received headers to messages received. The default is based on available resources.
This variable specifies the number of allowed inbound SMTP connections. After this value has been reached, Domino returns an error 421 message. The default value is based on available resources.
This variable lets you determine if mail sent during an authenticated SMTP session is issued from that user's Internet address. The default value of 0 instructs Domino not to check the Internet address of authenticated SMTP sessions. If you set this variable to 1, Domino determines if mail sent during an authenticated SMTP session is issued from that user's Internet address.
This variable disables group expansion when Smarthost is enabled for all recipients in the local Internet domain. If you set it to 0, group expansion occurs when Smarthost is enabled for all local Internet domain recipients. If you set the value to 1, it disables group expansion when Smarthost is enabled for all local Internet domain recipients. The default is 0.
When you set this variable to 1, it prevents Domino server product information from being disclosed in the SMTP Received headers. The default is 0.
This variable can control the number of recipients during the SMTP protocol RCPT TO command. After that value has been reached, Domino will issue an error 552 message. The default is based on available resources.
When messages are received through SMTP by the SMTP task, no change is made to any of the addresses. Some sites may prefer to have the Internet addresses of the local Notes users converted to Notes addresses (hierarchical). To convert the addresses, set this variable to one of the following values: 0 - (default) No translation; 1 - Translate only the from item; or 2 - Translate all address items.
If you have the previous variable SMTPTranslateAddresses set to either 1 or 2, you can use this variable to override the Configuration Setting document for Address lookup. To override the Configuration Setting document, set SMTPTranslateLookupFullThenLocal to 1. When you do, Lotus Domino translates the full name then local part. The default is 0.
If you have the variable SMTPTranslateAddresses set to either 1 or 2, you can use this variable to perform a lookup even if the address doesn't appear to be a local address. Set SMTPTranslateAddressLookup to 1 to enable it to perform an address lookup. The default is 0.
This variable preserves the original Internet address in Inetxxx items. Lotus Notes/Domino 6.5.2 and later maintain Inet items in the RFC821 form, which is the preferred form for Inet items. Set this variable to 1 to revert to previous behavior and to preserve any RFC822 addresses translated in the Inetxxx items.
If you set this variable to 1, entries in the Deny fields of the SMTP inbound relay controls take precedence over entries in the Allow fields in the event of a conflict. The default is 0.
When set to 1, SMTP_RIGHT_DOT_NEVER_NOTESDOMAIN corrects a problem when addressing messages to, where hostname notes matches the Notes domain name. It prevents the router from attempting to delivery the message locally.
This variable causes the RFC821 reverse path MAIL FROM command to be based on the value in the From field when set to 1. The default is 0.
If you have language packs installed, you can use this variable to enable translation of non-delivery messages. Set this value to 1 to enable this feature. Lotus Domino will translate certain English messages returned in NDRs by the router.
Preview of Lotus Domino 7
This section describes some new features that are in Lotus Domino 7. The features described below reflect the ones available in the Beta 2 release of Lotus Notes and Domino 7. However, these features may not appear in the final release of these products. Also, the user interface for these features is subject to change, so the illustrations in this article may not exactly match what appears on your screen.
DNS whitelist filters
Lotus Domino 7 has extended its spam control to include DNS whitelist filters. Whitelists allow messages from specified domains to be received. IBM supports both private blacklist and whitelist filters. With these new configuration settings, it is important to understand how you can reduce spam and to know the order that Domino will check when blacklist and whitelist filters are enabled.
If you enable private whitelist filters, when Domino receives an SMTP connection, it compares the IP address/host name against this list. The field "Whitelist the following hosts" should be used to enter the IP addresses or host names of systems that you want to whitelist. You can also use an asterisk (*) as a wild card. Members of the private whitelist are still subjected to connection, relay, sender, and recipient controls. Being whitelisted does not guarantee that the message will be delivered to the recipient.

Figure 2. Private Whitelist Filters
Private Whitelist Filters
You can also set the "Desired action when a connecting host is found in the private whitelist" field. You can choose to skip all the blacklist filters to avoid any excess lookups. When this action is configured, Domino does not record any additional logging. Prior to the introduction of private whitelist filters, to exclude a host from blacklist filter processing, you had to define the client's mail server as a relay exception.
Another option is to log the connecting IP address/host name that was found in the private whitelist. The last option is to log and tag the message. Tagging the message adds the note $DNSWLSite to the message, which can be used to further filter the message.
If the connecting host was not listed in the private whitelist, Domino searches private blacklist filters if enabled. Domino compares the IP address/host name with this list. You also have the option to log the message or log and tag the message with the note $DNSBLSite. There is a third option to log and reject the message. When configured, if Domino finds that a connecting host is on the private blacklist, it rejects the connection and returns a custom SMTP error message to the host.

Figure 3. Private Blacklist Filter
Private Blacklist Filter
After Domino has checked the private filters, it compares the IP address against DNS filters. Administrators should use DNS whitelist filters as a means to help identify legitimate email. The Bonded Sender Program proposed by IronPort Systems allows originators of legitimate email to post a financial bond to ensure the integrity of their email campaign. Recipients who feel that they have received an unsolicited email from a bonded sender can complain to their ISP, enterprise, or IronPort, and a financial charge is debited from the bond. This market-based mechanism allows email senders to ensure their message gets to their end user and provides corporate IT managers and ISPs with an objective way to ensure only unwanted messages get blocked. The Bonded Sender Program operates as a DNS whitelist. There are other programs similar to the Bonded Sender Program that are outside the scope of this article. You can search the Web for additional programs.
If DNS whitelist filters are enabled, as shown in Figure 4, Domino compares the IP address/host name with the DNS whitelist sites listed. You can also specify the action when a connecting host is found in the DNS whitelist. You can choose to skip all the blacklist filters to avoid any excess lookups. When this action is configured, Domino does not record any additional logging.

Figure 4. DNS Whitelist Filters
DNS Whitelist Filters
You also have the option to log the connecting IP address/host name that was found in the private whitelist. The last option is to log and tag the message. Tagging the message adds the note $DNSWLSite to the message which can be used to further filter the message.

Figure 5. Document properties for $DNSWLSite
Document properties for $DNSWLSite
The SMTP task maintains statistics to keep a cumulative count of the total number of hits (SMTP.DNSWL.TotalHits) as well as per-whitelist site hits (SMTP.DNSWL.<WhitelistSite>.Hits). The statistics are part of the SMTP stat package and can be viewed through either the Domino Administrator client or server console via the show stat SMTP command. You can further expand the statistics to learn the number of times a given IP address is found in one of the configured DNSWLs (SMTP.DNSWL.<WhitelistSite>.[IP address].Hits). To collect the expanded information, enable the Notes.ini variable:
Use this setting to generate DNS and private whitelist filter statistics for each connecting host found in a DNS or private blacklist site. If you set this variable to 0, the SMTP server does not generate host specific DNS/private blacklist filter statistics. If you set this variable to 1, the SMTP server generates host specific DNS/private blacklist filter statistics that indicate the total number of hits per DNSWL site, per connecting host's IP address.
In the absence of this setting, the SMTP task maintains statistics that track the total number of connecting hosts that were found on the combined DNSBL of all sites combined, as well as how many were found on the DNSBL of each configured site.
Server mail rules enhancements
Lotus Domino 7 has also made some new enhancements for configuring server mail rules. IBM has added two new conditions to search for to identify specific mail messages. Lotus Domino 7 has the ability to filter mail based on blacklist tags and whitelist tags. When a connecting host is found in a blacklist or whitelist, there is an option to tag the messages. Now you can quarantine messages that have a blacklist tag or journal messages that have a whitelist tag.
A new action has also been added for configuring server mail rules. You can specify an action of stop processing. The stop processing action stops the processing of all rules that follow the rule containing the stop processing action. You can use the stop processing action alone--that is, as the only action in a server mail rule--or you can use it with another action in a rule. This is especially useful when more than one rule could apply to a message, but you want execution of mail rules to stop after the first action is executed.
Support for IPv6 for SMTP
Lotus Domino 7 supports IPv6 for SMTP. Support for IPv6 by hardware and operating system suppliers and the Internet is still in the early stages. Moving to the IPv6 standard is a gradual process for most organizations. IPv6 is an emerging standard. Vendors who have implemented (or are implementing) IPv6 have done so in varied ways. How you enable and configure IPv6 in your enterprise depends on the client and server platforms you are using. To enable IPv6, add this setting to the server's Notes.ini file:
You can enable support for IPv6 on a Domino server that runs the IMAP, POP3, SMTP, LDAP, or HTTP service. If you set this variable to 0, Domino uses the IPv4 standard. Set the variable to 1 to enable Domino to use the IPv6 standard. By default, this setting is set to 0.
Even if you enable IPv6 in Lotus Domino, it can continue to connect to IP addresses that use the IPv4 standard. AAAA records store IPv6 addresses in DNS. After you enable IPv6 on a Domino server and add the server's AAAA record to DNS, another IPv6-enabled Domino server can connect to it only over IPv6. Servers that don't support IPv6 can run Lotus Domino with IPv6 support disabled, which is the default. These servers can successfully connect to IPv6-enabled Domino servers only if the DNS for the IPv6 servers contain A records.
Domino Domain Monitoring
Domino Domain Monitoring (DDM), new in Lotus Domino 7, lets you view the status of multiple servers across more than one domain. DDM uses probes that you configure to monitor server activity. One of those probes is a mail probe that monitors local mail routing. It sends a message to a known destination and verifies its delivery. If too much mail is pending or if mail fails to reach its destination, DDM can send you an alert. You can also use an SMTP probe to verify mail delivery to an SMTP recipient. DDM can issue a delivery status notification report. The Event Resolution Center database (Ddm.nsf) consolidates information gathered by the probes in a single repository.
For more information about Domino Domain Monitoring and other new features in Lotus Notes/Domino 7, see the developerWorks: Lotus article, "New features in Notes/Domino 7."
New Notes.ini variables
Lotus Domino 7 is also introducing some new Notes.ini variable to help prevent spam.
This variable requires that you have the option "Verify that local domain recipient exist in the Domino Directory" enabled. If you set this variable to 1, all external hosts receive a permanent error after the RCPT TO command when mail is addressed to a group. If you set this to 2, all connecting hosts receive a permanent error after the RCPT TO command when mail is addressed to a group. The default value is 0.
This variable requires that you have the option "Verify that local domain recipient exist in the Domino Directory" enabled. If you set this variable to 1, the SMTP task will not except any recipient name that is not unique. The default is 0.
What's coming
IBM research is also working on additional anti-spam technologies that are not in the current releases of Lotus Domino. One such technology framework known as SpamGuru allows one or more of these technologies to be combined to filter mail. One of the technologies being developed in this framework is a Bayesian spam filter. Bayesian filters use a statistical method to determine if a particular message is spam or not. By comparing features of a message with a corpus of previous good and spam messages, the probability of a message being spam is calculated and represented by a "score" that can be used to potentially alter the disposition of the message.
Bayesian filters continue to learn about new spam through a training process. The corpus of good/spam messages can continuously be updated to affect future calculations. This learning is accomplished by allowing users (mail recipients) to provide input to the system by "voting" a particular message as either good or spam. The number of votes for messages with a particular feature is considered during future calculations, allowing the filter to dynamically adapt to new spam content and the users' definition of spam.
See "SpamGuru: An Enterprise Anti-Spam Filtering System" for an overview of the SpamGuru architecture and how Lotus Domino can become an adaptive spam filter. Additional reading material can also be found at IBM Research.
NOTE: Currently IBM has no scheduled timeline for integrating SpamGuru technologies and Lotus Notes and Domino.

Controlling spam: Advanced SMTP settings in Lotus Domino (Part 1)

In the ever-changing world of technology, the amount of spam mail is increasing faster than most email systems can handle or control. In 2004, almost nine billion dollars will be spent by all U.S. corporations to fight spam. Companies have dedicated products to identify and quarantine possible spam messages. Recent surveys have shown that over 40% of all email is considered spam with an average of six messages a day per email user. If you think that's bad, the estimated spam increase by 2007 is 63%. These statistics and more can be found at the Spam Filter Review Web site.
Starting in Lotus Domino 4, Lotus has been building ways to prevent spam email and to restrict Simple Mail Transfer Protocol (SMTP) messages. Lotus Domino 4 introduced multiple Notes.ini parameters to control relaying, inbound connections, and senders’ domains. Lotus Domino 5 introduced a Graphical User Interface (GUI) in which Domino administrators could list values within fields in the Configuration Settings Document. This made SMTP configurations easier for a Domino administrator and took some of the burden off Notes users.
Lotus Domino 6 has taken great steps to develop technology to integrate messaging with DNS blacklist (DNSBL) filtering and content filtering. This article series explores the multiple solutions that IBM has created to limit the amount of unsolicited email from the server as well as preview the spam controls in Lotus Domino 7. In part one of this series, we look at settings in the Configuration Server document and server mail rules to help control spam. In part two, we discuss settings in the Server document and Notes.ini variables that control spam. We'll also take a sneak peek at enhancements in Lotus Notes/Domino 7. This article series assumes that you are an experienced Domino administrator familiar with Lotus Notes and Domino 6.
SMTP settings in Domino
Most Notes users would prefer that their administrator prevent spam email instead of having to delete and filter out unwanted email themselves. The most effective way to prevent spam is to stop the message from getting into your environment. This entails configuring SMTP and Router settings. You can configure both in the Configuration Settings document, Server document, and Domino server Notes.ini file.
The SMTP task controls the SMTP listener on the Domino server. By default, whenever you restart the SMTP service, and at two-minute intervals thereafter, the SMTP service automatically checks the Notes.ini file, Configuration Settings document, and Server document to see if any settings have changed. If the service detects that settings have changed, it rebuilds its internal configuration to incorporate the changes.
Configuration Settings document
The most effective place to control SMTP traffic is through the Configuration Settings document. The Configuration Settings document has several tabs that allow you to filter SMTP email, therefore reducing the amount of spam. On the Configuration Settings document Router/SMTP - Restrictions and Controls - SMTP Inbound Controls tab, there are six additional sections to configure the SMTP protocol.
Inbound relay controls
This section allows you to populate Internet domains to which Domino will allow or deny relaying messages as shown in Figure 1. Not configuring your Domino server for relay settings can result in being blacklisted and unable to send outbound SMTP messages to domains that use blacklist services.
In the Deny fields, an asterisk (*) prevents Domino from relaying messages to an external Internet domain from any external Internet hosts or IP addresses. You can also use an asterisk (*) to represent a subnet of an IP address. Any IP address or host listed in the "Allow messages to be sent only to the following external internet domains" field takes precedence over the "Deny messages to be sent to the following external internet domains" field.

Figure 1. SMTP Inbound Relay Controls
SMTP Inbound Relay Controls
Any value in the "Allow messages only from the following internet hosts to be sent to external internet domains" field will take precedence over the "Deny messages from the following internet hosts to be sent to external internet domains" field. In previous releases of Domino, entries in the Deny fields of the inbound relay controls take precedence over those in the Allow fields when a conflict exists.
If you want to convert back to the algorithm that release 5 uses, you need to configure the Notes.ini variable SMTPRelayHostsandDomains=value. The default value is 0. This variable forces servers to abide by Domino 5 rules to resolve conflicts between Allow and Deny list entries in the SMTP inbound relay controls.
  • 0 - Entries in the Allow field of the SMTP inbound relay controls take precedence over entries in the Deny fields when there is a conflict between them. For example, given the following entries the host can always relay to any destination, including destinations in the domain
    Deny messages to be sent to the following external internet
    Allow messages only from the following internet hosts to be sent to external internet
  • 1 - Entries in the Deny fields of the SMTP inbound relay controls take precedence over entries in the Allow fields in the event of a conflict. Using the preceding example, if you deny relays to, the host cannot relay to the denied domain.
Inbound relay enforcement
This section discusses advanced settings for relay controls. The following three fields specify additional SMTP relay settings shown in Figure 2.

Figure 2. SMTP Inbound Relay Enforcement
SMTP Inbound Relay Enforcement
Perform Anti-Relay enforcement for these connecting hosts
This field specifies the connections for which the server enforces the inbound relay controls defined in the SMTP inbound relay controls shown in Figure 1. You need to choose one of the following settings:
  • External hosts (default): The server applies the inbound relay controls only to hosts that connect to it from outside the local Internet domain. Hosts in the local Internet domain are exempt from anti-relay restrictions. The local Internet domain is defined by either a Global Domain document, if one exists, or as the Internet domain of the host server.
  • All connecting hosts: The server applies the inbound relay controls to all hosts attempting to relay mail to external Internet domains.
  • None: The server ignores the settings in the inbound relay controls. All hosts can always relay.
Exclude these connecting hosts from anti-relay checks
You can create an exceptions list containing the IP addresses or host names of systems that relay to any permitted domain. For each specified exception, the inbound relay controls are not enforced. Enter the IP addresses or host names of hosts to be exempted from the restrictions specified in the inbound relay controls section in Figure 1. When entering an IP address, enclose it within square brackets.
Exceptions for authenticated users
This field can be used to specify whether or not users who supply login credentials when connecting to the server are exempt from enforcement of the inbound relay controls. You must choose one of the following:
  • Perform anti-relay checks for authenticated users: The server does not allow exceptions for authenticated users. Authenticated users are subject to the same enforcement as non-authenticated users.
  • Allow all authenticated users to relay: Users who log in with a valid name and password are exempt from the applicable inbound relay controls. Use this to enable relaying by POP3 or IMAP users who connect to the network from ISP accounts outside the local Internet domain.
DNS blacklist filters
This section controls whether or not to use DNS blacklist filters as shown in Figure 3. If enabled, when Domino receives an SMTP connection request, it checks whether or not the connecting host is listed in the blacklist at the specified sites. If a connecting host is found on the list, Domino reports the event in a console message and in an entry to the Mail Routing Events view of the Notes Log. Both the console message and log entry provide the host name and IP address of the server as well as the name of the site where the server was listed. If Domino finds a match for a connecting host in one of the blacklists, it does not continue checking the lists for the other configured sites.

Figure 3. DNS Blacklist Filters
DNS Blacklist Filters
You can choose from a number of publicly available and private paid subscription services that maintain DNS blacklists. When using a public blacklist service, Domino performs DNS queries over the Internet. In some cases, it may take a significant amount of time to resolve DNS queries submitted to an Internet site. If the network latency of DNS queries made over the Internet results in slowed performance, consider contracting with a private service that allows zone transfer, so that Domino can perform the required DNS lookups to a local host. During a zone transfer, the contents of the DNS zone file at the service provider are copied to a DNS server in the local network.
Each blacklist service uses its own criteria for adding servers to its list. Blacklist sites use automated tests and other methods to confirm whether a suspected server is sending out spam or acting as an open relay. The more restrictive blacklist sites add servers to their list as soon as they fail the automated tests and regardless of whether or not the server is verified as a source of spam. Other less restrictive sites list a server only if its administrator fails to close the server to third-party relaying after a specified grace period or if the server plays host to known spammers.
You can enter the text of the error message returned when denying a connection because it found the host in the DNS blacklist. The default error message indicates that the connection was denied for policy reasons. You can use the format specifier %s to specify the IP address of the denied host and the DNS blacklist site where Domino found the host listed.
For example, suppose you enter the following:
Your host %s was found in the DNS Blacklist at %s
When Domino denies a connection, it returns an error to the host in which it replaces the first %s with the IP address of the host and the second %s with the DNS blacklist site name. Thus, if you entered the text in the preceding example, a denied host receives an error such as:
Your host was found in the DNS Blacklist at
Desired action when a connecting host is found in a DNS blacklist
You must choose one of the following DNS blacklist settings:
  • Log: When Domino finds that a connecting host is on the blacklist, it accepts messages from the host and records the host name and IP address of the connecting server and the name of the site where the server was listed in the server log.
  • Log and tag message: When Domino finds that a connecting host is on the blacklist, it accepts messages from the hosts, the host name and IP address of the connecting server, and the name of the site where the server was listed and adds the note item, $DNSBLSite, to each accepted message. The value of a $DNSBLSite item is the blacklist site in which the host was found. Administrators can use the $DNSBLSite note item to provide custom handling of messages received from hosts listed in a blacklist.
  • Log and reject message: When Domino finds that a connecting host is on the blacklist, it rejects the connection and returns a configurable error message to the host.
You can also gather statistics from the Domino Administrator or by using the SHOW STAT SMTP command from the server console. You can further expand the statistics to learn the number of times a given IP address is found on one of the configured DNSBLs. To collect the expanded information, you set the variable SMTPExpandDNSBLStats in the Notes.ini file on the server.
Use this setting to generate DNS blacklist filter statistics for each connecting host found in a DNS blacklist site.
  • 0 indicates that host-specific DNS blacklist filter statistics are not generated by the SMTP server.
  • 1 indicates that the SMTP server generates host-specific DNS blacklist filter statistics that indicate the total number of hits per DNSBL site, per connecting host's IP address.
This Notes.ini setting applies to Domino servers. In the absence of this setting, the SMTP task maintains statistics that track the total number of connecting hosts that were found on the combined DNSBL of all sites combined as well as how many were found on the DNSBL of each configured site.
The variable SMTPDebugSearchAllDNSBLSites=value displays the total number of DNS blacklist hits for each site configured if you set the value to 1. The default value is 0. Do not leave this variable in all the time. It is good to calculate statistics against all configured blacklist sites.
Inbound connection controls
This section can be used to restrict hosts and IP addresses from connecting to your Domino server. You can configure Domino to do a reverse DNS lookup from any connecting host. This forces Domino to verify the name of the connecting host by performing a reverse DNS lookup. Domino checks DNS for a PTR record that matches the IP address of the connecting host to a host name. If Domino cannot determine the name of the remote host because DNS is not available or no PTR record exists, it does not allow the host to transfer mail.
You can also enter host names and/or IP addresses allowed to or denied from connecting to the SMTP service on this server as shown in Figure 4. Host name entries may be complete, as in the fully qualified host name of a particular server, or partial and imply the existence of a wildcard. For example, in the "Allow connections only from the following SMTP internet host names/IP addresses" field, if you enter, Domino accepts only connections from mail hosts in the domains represented by *, so it accepts all host names ending in, including and Domino rejects all other connection requests.

Figure 4. SMTP Inbound Connection Controls
SMTP Inbound Connection Controls
Inbound sender controls
This section is used to restrict the sender of inbound SMTP messages. You can enable reverse DNS lookups on the sender's domain as shown in Figure 5. If enabled, Domino verifies that the sender's domain exists by checking the DNS for an MX, CNAME, or an A record that matches the domain part of the address in the MAIL FROM command received from the sending host. If no match is found, Domino rejects inbound mail from the host.
You can populate Internet addresses from which the server accepts or rejects messages. During the SMTP conversation, the Domino SMTP listener compares the address in the MAIL FROM command received from the connecting host with the entries in these fields.

Figure 5. SMTP Inbound Sender Controls
SMTP Inbound Sender Controls
Inbound intended recipients controls
This section allows you to restrict the name of recipients for inbound SMTP messages. A very useful feature is the "Verify that local domain recipient exist in the Domino Directory" field. This specifies whether or not the SMTP listener checks recipient names specified in RCPT TO commands against entries in the Domino Directory. If enabled, the domain part of an address specified in an SMTP RCPT TO command matches one of the configured local Internet domains; the SMTP listener checks all configured directories to determine whether or not the specified recipient is a valid user. If all lookups complete successfully and no matching user name is found, the SMTP server returns a 550 permanent failure response indicating that the user is unknown:
550 ... No such user
Choosing this setting can help prevent messages sent to nonexistent users (for example, spam messages and messages intended for users who have left the organization) from accumulating in as dead mail. To avoid messages from being rejected as a result of directory unavailability, Domino accepts messages when an attempted directory lookup does not complete successfully. Please refer to Figure 6 for more information.

Figure 6. SMTP Inbound Intended Recipients Controls
SMTP Inbound Intended Recipients Controls
You can populate Internet addresses that are within the local Internet domain and that are allowed or denied the ability to receive mail from the Internet. You can also create a Notes group containing a list of addresses allowed to receive or reject mail from the Internet and enter the group name in this field.
NOTE: Some of the sections above have Allow messages… and Deny messages… fields. These fields are mutually exclusive. Any entry in the Deny messages… field will ignore the corresponding Allow messages… field.
Server mail rules
You can create content filtering rules for a server that define actions to take on certain messages. When a new message that meets a specified condition is deposited in, Domino automatically performs the designated action. Rule conditions are based on content in the message headers or in the message body. By configuring a set of conditions and actions, you can customize rules to help block spam mail or intercept messages with questionable content. Except where a rule action explicitly indicates, Domino does not notify the sender or recipient if a rule prevents a message from reaching its destination.
If receives an encrypted message (Notes encrypted, S/MIME, PGP, and so on), the server mail rules process any rule conditions that are based on unencrypted information in the message envelope, such as the sender, importance, and recipients, but do not process conditions based on the encrypted portion of the message body. Most rule conditions are based on information in the message envelope. The server does not log instances in which rules are unable to process a message.
Domino stores the mail rules you create on the Configuration Settings document Router/SMTP - Restrictions and Controls - Rules tab. On startup, each server retrieves the mail rules from the appropriate Configuration Settings document and registers them as monitors on each database in use. Whenever receives a new message from any source, such as the SMTP process, the Router on another server, or a client depositing a message, the server evaluates the various message fields against the registered mail rules. Each message is evaluated only once.
Creating mail server rules
When you add a new rule, it takes effect only after the server reloads the mail rules. A reload is automatically triggered if the Server task detects a rule change when performing its routine check of the Configuration Settings document. This check occurs approximately every five minutes or can be reloaded from the Domino console.
When creating server mail rules, there are some factors that should first be considered. When multiple mail rules are enabled, you can set their relative priority by moving them up and down in the list. Try to place the most common words at the beginning of the rule so that if a condition is met it may not continue processing the remaining conditions in the rule. Don't search the body of the message unless it is really needed. Searching the body has the most impact on the server's CPU and memory and can cause undesired results on the performance of the Domino server. The maximum number of mail rules is 100, but can be adjusted with a Notes.ini variable.

Figure 7. New Rule dialog box
New Rule dialog box
The first step in creating a server mail rule is to determine the message item to examine or to specify condition(s). You can choose from:
  • Sender
  • Subject
  • Body
  • Importance
  • Delivery priority
  • To
  • CC
  • BCC
  • To or CC
  • Body or subject
  • Internet domain
  • Size (in bytes)
  • All documents
  • Attachment name
  • Number of attachments
  • Form
  • Recipient count
  • Any recipient
Once you have the message item to examine, you need to set the logical operator or qualifier. You have the option to choose from:
  • Contains (for text field values)
  • Does not contain (for text field values)
  • Is
  • Is not
  • Is less than (for numeric field values)
  • Is greater than (for numeric field values)
You can also modify the server mail rule to add more conditions, such as And or Or. You can also add an exception to the server mail rule as an option.
The second step in creating a server mail rule is to specify the action to perform when a message arrives that matches the condition statement. Refer to Table A for the options to choose from.

Table A. Specify Actions for server mail rules.
Journal this messageThe Router sends a copy of the message to the configured mail journaling database and continues routing the message to its destination. Journaling must be enabled on the Router/SMTP - Advanced - Journaling tab.
Move to databaseThe Router removes the message from and moves it in the database specified in the accompanying text field, for example, junkmail.nsf. The specified database must already exist. The message is not routed to its destination. Placing messages in a junkmail database lets you examine them more closely for unwanted or other suspicious content.
Don't accept messageDomino rejects the message, but the Router does not generate a delivery failure report. Depending on the message source, the sender may or may not receive a nondelivery report (NDR) or other indication that the message was not sent. When Domino does not accept an incoming SMTP message, it returns an SMTP permanent error code to the sending server, indicating that the message was rejected for policy reasons. SMTP permanent errors (500-series errors) indicate error types that will recur if the sender attempts to send to the same address again Depending on the configuration of the sending client and server, the message originator may then receive a delivery failure report. For messages received over Notes routing, Domino returns a delivery failure report indicating that the message violated a mail rule. For messages deposited by a Notes client, the sending client displays an error indicating that the message violated a mail rule.
Don't deliver messageDomino accepts the message, but rather than sending it to its destination, it processes the message according to one of the following specified options:
  • Silently delete: Domino deletes the message from with no indication to the sender or recipient.
  • Send NDR: Domino generates a nondelivery report and returns it to the sender. The MIME and Notes rich-text versions of messages sent from a Notes client result in separate delivery failure reports.
Change routing stateDomino accepts the message, but does not deliver it. Instead, it marks it as held, changing the value of the RoutingState item on the message to HOLD. This change to the routing state of the message causes the Router to retain the message in indefinitely, pending administrative action to delete or release the held message.
Inbound SMTP commands and extensions
Lotus Domino supports some common ESMTP (Extended Simple Mail Transfer Protocol) commands and extensions. For the most part, most of these are configured through the Server Configuration Settings document under the Router/SMTP - Restrictions and Controls - Advanced - Commands and Extensions tab. Each ESMTP command is supported by a different Request For Comment (RFC). Refer to Table B for the inbound ESMTP commands and extensions supported by the SMTP listener task.

Table B. Inbound SMTP commands and extensions
SIZE extension (RFC 1427)
  • Enabled (default) - Domino declares its maximum message size to connecting hosts and checks the sending host's estimates of message size before accepting transfer. If the sender indicates that a message to be transferred is larger than the maximum size, Domino returns an error indicating that it will not accept the message
  • Disabled - Domino does not advertise its maximum message size or check inbound message size before transfer.
Pipelining extension (RFC 1854)
  • Enabled (default) - Improves performance by allowing Domino to accept multiple SMTP commands in the same network packet.
  • Disabled - Domino does not accept multiple SMTP commands in a single packet.
DSN extension (RFC 3461) )
  • Enabled - Domino supports incoming requests to return delivery status notifications to the sender for failed, delayed, delivered, and relayed messages. Domino sends delay reports for low-priority messages held until the low-priority routing time to the sender of an SMTP message upon request.
  • Disabled (default) - Domino does not return delivery status notifications for SMTP messages. Domino will return failed DSNs.
8-bit MIME extension (RFC 1652)
  • Enabled - Domino accepts 8-bit messages as is, allowing reception of unencoded multinational characters.
  • Disabled (default) - Domino requires inbound messages containing 8-bit characters to be sent using 7-bit ASCII encoding.
HELP command
  • Enabled (default) - In response to the Help command, Domino displays a list of supported commands.
  • Disabled - Domino ignores the Help command.
VRFY command (RFC 821 section 3.3)
  • Enabled - Domino accepts inbound requests to verify user names.
  • Disabled (default) - Domino denies requests to verify user names.
EXPN command (RFC 821 section 3.3)
  • Enabled - Domino expands mailing lists or groups to show individual recipient names.
  • Disabled (default) - Domino does not expand lists and groups.
ETRN command (RFC 1985)
  • Enabled - Domino accepts inbound "pull" requests from other SMTP hosts to transfer messages destined for the calling server. Enabling ETRN support allows for more efficient use of bandwidth resources by allowing a remote SMTP host to request pending messages at the same time it transfers messages to the Domino server.
  • Disabled (default) - Domino does not accept inbound "pull" requests from other SMTP hosts.
SSL negotiated over TCP/IP port (RFC 2487 and RFC 3207)
  • Enabled - Domino supports the STARTTLS command, allowing it to create an encrypted SSL channel over the SMTP TCP/IP port.
  • Required - Domino accepts inbound SMTP connections over the TCP/IP port only from hosts that issue the STARTTLS command.
  • Disabled (default) - Domino does not allow secure SSL connections over the SMTP TCP/IP port.
After accepting the STARTTLS command from a remote server, Domino uses settings for the server's SSL port to govern authentication for the sessions. For Domino to authenticate remote hosts that use the SMTP AUTH command, name and password authentication must be enabled for the Domino SSL port. We'll cover how to configure the server's SSL port in part two of this article series.

Integrating voice, email, and fax in a single unified messaging store

In the ever-changing world of technology, the amount of time and money spent to ensure constant accessibility via fax, phone, email, chat, and text messages is steadily increasing. Companies have been searching for the answer to a unified messaging store to improve business productivity by helping the end user gain faster access to multiple media types. IBM has developed a solution in partnership with Cisco Systems, Avaya, and AVST that provides users a central repository to store and retrieve fax, phone, and email messages, and in 2002, IBM introduced its solution: Domino Unified Communications (DUC). Domino Unified Communications integrates with Lotus Notes and Domino to store email, voice mail, and fax messages in a server-based database. Now users can retrieve, create, and manage all their emails, voice mails, and faxes with a single device.
Domino Unified Communications allows you to access your messages from telephones, the Lotus Notes Client, pagers, Personal Digital Assistants (PDA's), cell phones, and browser-based email clients (Domino Web Access or iNotes). No longer do you have to dial into your voice mail to listen to voice messages or run to the fax machine to obtain important documents. Domino Unified Communications now allows you to access all these messages from one device and in multiple languages. You can use a phone to listen to voice messages as well as email messages or use a computer to read emails, faxes, and even play back voice messages. Not only will this save you time and frustration, but it will lower Total Cost of Ownership (TCO) because storing voice messages in Domino databases is typically less expensive than storing them in a proprietary voice mail system. Voice mail messages on average are less than 30 seconds long and each minute of voice data stored in Domino is approximately 1 MB in size. Storing multiple message types in one message store also reduces the process of backing up data to one process.
Domino Unified Communications can be deployed in small to medium businesses (SMB) or large corporate enterprises. According to the Cisco Systems Web site, it is projected that the market for unified messaging (UM) will reach $840 million by 2006 with over 24 million UM mail files. Businesses that have implemented unified messaging technology report desktop users spend 53 percent less time managing all their messages. Mobile Notes users report savings up to 70 percent less time when checking their messages using the Notes/Domino environment instead of using traditional means (email client, fax machine, and so on). Training time for new employees unfamiliar with the Notes environment is also reduced because the unified messaging client provides a single application for all email, fax, and voice mail messages, requiring familiarity with only one application interface, not three. Unified messaging represents the convergence of email, fax, and voice mail so that all messages are accessible from and controlled by a single application. Unified communications (UC) takes unified messaging a step further by extending message access to additional devices and technologies, such as mobile phones, pagers, PDAs, and browsers.
Domino Unified Communications can take full advantage of Domino features such as digital networking, automatic message replication, clustering, mail rules, system filters, and foldering. Lotus Domino can still utilize additional email clients that support Simple Mail Transfer Protocol (SMTP), Multipurpose Internet Mail Extensions (MIME), Post Office Protocol 3 (POP3), and Internet Message Access Protocol 4 (IMAP4). However, some DUC functionality will not work if you access a DUC-enabled mail file, such as clearing any type of read or unread flag. Users can personalize their mail files which provide full menu options to guide users through them with faster system navigation.
This article introduces you to Domino Unified Communications, giving you an architectural overview of how it works and which vendors your can choose to work with. It is intended for experienced Domino system administrators.
Technology needed to run Domino Unified Communications
IBM has partnered with three voice messaging technology vendors to deliver this product. Domino Unified Communications can be installed in conjunction with Avaya, AVST, and Cisco. The DUC code for all three vendors is based on a common architecture. In order for DUC to support fax capabilities, a dedicated fax line connected to the fax port on the fax server must exist. You will need to contact the vender to get a list of officially supported fax servers that you can use.
The procedure for setting up Domino Unified Communications depends on which vender you choose to install with. In this article, we will be working with DUC 1.2.2 for Cisco. However, IBM does not recommend any one vendor over the other. For more information about the installation and the partners' voice messaging system for Cisco, Avaya, and AVST, please refer to their respective release notes.
Domino Unified Communications can be installed by a trained professional consultant from IBM Global Services (IGS), IBM Software Services for Lotus (ISSL), or any authorized integrators from the voice messaging vendor of your choice. IBM Business Partners or their authorized integrators are responsible for the sale and support of all vender components related to DUC. Domino Unified Communications software is available through the IBM Passport Advantage Web site.
Supported server system requirements
The server software necessary to install and run Domino Unified Communications is as follows:
  • Microsoft Windows 2003
  • Microsoft Windows 2000
  • Microsoft Windows NT 4.0 with Service Pack 4 (using the Intel Pentium processor)
  • Lotus Domino 5.0.10 or higher
Supported client system requirements
The following client software is required to run DUC:
  • Windows XP
  • Windows 2000
  • Windows 9.x
  • Windows NT 4.0
  • Lotus Notes 5.0.10 or higher
  • Lotus Domino Web Access (iNotes)
Installing Domino Unified Communications 1.2.2 for Cisco
The installation of Domino Unified Communications 1.2.2 for Cisco requires three separate setups and installations. Domino Unified Communications runs on Lotus Notes and Domino 5.0.10 and higher, 6.0.x, and 6.5.x. The installation also requires Cisco Unity release 4.0(4) or higher on the voice mail server.
  1. Install DUC 1.2.2 for Cisco on any Domino servers that contain DUC-enabled mail files that you want to use unified communication and messaging. When you install the DUC server code, this will also UC-enable the default mail templates for Lotus Notes and Domino Web Access. During the installation, you can also select additional mail templates that you want to UC-enable. Note: If you are upgrading your DUC servers from Domino 5.0.x to Domino 6.x or 6.5.x, perform step 2. Then install Domino 6.0.x or Domino 6.5.x on the servers, and then reinstall DUC 1.2.2. Select both the mail50.ntf and mail6.ntf templates to DUC templates. This ensures that existing DUC Notes 5 users remain operational and that new DUC users (Notes 5.0.x, 6.0.x, and 6.5.x) can be created.
  2. Install the vender-specific Administration Client to enable/disable users for Domino Unified Communications.
  3. Install DUC 1.2.2 on Notes clients that you want to utilize unified communication and messaging. Installing DUC on the Notes client installs the Sipro Labs G.729a audio compression driver. When DUC is installed on the Notes client, the following extension manager add-in is added to the Notes.ini file: ExtMgr_Addins=ucclient.
When Domino Unified Communications is installed on the Domino server, some additional code extends into the ROUTER, SERVER, and HTTP tasks. In addition, Domino now runs three new tasks: UCEvent, CSUMHIr, and UCAdminp. UCEvent monitors mail files for DUC-specific events on the server. CSUMHIr passes message notifications to the voice server over TCP/IP. UCAdminp works with AdminP to process DUC-specific administration requests.
Subscribing users to Domino Unified Communications
After you install the DUC software, enable the end users for DUC. Use the Cisco Administration Client to select the users that you want to subscribe to DUC. The voice mail server sends an AdminP request to Domino. The AdminP task passes a request to the UCAdminp task to subscribe a user to DUC. The UCAdminp task is responsible for changing the mail file ACL to give the voice server Manager access along with replacing the design of the database to a DUC-enabled template for Domino Web Access users (hidden views are added). You also use UCAdminp to create profile documents that are in the users' mail files to store information about users as shown in Figure 1.

Figure 1. Cisco Unity Administrator
Cisco Unity Administrator
The Recorded voice control bar displayed during the subscriber registration allows you to make and play recordings with a phone or with your computer microphone and speakers. The Recorded voice control bar displayed in Figure 2 uses Distributed Component Object Model (DCOM) and requires that your browser is able to download and run ActiveX controls. You also have the ability to record up to five different personal greetings for such occasions as being out of the office or away from your workstation.

Figure 2. Recorded voice control bar
Recorded Voice Control Bar
The Cisco Unity server also modifies the subscriber's Person document. Thus, the voice mail server must have at least Editor access in the ACL of the Domino Directory with Delete documents and Create shared folders/views rights. Cisco Unity writes extensions into the Person document, but they are read-only. Figure 3 shows a DUC-enabled Person document.

Figure 3. Modified Person document with DUC enabled
Modified Person document with DUC enabled
Viewing and retrieving messages
With a Notes client, users can view messages in their Inboxes to determine if they are voice messages, fax messages, or email messages. The icons provide a visual description of each message type and because every message is delivered to one Inbox, you can see the number, type, and status of all your communications in one view. All messages appear in the Inbox (shown in Figure 4) and in addition, voice messages appear in a separate voice Inbox that displays the length and type of each message as shown in Figure 5. Voice messages can be played back on the user's machine using the integrated audio player/recorder. For messages to be played from Lotus Notes or Domino Web Access clients, the user must have either a machine with a capable sound card and speakers or a desktop phone. Voice messages are displayed with a custom form that gives them access to pause, stop, skip ahead, and skip back. All of these controls are available regardless if you playback the message through a computer or phone.

Figure 4. DUC-enabled mail file (Inbox view)
DUC-enabled mail file (Inbox view)

Figure 5. DUC-enabled mail file (Voice Inbox view)
DUC-enabled mail file (Voice Inbox view)
The integrated audio player/recorder provides the user with the ability to create new voice messages with a microphone or telephone. Figure 6 shows the embedded media player in a voice message. The user can then save the message as a draft or send the message to one or more recipients. Sending a recorded voice message works just the same as sending a regular MIME message.
NOTE: Voice messages do not function properly with encrypted mail.
DUC-enabled users can specify a variety of notification methods and criteria depending on the chosen voice server partner. When listening to a voice mail message, the user can add private notes to the message. This allows the user to store additional important information (up to 15,000 characters) in the message. Private notes are never forwarded or included in a reply with history.

Figure 6. Embedded media player with Private Notes field
Embedded media player with Private Notes field
The embedded media player in voice messages give the user a VCR-like remote control. Users can play, pause, skip, stop, and record. They also have volume control, a status display, a phone number display, and progress bar. For additional information about the controls available, please refer to Figure 7.

Figure 7. Controls available with the embedded media player
Controls available with the embedded media player
Subscribers can still access voice mail by dialing into the voice server and providing their identification and PIN. After the subscriber is authenticated, the voice server accesses the mail file and presents a summary of the messages. The subscriber can then skip or play back any message using a touch-tone keypad. The voice server plays the voice messages exactly how it was received. The voice server can also play back email messages with the Text-To-Speech functionality. The subscriber can then reply or forward any existing messages from his Inbox or create a new message. All sent messages are stored in the Sent view of the mail file. Also depending on the capabilities of your fax server and the voice partner you have chosen, you may have the ability to print emails, attachments, and incoming faxes on a nearby fax machine with the touch of a phone.
Behind the scenes: How Domino Unified Communications works
If a call into a PBX or IP-phone system is unanswered, it passes that call to the voice server using the Call Answering (CA) function. The voice server determines the correct subscriber for the call and plays the subscriber's greeting. The voice server then records the voice message with any additional information, such as urgency or privacy. The voice server then prepares the recorded voice message and routes it to the correct recipient mail file. When the message is received by the recipient, the message is categorized and notification services are generated depending on the user's preferences. The end user can be notified via any appropriate Message Waiting Indicator (MWI) or new message alert. DUC supports the standard message waiting indicators provided by conventional voice servers as well as common alert mechanisms such as instant messaging, pagers, and short message service (SMS). Figure 8 shows how Domino Unified Communications works.

Figure 8. Flow chart of Domino Unified Communications
Flow chart of Domino Unified Communications
Below is an except from the Domino console that shows the process of events starting with the Unseen flag being cleared (which is triggered by the USER.ID that owns the mail file opening an Unseen message). The process ends with confirmation that the notification was passed onto the handler queue. Once the voice server has received this notification, it tells the underlying phone system to turn off the light.
mm/dd/yyyy 09:20:45 AM  DUCS: [UCExtn(server)] Unseen flag cleared
mm/dd/yyyy 09:20:45 AM  DUCS: [UCExtn(server)] Posting MWI notification(s)
mm/dd/yyyy 09:20:45 AM  DUCS: [UCExtn(server)] Sent notification DB00075 from mail file mail\duc10.nsf
mm/dd/yyyy 09:20:45 AM  DUCS: [UCEvent] Notification received
mm/dd/yyyy 09:20:45 AM  DUCS: [UCExtn(server)] Notification posted for profile UCProfileCountChange:
mm/dd/yyyy 09:20:45 AM  DUCS: [UCExtn(server)] One notification posted
mm/dd/yyyy 09:20:45 AM  DUCS: [UCEvent] MWI notification DB00075 received for handler 
mm/dd/yyyy 09:20:45 AM  DUCS: [UCEvent] Event DB00075 posted to handler queue UCHDLR93062880

When you replace the design of a database using a DUC template, only additional design elements are added. The DUC mail template does not alter or remove any of the default design elements. The following table displays the new design elements that are added to the template.
Element Name
Voice Message
(Display Received Voice Message)
ViewsVoice Inbox
Agents(UC Enable)
Script librariesCore UC Classes
Core UC Strings
Unified Communications
The new DUC template starts with a UC naming convention (for example, UCmail5.ntf or UCmail6a.ntf). To verify whether or not a template is DUC-enabled, open the template with the Domino Designer client and check for the Voice Inbox view. To check whether or not a mail file has been DUC-enabled, verify if there is a $UCInbox view. This view is written into the mail file at the time of DUC enablement by the AdminP task.