Bookshelf v7.8: How the Internet SMTP/POP3 Driver Processes Email Messages

This section contains some information about email directories, driver parameters, and an overview of how the Internet SMTP/POP3 Server driver processes email messages. For details about the directories and driver parameters included in this section, see Siebel Communications Server Administration Guide.

Email Directories and Driver Parameters

When the Internet SMTP/POP3 Server driver starts, it creates the following directories and by default puts them in the bin subdirectory, if they do not exist. By default, the following directories are created:

If you do not wish to store messages in the bin subdirectory, you can specify a different location by changing the values for the communications driver parameters. To change the locations where messages are stored, navigate to the Administration - Communications screen and select the Communications Drivers and Profiles view. In the Driver Parameters list, choose one of the following parameters for the directory location that you want to change, and type a directory path in the Default Value column.

The following parameters control how incoming and outgoing messages are processed:

You can change how these email messages are processed by changing the Default Value of a driver parameter. For example, if you do not want to return attachments, change the default value to FALSE.

Output Parameter Values for POP3 and SMTP Email Drivers

During email processing, the POP3 and SMTP email drivers pass output parameter values to the Communications Inbound Receiver and Communications Inbound Processor server components. From the Communications Inbound Receiver and Communications Inbound Processor server components, these values are passed to the Siebel Email Response workflows in the form properties of the EventFields property set. Table 22 provides a list of the output parameter values and a general description of how you can modify email handling behavior by accessing these values in the EventFields property set.

