This extension runs in the background to scan the defined mail inbox(es) and either create or update tickets based on the content of the incoming emails.

• On Ticket creation, it fills the description of the ticket with the content of the email, set the caller, the customer, copy attachments, add contacts and many other fields…
• On Ticket update, it extracts as best as possible, the last reply part of the email to update the Public Log of the ticket, copy attachment, change the status of the ticket and add contacts

• Determine if the sender is an existing Person (found by its email), then based on configuration it can reject the email in error or create a new Person.
• Determines whether a Ticket must be created or updated based either on the custom headers added by iTop in the eMail (in case of replies) or based on a configurable pattern in the title
• Connect to any mailbox using either the POP3 or IMAP protocol
• Interactive configuration of the mail inboxes
• Processes the incoming eMails in both HTML or plain text format
• Support both Incidents and User Request tickets
• Ticket's attachments are automatically turned into attachments of the Ticket (“dangerous” types of attachments can be excluded)
• Automatic detection of duplicate attachments (like signature images)
• Keeps the messages in the mailbox until the corresponding Ticket is either closed or deleted
• Manual retry in case an error occurs when processing an eMail
• Images embedded inside an HTML mail are displayed inline in iTop as well.
• Images “too small” (below configurable dimensions) are not imported as attachments (to exclude signatures)
• Images bigger than configurable dimensions can be resized automatically before uploading into iTop
• “Inline images” are displayed at a reduced (configurable) size and can be “zoomed-in” by clicking on them.
• Automatically reject “Autoreply” emails, based on a set of configurable patterns to be tested against the subject of the email
• Add the other recipients of the email (To: and CC:) as additional contacts on the ticket (configurable). The contact must already exist with that exact email, it won't be created, just linked to the Ticket..
• Apply a stimulus (configurable, depending on the state of the ticket) to change the state of the ticket upon reception of an email.
• Add a new type of Trigger: Trigger (when updated by mail) which allow to notify when a Ticket is updated through a received email.

• PHP 5.2.1+ with the IMAP extension enabled if you want to connect to an IMAP server, or PEAR::NetSocket (iTop comes with its own copy of PEAR::POP3) if you want to connect to a POP3 server.
• A connection to a POP3 or IMAP server with a valid mailbox.
• cron.php must be running to enable the processing of incoming eMails.
• For the debug trace, PHP MBString must be installed.
• For resizing big images, PHP GD must be installed.

sudo apt-get install php-pear php-net-socket php-imap

• Expand the content of the zip file in the “extensions” folder of iTop.

• Make sure that the web server has enough rights to read all the files in the “extensions” folder.
• Launch the setup program, and when prompted for the list of extensions to install, check “Mail to ticket automation” from the list

sudo apt-get install php5-imap
sudo php5enmod imap

sudo service apache2 restart

When creating a new ticket from an incoming email message, the application automatically fills the following fields of the ticket:

• Title = subject of the mail
• Description = body of the mail
• Caller (caller_id) = sender of the mail (identified by her/his email address)
• Organization (org_id) = organization of the caller
• Origin (if this field exists on the ticket) = 'mail'

Default (i.e. constant) values must be supplied, via the “Ticket Default Values” setting, for any other mandatory field of the Ticket, otherwise the creation of the Ticket will fail.

When updating an existing Ticket, the application add an entry into the public_log field (configurable, see below), with the “new part” of the message. See below for more explanation about how the “new part” is extracted from the message.

The syntax for specifying default values is the following:

• One field per line, with the syntax:
• field_code:default_value

If the field to initialize is a key to another object (for the fields like org_id, service_id, etc…) you can specify either the numeric identifier of the target object (e.g. service_id:153) or its name (e.g. org_id:Demo), provided that the name is unique.

The behavior for each mailbox (which messages to process and whether to create or update a Ticket) is managed via the menu “Incoming eMail Inboxes” in the “Admin tools” section:

Click, “Create a new Mail Inbox” to create a new configuration for a mail inbox. This displays the following form:

The “Mailbox configuration” defines how the application connects to the mail inbox:

This section defines the behavior when an incoming email cannot be processed properly. The email can be either kept in the mailbox (and remembered as an “Error” and no longer processed) or deleted immediately from the mailbox. Furthermore the original message can be forwarded to an administrator (as an attachment) along with some explanation about the cause of the error.

This section defines the behavior of the application when processing incoming emails.

This section determines the behavior of the application when the sender of an email (From:) does not correspond to a known email address in the application. There are two possibilites:

• Reject the eMail: the incoming email is treated as an error and thus either forwarded to an administrator or deleted.
• Create a new person: a new Person will be created based on the email of the sender and constant values defined below.

This section determines the behavior of the application regarding the additional recipients of the incoming email (persons in To: and CC: of the message). It is possible to specify if/when the email addresses which correspond to a valid contact in iTop are added to the ticket (via the Contacts tab). Email addresses which do not correspond to a valid contact in iTop are always ignored.

