Bookshelf v7.8: About Installing and Configuring Siebel Email Marketing

The Siebel Email Marketing Server is a combination of components designed to support high volume, personalized email messages and track email bounces and click-through responses. The Siebel Email Marketing Server consists of the following three components, each with its own installer and each is separate from the Siebel Marketing Server installer:

Example of Email Delivery

A good understanding of email delivery is helpful in understanding the key principles and items presented in the following topics. The provided example is a simplified description of the email delivery process and describes one email being sent. When you send thousands or millions of emails, the process becomes more complex. Siebel Email Marketing is designed to address the issues associated with sending a large volume of emails.

When an email is sent by person A to person B, an attempt is made to deliver the email. The first step in the process occurs when the user clicks Send in their email client. The email client tries to initiate a connection to an email server.

NOTE: This email server is often called a Mail Transfer Agent (MTA) because of its function or a Simple Mail Transfer Protocol (SMTP) Server because of the protocol it uses.

When the client has a connection to a Mail Transfer Agent, the Mail Transfer Agent and the client communicate using the Simple Mail Transfer Protocol. The following are important parts of this communication:

If the recipient of the email (person B) has their mailbox on this server, then the server drops the email in the box and the job is done. If person B is on another domain, the Mail Transfer Agent executes a Domain Name Service (DNS) lookup to find the address of another Mail Transfer Agent to communicate with. Another Simple Mail Transfer Protocol conversation occurs and the second Mail Transfer Agent receives the message and delivers it to the mailbox for person. When it is in person B's mailbox, the recipient can retrieve it using another protocol such as Post Office Protocol (POP) and read the message in an email application.

