Siebel Email Response Administration Guide > Tables and Reference > How the Internet SMTP/POP3 Driver Processes Email Messages >

An Overview of the Processing Flow of Inbound Email Messages


When the Internet SMTP/POP3 Server driver starts, it creates required directories such as Incoming Email. The Internet SMTP/POP3 Server driver also creates a thread that polls the POP3 server. The PollingInterval driver parameter controls the frequency at which the Internet SMTP/POP3 Server driver checks the POP3 server for messages.

If there are messages, the Internet SMTP/POP3 Server driver retrieves and processes them one at a time, up to a maximum per session equal to the value set in the POP3 Batch Size driver parameter. If the current session with the POP3 server terminates abnormally, all messages previously retrieved, processed, and deleted during the current session will be restored, retrieved, and processed again the next time the Internet SMTP/POP3 Server driver connects to the POP3 server. The smaller the value POP3 Batch Size driver parameter, the fewer duplicate messages will be created and processed if a restart occurs.

Messages in a session are processed as shown in the following steps:

  1. A message is saved in the Incoming Email directory.
  2. The POP3 DELE command deletes the message from the POP3 server.

    If the DELE command fails, the message stored in the Incoming Email directory is erased because it will be retrieved again in the next POP3 session.

    NOTE:  You should not have other email clients accessing the mailboxes that Siebel Email Response is monitoring because the email driver deletes the messages from the POP3 server when they are processed by Siebel Email Response. As such, these messages will not be visible from another client.

  3. The disk based message is parsed. The parsing produces the following files in the Incoming Email directory:
    1. OriginalMessageText_[the original header of the message along with all text parts concatenated together].txt.
    2. Any attachments parsed from message are given unique names in the following format:

      ATT_[the original header of the message along with all text parts concatenated together].DAT.

    3. Any remaining text or HTML fragments are turned into attachments and are given unique names in the following format:

      ATT_[the original header of the message along with all text parts concatenated together].DAT.

  4. If an error occurs when the message is parsed, the following events occur:
    1. A temporary file in the following format is moved to the Failed Email directory and any attachments created are deleted:

      pop3_[the original header of the message along with all text parts concatenated together].tmp

    2. The POP3 session is immediately terminated with a QUIT command so that the offending message is permanently deleted from the server.
  5. If the Loopback Detection Interval parameter value is greater than zero and the message sender is currently being blocked, the following events occur:
    • If the Process If Loopback Detected parameter value is FALSE, the message is moved to the Loopback Email directory.
    • If the Process If Loopback Detected parameter value is TRUE, the driver's Loopback Candidate flag is set to TRUE and the message continues processing.
  6. If the message is not moved to the Loopback Email directory or flagged as a loopback candidate, the pop3_[the original header of the message along with all text parts concatenated together].tmp file is processed as follows:
    • If the Delete Processed Messages parameter value is TRUE, the temporary file is deleted.
    • If the Delete Processed Messages parameter value is FALSE, the temporary file is moved to the Processed Email directory.
  7. The primary message text, header information (subject, to, cc, date, and so on), Loopback Candidate flag, and references to the attachments are passed to the driver's creator (usually Communications Inbound Receiver and Communications Inbound Processor).
  8. The OriginalMessageText file and all the attachments are not deleted by the SMTP/POP3 driver. It is the responsibility of the workflow invoked by CIM to delete all the attachments.

    CAUTION:  Any errors that occur in the workflows may strand the ATT_OriginalMessageText files in the Incoming Email folder. If this occurs while CIM is not running, the workflow invoked by CIM failed to process a message event. The safe way to determine if an ATT_OriginalMessageText file can be deleted is to stop CIM and then look at the contents of all the queued CIM Events in all response groups to make sure that the ATT_OriginalMessageText files are no longer being referenced.

Siebel Email Response Administration Guide