In addition to the configuration performed by creating a Mail Inbox object using the user interface of the application, a few parameters are available in the configuration file to fine tune the behavior of the application.

   'combodo-email-synchro' => array (
      'debug' => false,
      'periodicity' => 30,
      'body_parts_order' => 'text/html,text/plain',
      'pop3_auth_option' => 'USER',
      'imap_options' => array (
            0 => 'imap',
      ),
      'exclude_attachment_types' => array (
            0 => 'application/exe',
      ),
      'maximum_email_size' => '10M',
      'recommended_max_allowed_packet' => 10485760,
      'introductory-patterns' => array (
            0 => '/^le .+ a écrit :$/i',
            1 => '/^on .+ wrote:$/i',
            2 => '|^[0-9]{4}/[0-9]{1,2}/[0-9]{1,2} .+:$|',
      ),
      'multiline-delimiter-patterns' => array (
            0 => '/\\RFrom: .+\\RSent: .+\\R/m',
            1 => '/\\R_+\\R/m',
            2 => '/\\RDe : .+\\R\\R?Envoyé : /m',
            3 => '/\\RDe : .+\\RDate d\'envoi : .+\\R/m',
            4 => '/\\R-----Message d\'origine-----\\R/m',
            5 => '/\\RExpéditeur: .+\\RDate:/m',
            6 => '/\\RDe : .+\\RDate : /m',
            7 => '/\\TO:.+\\RCC:/m',
      ),
      'delimiter-patterns' => array (
            '/^>.*$/' => false,  // "false" remove only the line, "true" remove the rest of the message
      ),
      'big_files_dir' => '',
      'use_message_id_as_uid' => false, // Don't change this unless you know what you are doing!
      'images_minimum_size' => '100x20',
      'images_maximum_size' => '',
      'undesired-subject-patterns' => array (
            0 => '/^Out Of Office/i',
            1 => '/^Automatic answer$/i',
            2 => '/^Réponse automatique:/',
      ),
      'undesired-purge-delay' => 7,
      'html-tags-to-remove' => array(
           'blockquote' => array(), 
           // No class specified, remove any blockquote tag
           'div' => array('gmail_quote', 'moz-cite-prefix'),
           'pre' => array('moz-signature'),
      );
 
   ),

        'itop-standard-email-synchro' => array (
                'ticket_log' => array (
                          'UserRequest' => 'public_log',
                          'Incident' => 'public_log',
                        ),
        ),

• Each mail inbox configured corresponds to one type of Ticket (i.e. User Requests or Incidents, but not both).
• Connecting to a POP3 mailbox via the php IMAP extension does not work. You must use the POP3 configuration via PEAR::NetSocket for such a case.
• There is no validation that the target class of the Mail Inbox is an existing class in iTop. (i.e. don't try to create incidents if the Incident Management module is not installed).
• The support of inline images works only if the preferred order for email parts is configured as “text/html,text/plain” (i.e. HTML first), which is now the default for all new installations.

Once the Mail Inbox object has been created, you can use the tab “Mailbox Content” in the details of the object to check that the application can properly connect to the mail server and retrieve messages from it.

This view also allows to perform two different kind of actions on a set of messages:

• “Reset Status”: for messages which are either flagged as “Error” or “Already processed”, this status will be reset and the email will considered again as “New” and thus candidate for processing the next time cron.php runs.
• “Delete eMail”: deletes the message(s) from the mailbox. No confirmation will be asked !!
• “Ignore eMail”: mark new messages as “ignored” to avoid processing them.

New in 3.0.15: Access to the eml used and to the message specific logs without activating the debug mode for every processed message.

Since the processing of the incoming emails occurs in the background, it is not always easy to understand what happens when a ticket is not processed as expected. In order to trace the execution of this background task, several levels of tracing are available:

• by setting the “Debug trace” field to “Yes”, more trace will be generated when processing the mailbox. This trace goes to the output of the cron job, and is also captured (limited to 256 KB) in the database. This captured trace is visible in the “Debug Trace” tab of the Mail Inbox object.
• the configuration setting debug for the module combodo-email-synchro can be set to true in the configuration file. This activates even more traces for all the configured mail inboxes. This additional trace appears only in the output of the cron job.
• the cron job can be passed the optional parameter --verbose=1 to activate some debug trace for all the background tasks. This additional trace also goes into the output of the cron job.

If the cron job is not already running in the background it is convenient to run it manually from the command line, to see what's happening:

  php cron.php --auth_user=<user> --auth_pwd=<pwd> --verbose=1

Question: Mails are no more processed?
Answer:

1. It might be due to a email message with a too big attachment, which can end-up crashing the database. In that case, to quickly process the following emails, open the Mail Inbox in iTop, tab: Mailbox Content; identify the faulty email, probably the oldest “new” message and check it and press the Ignore button.
2. To limit the above situation, check coherence between allowed_max_packet, recommended_max_allowed_packet and maximum_email_size parameters.
3. It might be due to the cron.php not running

Question: a particular mail is in error, why?
Answer: There can be multiple reasons, which leads to flagging a mail in error. When browsing the Mailbox Content tab on the Incoming eMail Inboxes the error message should explain you the reason. Attachment too big, mail in an unkown format (encrypted for eg.),…

Question: Is there a way to disable Mail to Ticket automatically deleting e-mails when closing tickets?
Answer: Not easy. A solution could be to set the Log in read-only when the Ticket is closed, as a result, when a new incoming mail related to that Ticket is processed, it fails to update the ticket, it is flagged in error and kept in the Inbox…

Question: We are missing e-mails from users that reply to tickets that have already been closed, what can we do?
Answer: There are different strategies to this issue

• One solution is to re-open the closed Ticket and reassign it (not nice if the answer just contains a simple “thank you”)
• Another solution is to activate a notification to the agent on closed tickets with the content of the last log entry, so they can decide what to do with it: ignore or open manually a new ticket. That last action could be facilitate with a User action Configuration entry, which could create a new ticket from the closed one, reusing the last log entry as the description of the new ticket, and copying all other pertinent fields.