Maileater

To make corrections or additions to this article, select the edit tab above.
To discuss or ask questions about this article, select the discussion tab above.

Overview

This article provides details about the maileater functionality. Maileater is a legacy feature used to create and update tickets via an email. It is very limited in its flexibilities and is best for automated ticket creation by enterprise systems that are not web services capabilities. Although it is an aged and outdated practice, many company's rely on email as a source for ticket generation, and thus rely on maileater to automate ticket creation.

How it Works

Once enabled, Maileater will access the specified email inbox via POP3 or IMAP. All emails in the inbox are processed. Emails that are properly configured and contain the required information will generate new tickets or update existing tickets. An email is sent verifying a successful creation or update. Emails that are properly configured but are lacking required information, such as any required fields, will generate an a failure email. Emails that are improperly configured have no reply email generated. All emails that are processed are deleted from the inbox.

Enabling maileater

Maileater is enabled via the Options Manager. All maileater options are with the word maileater.

Understanding text_api

Maileater is driven by the text_api.cfg. All the values that can be set via an email can be found in the text_api. Additional attributes can be added to the [KEYWORDS] section of the text_api to allow for setting custom fields or alternate methods of setting default fields.

The sections specific to Maileater are [EMAIL_DEFAULTS] and [EMAIL_IGNORE_INCOMING].

• [EMAIL_DEFAULTS] are used to consistently set the same value for all email generated tickets. For example, if you always want a specific initial Priority level, then identify it here. This eliminates the need for having to account for the Priority in the body of the email. However, any values identified in the email take priority over those set in [EMAIL_DEFAULTS]. In other words, the [EMAIL_DEFAULTS] is a backup just in case the email does not contain any value for that particular variable.
• [EMAIL_IGNORE_INCOMING] allows you to identify fields that are not permitted to be set via an email. This can be helpful for maintaining standards.

Configuring the Email Message

An email message that Maileater is to process must have a precise configuration.

Subject Line
The Subject Line must contain either the word REQUEST, CHANGE, or ISSUE. See the text_api.cfg and see how items are all referenced in the same manner. Since the system will set the Affected End User based on the email account sending the email, the -m argument can be used to trump this functionality.

For example, If Gregg sent an email with REQUEST in the subject line, a Request would be created where Gregg is the Affected End User. But if he send an email with REQUEST -m gityerfix@servicedeskusers.com as the subject, then a Request would be created with Gityerfix as the Affected End User.

Body
The message body by default is treated as the ticket Description unless otherwise noted. To set other fields via the email use a format that coincides with the [KEYWORD] values identified in the text_api similar to this example: <source lang="text">%PRIORITY=1 %CATEGORY=ServiceDeskUsers %IMPACT=5 %DESCRIPTION=SDU is great</source>

Handling required fields

There are two ways to handle required fields.

1. Account for them in the email body.
2. Account for them in the text_api.cfg in the [EMAIL_DEFAULTS] section.

Limitations

• No way of setting the Parent. If there is a way of doing this, it is a well guarded secret.

• Dependent on intelligence of the sender. This means that Service Desk has no way of knowing what the correct values should be if enter incorrectly, and no way way of knowing that multiple emails from an auto-generating system are regarding the same issue.

• Only one existence of the user's email. If the -m argument does not exist in the subject line of the email, then the FROM ADDRESS is used to determine the End User of the ticket. The system will look for the existence of that email address and the contact record containing that email address becomes the Affected End User. However, if there are multiple instances of the email address, problems can occur.

Best Practices

1. The best practice is to restrict the use of Maileater to the auto-generation of tickets via systems that do not have web services capabilities. Web Services is a much more flexibly method of automating ticket creation. Web Services is a direct A to B communication, where as Maileater is A to B to C where B is the mail system. Consequently using maileater adds an addition point of failure.
2. Promote level 0 support. While email support is cheaper than phone support, self-help is the absolute cheapest. And in order to promote self-help you have to get the users to utilize the application. Using maileater does not help to promote this directive and only results in users being dependent on an outdated and archaic form of support.
3. If you do elect to utilize Maileater, have a dedicated email address used exclusively by Maileater. As Maileater processes emails it deletes them from the inbox. For this reason, it is not practical for the Maileater inbox to be used by anything (or anyone) else.