Unexpected issues can occur during this process. For example, the domain of the recipient can be unreachable or not exist at all. In this case, an error message, or bounce, is created by the Mail Transfer Agent that identifies the problem and the bounce is returned to the sender of the message (the sender's email address is also called the from address of the SMTP envelope). Another problem may be that the domain has been found but the user does not exist on that domain. Again, a bounce is created and sent back to the sender of the original message. Both of these are examples of hard bounces. This means that not only was the email unable to be delivered but that it can never be delivered. Another type of bounce is a soft bounce, which means that although the email could not be delivered at present, it may be possible to deliver the message in the future. Table 23 lists the possible bounce codes.

Table 23. Bounce Codes
Bounce Code	Description
Address Moved	The recipient has changed the email address and the new address is available. This occurs rarely.
Bad Sender	The email address is bad: either the address is misformatted (unlikely) or there is no such user.
Last Resort	The bounce parser could not determine the type of bounce, but it has the name of the original recipient.
Mailbox Problem	The email address exists, but the mailbox is full or temporarily locked. This occurs rarely.
Message Too Large	The message size exceeds the recipient's allowable limit.
Network Problem	Because of network problems, the MTA is unable to connect to either the receiving Mail Server or some other necessary server (such as a company's LDAP server). This occurs rarely.
Protocol Problem	The receiving Mail Server does not work with the version of SMTP the MTA uses. This occurs rarely.
Security Problem	The receiving Mail Server does not allow email from your domain. This can occur when the receiving Mail Server blocks domains of known or suspected spammers.
System Problem	The receiving email server is having technical problems and cannot accept mail right now.
Unparsable	The bounce parser could not classify the bounce message into any other category.
Vacation	The recipient has activated a vacation mail response. This error message occurs rarely because vacation responses do not get sent to the same place bounces do and also because vacation messages are quite varied, making it hard for the bounce parser to identify them.

The Siebel Email Marketing Server Installation

The Siebel Email Marketing Server consists of three components, each of which comes with its own installer and is separate from the Siebel Marketing Server installer. The installation media for the three Email Marketing Server components are distributed together on media separate from the Siebel Enterprise installation media.

The following is a summary of the issues to consider when installing the different components of Siebel Email Marketing. The Email Marketing components can reside outside the firewall, with ports opened for SISNAPI, SOAP (HTTP), and networked file system access through the firewall. Alternatively, the Email Marketing components can reside inside the firewall with ports 80 and 25 opened on the firewall (or proxies) or relays put in place.

These components talk to the Siebel Marketing Server using the Siebel Java Data Bean over the Siebel Internet Session API (SISNAPI). For more information about the Siebel Java Data Bean, read the topic about integrating with the J2EE Application server in Transports and Interfaces: Siebel Business Application Integration Volume III.

Email Sending Daemon (ESD)

The Email Sending Daemon assembles an email to be sent to a list or segment of contacts and prospects and delivers each email to the corporate outbound Mail Transfer Agents. Assembly includes adding headers in front of the email message content and merging personalized data into the message content.

The Email Sending Daemon listens on port 80 for SOAP requests from the Siebel Marketing Server. A SOAP request includes the filename of the email message content, the email message headers, and the Marketing Server subwave contacts and prospects list (containing mail merge data). These files are found in the Marketing File System which is commonly a networked directory accessible to the Email Sending Daemon. The Email Sending Daemon must be able to communicate with one or more outbound Mail Transfer Agents to send mailings over the internet. The Email Sending Daemon must be able to tell the Marketing Server when it has completed a subwave as well as deliver details of email address errors that occurred while it communicated using Simple Mail Transfer Protocol to the Mail Transfer Agents (called synchronous bounces). Communications with the Siebel Marketing Server use SISNAPI protocol.

The most common placement for the Email Sending Daemon is within the corporate network, behind the DMZ. However, the Email Sending Daemon component can be placed inside the DMZ or outside the firewall, if there is a port opened to connect to the Siebel Marketing Server using SISNAPI protocol, SOAP, and the networked Marketing File System.

Bounce Handler Daemon (BHD)

Typically, the Bounce Handler Daemon receives and processes bounced mail on port 25 (the default SMTP port).

Email messages that have bounced appear similar to regular email, though their email message content and headers probably have noticeable differences in content. For a bounced email to be returned to the Bounce Handler Daemon, the original email must have a usable return address (the SMTP envelope from address). The correct SMTP envelope from address is generated for you using the Bounce Handler Daemon's domain name (supplied by you when you configure the Email Marketing Server).

The recommended approach is to place the Bounce Handler Daemon machine in the DMZ. However, some network support technicians may want to place the Bounce Handler Daemon behind an inbound Mail Transfer Agent. The approach that you choose depends on the configuration of your network, DMZ, existing inbound Mail Transfer Agent, and firewall. The following example describes a typical approach:

You may have a domain name of oracle.com and an inbound Mail Transfer Agent (in this example mail.oracle.com) for mail to that domain. The Mail Transfer Agent mail.oracle.com currently routes email successfully to machines in the internal network. It may be in the DMZ with a special hole for port 25 traffic or straddling the outer firewall with one NIC in the DMZ and the other NIC on the Internet. The Bounce Handler Daemon may be running inside the DMZ, with an internal-only hostname such as oracle-host.internal.oracle.com.

In this example, you would need to choose a Bounce Handler Daemon hostname such as bounces.oracle.com that is not already used by external DNS and then and perform the following steps:

Because the Internet DNS MX records for bounce.oracle.com point to the inbound Mail Transfer Agent, bounced email for the Bounce Handler Daemon is sent there first. Mail.oracle.com should be configured to relay the mail for bounces.oracle.com to the Bounce Handler Daemon using the internal DNS server for the correct internal IP address.

Organizations often create IP numbers that cannot be routed within their enterprise. For example, IP numbers starting with 10.* or 192.168.* are only available inside the enterprise. Similarly, organizations often have hostnames, such as my-machine.corp.oracle.com, that are only visible inside the company network. If you use an IP address or hostname that is only available inside your company network for your Bounce Handler Daemon hostname, Mail Transfer Agents outside your network can not connect to the Bounce Handler Daemon. Therefore, the Bounce Handler Daemon server must be available, directly or indirectly, from outside your network.

Click-Through Daemon (CTD)

The Click-Through Daemon listens on port 80 for HTTP requests (Click-through, Message Open, Forward to a Friend and un-subscription/subscription requests). This component can be placed in the DMZ, inside or outside the firewall, if a port is opened that allows it to connect to the Siebel Marketing Server using SISNAPI protocol. Web proxy servers can be used to route the HTTP requests to the Click-Through Daemon server.

Frequently Used Terms for Email Marketing

Table 24. Frequently Used Terms for Email Marketing
Term	Definition
BHD	Bounce Handling Daemon. Processes asynchronous bounced email (bounces that do not occur in the SMTP communications between the Email Sending Daemon and the Mail Transfer Agent).
Bounce	An email that is returned due to a temporary or permanent error condition. There are hard bounces and soft bounces as described in the following list: Hard bounce. The email was not delivered and can never be delivered. For example, if the email address is invalid. Soft bounce. The email cannot be delivered because of a temporary problem such as a full mailbox and can be delivered when the problem no longer exists.
CTD	Click Through Daemon. Handles the following customer actions: Unsubscribe and Subscribe so contacts can opt in or opt out of email lists. Forward to a Friend provides method for capturing new email addresses. Related URLs track customer clicks an embedded link in an email. Read Receipts logs message opens.
Daemon	A program that is not invoked explicitly, but lies dormant waiting for an action or event to activate it.
DNS	Domain Name System. Created to provide a way to translate domain names to their corresponding IP addresses. The DNS server maintains a list of domain names and IP addresses and each request is pointed to the correct corresponding IP address.
DMZ	DeMilitarized Zone. A section of your corporate network that acts like a neutral zone or buffer between your internal network and the Internet. It is created by placing one firewall between the outside (internet) and Web servers, and a second firewall between the Web servers and your internal network. External users can access servers in the neutral zone, but not servers on the internal network. The servers in the DMZ handle incoming and outgoing traffic.
DNS groups	DNS domain names are categorized into groups called a record and each record is given a special name such as MX or A. MX (type of record). Specifies a domain name which can receive and possibly relay emails. This domain probably contains a server hosting an MTA. A (type of record). Maps a domain name to an IP address.
ESD	Email Sending Daemon. Manages the following tasks: Email Construction and Personalization. Delivery of outbound email to Mail Transfer Agents. Synchronous bounced email. Bounces that occur in the SMTP conversation between the Email Sending Daemon and the MTA.
MTA	Mail Transfer Agent. A program responsible for receiving, routing, and delivering email messages. MTAs receive email messages and recipient addresses from local users and remote hosts, perform alias creation and forwarding functions, and deliver the messages to their destinations. An MTA is sometimes called a Mail Transport Agent, a mail router, an Internet mailer, or a mail server program. Commonly used MTAs include sendmail, qmail, and Exim.
SISNAPI	Siebel Internet Session Network Application Programming Interface. A proprietary Siebel network protocol used for communications to and from Siebel Components.
SMTP	Simple Mail Transport Protocol. Used to move each email over the Internet.
SOAP	Simple Object Access Protocol. The use of XML and HTTP to access services, objects, and servers in a platform-independent manner. For more information about SOAP, read Siebel Analytics Web Services Guide.

Siebel Marketing Installation and Administration Guide		Copyright © 2006, Oracle. All rights reserved.