Table 22. Output Parameters for POP3 and SMTP Email Drivers
Parameter Name	Default Value	Description
Attachments	0	Number of nonsupplemental attachments found.
CcList		Value of CC: header field. This parameter is semicolon delimited as required by the Siebel application.
DsnAction		This parameter uses the RFC1894 protocol. For more information, see http://www.faqs.org/rfcs/rfc1894.html.
DsnContent		This parameter uses the RFC1894 protocol. For more information, see http://www.faqs.org/rfcs/rfc1894.html.
DsnFinalRecipient		This parameter uses the RFC1894 protocol. For more information, see http://www.faqs.org/rfcs/rfc1894.html.
DsnOriginalEnvelopeId		This parameter uses the RFC1894 protocol. For more information, see http://www.faqs.org/rfcs/rfc1894.html.
DsnStatus		This parameter uses the RFC1894 protocol. For more information, see http://www.faqs.org/rfcs/rfc1894.html.
FileCharset%d		The character set of file %d (where %d is 0 based).
FileIsInline%d		If an incoming attachment does not have a name associated with it, it is considered inline. The Siebel user interface should display the attachment in the rich edit control and not in the attachment pane. (%d is 0 based).
FileIsSupplemental%d		If the incoming attachment is a supplemental file created by the driver, such as the original message.txt file, this parameter is set to TRUE. Otherwise this parameter is FALSE.
FileName%d		The name of the attachment file. This parameter can be specified in the MIME type or synthesized based on the type/subtype of the attachment.
FilePath%d		The physical location of the file on the local hard disk. If the response group that loaded the driver is not processing email in Real-Time, this will be the location of the file on the Siebel File System.
FileSubtype%d		This is the MIME subtype of the attachment.
FileType%d		This is the MIME type of the attachment.
HasAttach		TRUE if Attachments >= 1.
HTMLBody		This will be set if the incoming email text was HTML only or was multipart/alternative with HTML.
In-Reply-To		Value of In-Reply-To: header field. This parameter uses the RFC2822 protocol. For more information, see http://www.faqs.org/rfcs/rfc2822.html.
IsDeliveryStatusNotification		If the incoming email is a delivery status notification as specified by the RFC1894 protocol this parameter value will be TRUE. Otherwise, the value will be FALSE. For information on the RFC1894 protocol, see http://www.faqs.org/rfcs/rfc1894.html.
Keywords		Value of the Keywords: header field. This parameter uses the RFC2822 protocol. For more information, see http://www.faqs.org/rfcs/rfc2822.html.
LocalFileToGlobal%d		For a description of this parameter, see Moving Generated Local Files to the Siebel File System.
Loopback Candidate		For a description of this parameter, see Moving Generated Local Files to the Siebel File System.
Message-ID		Value of "Message-ID:" header field. We also use this as the SCAPI DriverTrackingID. For more information, see http://www.faqs.org/rfcs/rfc2822.html.
MsgClass		This parameter is obsolete.
OrigMsgFile		The incoming MIME type is saved in this local file. If the response group that loaded the driver is not processing email in RealTime, this will be the location on file on the Siebel File System.
Prefix		If this is a forwarded message this will be Fwd or Fw. If this is a message that is in reply to another message this will be Re. Otherwise this parameter will be empty.
Priority	3	This is a number from 1 to 5 with 1 being the highest priority and 5 being the lowest priority. This is extracted from the X-Priority or the X-MSMail-Priority if available.
Received		This is the date the email was retrieved from the POP3 server.
ReceiverAddress		The is the email address extracted from the From Address communications profile input parameter. For example, the ReceiverAddress for John Smith <John@Smith.net> would be john@smith.net.
ReceiverName		This is the proper name extracted from the From Address communications profile input parameter. If there was no proper name, this will be set to the ReceiverAddress. For example, the ReceiverName for John Smith <John@Smith.net> would be john@smith.net.
References		Value of References: header field. This parameter uses the RFC2822 protocol. For more information, see http://www.faqs.org/rfcs/rfc2822.html.
SenderAddress		The is the email address extracted from the From: header field. For example, the SenderAddress for John Smith <John@Smith.net> would be john@smith.net.
SenderAddrType		Always empty, this parameter is not needed by the workflows.
SenderName		This is the proper name extracted from the From: header field. If there was no 'proper name', this will be set to the SenderAddress. For example, the SenderName for John Smith <John@Smith.net> would be john@smith.net.
SenderReplyNames		If the Reply-To: header field is set, this is the value but delimited by semicolons rather than commas. If Reply-To: was not specified, this is the same value as the SenderAddress.
Sent		This is the date from the Date: header field.
SiebelChannelProfile		This is generated by Media Manager.
SiebelChannelType		This is generated by Media Manager.
SiebelChannelTypeString		This is generated by Media Manager.
SiebelDriverNotifyWhenDone		This is generated by Media Manager.
SiebelWorkItemID		This is generated by Media Manager.
Subject		Value of the Subject: header field.
Temp%d		If an attachment should be deleted by the processing workflow, this should be TRUE.
text/html charset		This is the IANA character set of the HTMLBody. This is the value of the charset parameter of the Content-Type header field.
text/plain charset		This is the IANA character set of the TextNote. This is the value of the charset parameter of the Content-Type: header field.
TextNote		This is the plain/text message body text of the incoming message.
ToList		This is the value of the To: header field. This will be semicolon delimited as required by the Siebel application.

Moving Generated Local Files to the Siebel File System

The following section describes how to cause the Communications Inbound Receiver to move driver-generated local files to the Siebel File System.

The processing of driver events may occur on a remote Communications Inbound Processor server. However, this will only occur if the response group input parameter RealTime is set to FALSE. In previous versions of Siebel Email Response, the Communications Inbound Manager server component would always execute driver events in the same process in which the driver was loaded. This meant that the business service executed by Communications Inbound Manager server component, usually a workflow, would have easy access to any local files generated by the driver.

To allow workflows executing on a remote Communications Inbound Processor server to access driver-generated local files, the Communications Inbound Receiver will watch for EventFields with the following tag:

tag is the key to a tag/value pair that will have the text toReplace replaced with the actual Siebel File System file name generated when toReplace was moved to the Siebel File System.

This example results in the local file c:\OriginalMsgFile.txt being moved to the Siebel File System. Assuming this file received the name ABCDEFG on the Siebel File System, the EventFields would be modified as follows before being submitted to workflow for processing: