Siebel Email Administration Guide > Configuring Communications Drivers and Profiles for Email > How Communications Drivers Process Email Messages >

Attachments Created When Inbound Email Is Received

The Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver creates several different files as a result of processing inbound and outbound email messages. Some of these files are temporary, and some can be permanent depending on the profile parameters. All numbers in the file names are in Hexadecimal format.

Siebel Email Response generates internal attachments when it receives plain text or HTML email. These internally generated attachments appear in addition to any external attachments that the email sender associates with the email. No internally generated attachment is sent with a Reply, Reply to All, or Forward message.

SMTP_A_B_C_D_E_F.tmp

When the driver is used to send a message, it creates one file with the naming convention SMTP_A_B_C_D_E_F.tmp where:

• A is the process ID of the application that loads the driver.
• B is the Siebel Communications API handle of the driver.
• C is the Siebel Communications API handle of the service.
• D is the time when the service is created.
• E is the number of messages that this service sends.
• F is the number of milliseconds that elapsed since the application was started.

This file is the encoded MIME message that is sent to the SMTP server for delivery. This file is created under the bin/sent directory unless you specify the Sent Email Directory profile parameter. This file is deleted after the message is sent from the disk to the SMTP server unless the Save Sent Msg profile parameter is set to True.

POP3_A_B_C_D_E_F.tmp

When the driver is used to retrieve a message from a POP3 server, it creates a file to store the incoming message with the naming convention POP3_A_B_C_D_E_F.tmp where:

• A is the process ID of the application that loads the driver.
• B is the Siebel Communications API handle of the driver.
• C is the Siebel Communications API handle of the service.
• D is the time when the service that received the message is created.
• E is the number of messages that are received during the current POP3 session.
• F is the number of milliseconds that elapsed since the application was started.

This file is the MIME message that is retrieved from the POP3 server. This file stores the incoming message and is always created in the bin/incoming directory unless you specify the Incoming Email Directory profile parameter. If the Delete Processed Messages profile parameter is False, then these messages are moved to the bin/processed directory after they are processed, otherwise they are deleted.

After a MIME message is downloaded to the bin/incoming directory, it is parsed and the results are usually passed to the Communications Inbound Receiver. This file is not reprocessed when the Communications Inbound Receiver is restarted. Therefore, if an application failure occurs, then one or more of these files might be placed in the bin/incoming directory. You can delete these files without consequence. The messages that the POP3_A_B_C_D_E_F.tmp files represent are re-retrieved and not lost.

ATT_A_B_C_D_E_F_G.dat

When the driver is used to retrieve a message, it creates a file to store attachments that are parsed from the incoming message with the naming convention ATT_A_B_C_D_E_F_G.dat where:

• A is the process ID of the application that loads the driver.
• B is the Siebel Communications API handle of the driver.
• C is the Siebel Communications API handle of the service.
• D is the time when the service that received the message is created.
• E is the number of messages that are received during the current POP3 or IMAP session.
• F is the number of attachments that are found so far in the message.
• G is the number of milliseconds that elapsed since the application was started.

When the message is parsed, all non-inline message parts and textual parts of the message are used to create the attachment files in the bin/incoming directory.

Another special instance of this type of file is created when an embedded message is found in the message that is parsed. Embedded messages cause the creation of one of the following two types of files:

• A file with the internal name of EmbeddedMsgX.xml that contains the embedded message header and all plain text parts of the mail. The purpose of this file is the same as the purpose of the OriginalMessageText_A_B_C_D_E_F.txt file.
• A file with the internal name EmbeddedMsgX.eml that contains the MIME message of the embedded message. You can open this file with Microsoft Outlook Express. This file is created only if the Parse Embedded Messages profile parameter is explicitly set to False, and the EmbeddedMsgX.xml file is not created.

OriginalMessageText_A_B_C_D_E_F_G.txt

When the driver is used to retrieve a message, it creates a file to store the header and textual data from the incoming message with the naming convention OriginalMessageText_A_B_C_D_E_F.txt where:

• A is the process ID of the application that loads the driver.
• B is the Siebel Communications API handle of the driver.
• C is the Siebel Communications API handle of the service.
• D is the time when the service that received the message is created.
• E is the number of messages that are received during the current POP3 or IMAP session.
• F is the number of attachments that are found so far in the message.
• G is the number of milliseconds that elapsed since the application was started.

The OriginalMessageText file contains the MIME format of the message that the Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver receives. The original message header and all text/plain message parts that are not inside an embedded message part and not marked as inline are written to a file in the UTF-8 character set.

The Siebel Email Response workflows delete the ATT and OriginalMessageText files. If ATT or OriginalMessageText files exist in the bin/incoming directory, then the Communications Inbound Receiver process terminated abnormally or the email events that created these files are not yet processed. Do not manually delete these temporary files until you verify that none of the email events under the bin/queued directory reference the temporary files.

Current_A_B.ids and Previous_A_B.ids

To avoid retrieving duplicate messages when a POP3 or IMAP session is abnormally terminated, the unique message-ids associated with each processed message are stored (to keep track of previously retrieved messages) in two files with the naming conventions Current_A_B.ids and Previous_A_B.ids where:

• A is the POP3 or IMAP server name.
• B is the POP3 or IMAP account name.

The Current index file stores all the message IDs that are passed to the Communications Inbound Receiver for workflow processing in the current POP3 or IMAP session. If the session terminates abnormally, then the quit command is not executed and the delete commands for the current session are not executed. To avoid re-retrieving the messages from the previous session, the driver checks for a Current index file on startup, and if this file exists, then it is appended to the Previous index file. Before a message is retrieved from the POP3 or IMAP server, the Previous index file is checked to see whether that message is already processed.

You can delete these files, but if a POP3 or IMAP session terminates abnormally and you delete these files, then messages with a POP3 Batch Size less 1 might be duplicated. These files never are large because they are erased each time a POP3 or IMAP session terminates normally. In addition, they are never larger than a certain number of bytes (POP3 Batch Size multiplied by 128).

POP3SMTP_A_B_C_D_E.log or IMAPSMTP_A_B_C_D_E.log

Each service instance can also create a log file if you set the LogDebug profile parameter to True. The error logging level determines the amount of tracing data in this log file. This log file is always created in the same directory as all the other Siebel log files. The naming convention of this file is POP3SMTP_A_B_C_D_E.log or IMAPSMTP_A_B_C_D_E.log where:

• A is the process ID of the application that loads the driver.
• B is the Siebel Communications API handle of the driver.
• C is the Siebel Communications API handle of the service.
• D is the time when the service that received the message is created.
• E is the number of milliseconds that elapsed since the application was started.