Reading emails

When receiving emails for existing tickets, the INETAPP requires a reference to this ticket. The following parameters allow various settings to make this reference as unique as possible for external systems.

A supporter can send an email from a ticket. In this case, the INETAPP server automatically inserts the following combination into the subject of the e-mail:

• the keyword TicketID + specific ticket number + a string of letters.
• e.g. TicketID 3246MKHH.

When replying by email, the INETAPP server recognizes from this keyword that the email is a reply to an existing ticket. Therefore, the ticket number and a letter string are expected after the keyword.

You can now place one or more characters before and after the combination to mark this part of the subject as not relevant for the user but presumably "technically necessary".

In the following example, an opening and closing square bracket have been used respectively, which are displayed for order number 500 with the keyword TicketID: [TicketID 500OOJ]

The term TicketID appearing in the subject of a sent mail can be replaced by another letter number sequence WITHOUT spaces. Each term in the list will be interpreted as a keyword. The term TicketID will always be considered as a keyword. In future reply emails to the i-net HelpDesk, all terms in the list will be evaluated in the subject.

With the button Add ticket ID format an alternative keyword is added.

• Example: Previously "TicketID" and now the new term "OrderNo".

Important: Alternatively, select a keyword as a term that is usually NOT included in the subject of an email. Not recommended is, for example, as a keyword ID. If the i-net HelpDesk server now reads an e-mail that contains the string ID in the subject, among other things, then an order number plus letter sequence is expected behind it. If this information is missing, the e-mail is rejected as invalid. The sender receives a corresponding e-mail.

The Unique Server ID is used to expand the ticket numbers in sent e-mails to ensure that the e-mail is intended for the current i-net HelpDesk server in case of subsequent replies with this ticket number and server ID combination. This server ID is initially created automatically, but can be customized by the administrator as desired.

The concrete ticket number for the email is created using the following rule: XXXYYZZZ, where:

• XXX is the ticket number, of any length, determined by the i-net HelpDesk server.
• YYY check character with the same number of characters as the ticket number.
• ZZZ additional server ID with any number of characters.

By default, the keyword TicketID plus order number and letter string are placed at the end of the subject. This behavior can be changed here.

The INETAPP can communicate with foreign service desk systems. The problem is not so much possible auto-reply "ping-pong" loops, as the INETAPP only sends an auto-reply initially when a new ticket is created.

Further information

The i-net HelpDesk server automatically retrieves emails from one or more mailboxes. The retrieval interval can be defined here. It is also possible to have the email reception date set as the request date, and to expand the positive list of permitted file types in attachments.

By default, the INETAPP server retrieves the assigned mailboxes every 10 minutes. You can change this time interval here, usually to a single digit lower minute range.

The number of times the connection to email servers is retried, before an error notification will be sent. The connection is checked respecting the polling intervall. That means, error notifications are sent only after <Polling Interval> x <Tolerated Failures +1> minutes.

When activated, the date of email reception is used as inquiry date instead of the date reading the email.

Normally, an email from the mailbox is immediately read in as a ticket by the i-net HelpDesk server within the retrieval interval. In the following exceptional case, the checkbox Email receipt date as request date helps:

• The INETAPP service is not available, e.g. on weekends.
• Now a customer writes a support email during this period.
• Since the INETAPP service is not running, the customer's email remains in the mailbox.
• On Monday morning, the i-net HelpDesk service is started again, it reads the mailbox and creates new tickets.
• Now the date of ticket creation is taken as the date the email was received in the mailbox.

The following is also affected:

• Date of 'Email received' steps
• Check if the reactivation of a ticket is allowed according to the configured interval
• Date of recalculation of the deadline on reactivation if recalculation of the deadline is activated.

If the i-net HelpDesk is reading more than one mail account, it may happen that users send one and the same email to multiple accounts. With this option activated such a mail is being read only by the first email account. The first account is the one that appears first in the To: recipient field in the email.

Note: Mailboxes are assigned to recipient addresses via the Account Email Address, which is assigned to each mailbox in the configuration. If no email address is entered there, these mailboxes cannot be considered for this function.

Note: Only single emails sent to multiple mailboxes can be intercepted with this. Multiple identical emails, each going to a different mailbox, cannot be detected.

Tickets in INETAPP can be changed by incoming emails. This is useful, for example, if an external support company does some additional work and sends the result to the INETAPP via email. The parameters for recognizing the data field as well as the value to be set (key-value pair) is set in this dialog.

Additional information

The INETAPP can automatically recognize incoming emails as auto-responses or automatically generated if they are marked accordingly. These are often automatic replies (auto-reply) from external systems, out-of-office messages from people who are currently on vacation, generated circulars, advertising or other generated emails. In these cases, the incoming email is read, but it often makes sense to change the reaction, e.g. not to send automatic replies or not to reactivate tickets.

If the checkbox is deactivated, no rules for recognizing automatic replies are applied.

The table lists the headers with their values for which the INETAPP deviates from the standard behavior.

There are two possible actions as a deviation:

• No auto-response: No automatic responses are sent to the sender.
• No auto-response and leave ticket unchanged
  • No automatic responses are sent, to either sender or resources.
  • If the associated ticket is still open, it is not marked as unread.
  • If the associated ticket is closed, it will not be reactivated.
  • If no related ticket can be found, a new ticket will still be created, but without sending an automatic email.

A line of the table represents a rule: IF header X contains/is/is not Y, then apply action Z. The rules of the table are checked from top to bottom, if a condition applies, this action is applied and no further rule is checked. Upper/lower case is ignored.

The following headers are defined as default values. If the recognition for your communication does not work as expected, please check the headers in the emails from your mail server(s).

Note: The "From" header indicates the sender address of the email.

The Auto-Submitted header with the value auto-generated may require a special handling. According to RFC 3834, the value auto-generated is to be used for emails that are sent by automatic processes or programs without the direct interaction of a user. It must not be used for automatic email replies to incoming emails, as the value auto-replied must be used for this.

In our experience, however, it is not uncommon for automatic replies such as OutOfOffice-replys to be mistakenly assigned the value auto-generated to the Auto-Submitted header. If this is the case, please contact the sender of these emails and ask them to set the Auto-Submitted header for auto-replies correctly in accordance with RFC 3834.

If the sender cannot or does not want to do this, or if there are many different senders with this problem, then you can also change the rule for this header in the INETAPP at your own risk by adding a line before Auto-Submitted is unequal no → No auto-email:

This means that all emails generated by programs will probably no longer set tickets unread or reactivate tickets in your INETAPP.