Exception Queue 101

From DocWiki

What is it?

The Exception Queue is a standalone queue in EIM that serves as a bucket for all emails meeting certain conditions such as Delivery Exceptions or system routing failures. Emails can be "Picked" form the Exception Queue by:

1. Standalone Users with the Administrator role
2. Integrated users with the Administrator role.
3. Standalone Users without the Administrator role, but with permissions for the Exception Queue:

• These users can also "Search" for activities in the Exception Queue if they know the activity_id or case_id.

• Note that without permission for the Exception Queue, the agent can only view the details of the activity.

How is it different from nIPTA?

The Exception Queue is a purely standalone queue that is not mapped to anything in UCCE.

However, it can still be triggered in a similar way. If an integrated customer does not configure nIPTA Skill Groups/Queues, failed tasks will be sent to the Exception Queue.

Customers can also purposely script this logic by using the same concept described in the "nIPTA Basics" section. Tasks can be routed to LBL_Exception_Queue, and EIM will strip the LBL_ and match Exception_Queue.

Delivery Exceptions

Think of Delivery Exceptions as EIM's fundamental spam filter. Out-of-the-box, EIM is configured to route mails with certain strings in the sender's address or subject line directly to the Exception Queue. For example, "postmaster@cisco.com" or "Warning - Delayed Mail". The 4.3 Administrator's Guide to Email describes the two types:

• Permanent: Indicates that an irreparable reason, such as an invalid email address, caused the email to bounce back. These are permanent failure conditions and any email sent to such email address would always bounce back.
• Temporary: Indicates that a temporary reason, such as an out of office reply or a temporary unavailability of the destination server caused the email to bounce back. The inference here is that should the emails be sent again, there is a chance that they may be delivered.

These mails will have an activity_sub_type of 4 or 5, which means that if they are transferred to an integrated queue, EAAS will not pick them up since activity_sub_type != 1. These mails will sit in the the queue on EIM indefinitely, and eventually raise concern with users that emails are "stuck."

Some pre-defined Delivery Exceptions are below. For the full list, reference the 4.3 Administrator's Guide to Email.

Examples from retriever logs:

2011-07-11 12:30:33.872 GMT-0400 <@> WARN <@> [73:RxInstance id : 999] <@> ProcessId:4640 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.mail.module.retriever.service.RxProcess <@> checkForUndeliverableEmail <@> UNDELIVERABLE_SUBJECT :  Nondeliverable <@> 
2011-07-11 12:31:05.950 GMT-0400 <@> WARN <@> [73:RxInstance id : 999] <@> ProcessId:4640 <@> PID:1 <@> UID:12 <@> HttpSessionId:  <@> com.egain.mail.module.retriever.service.RxProcess <@> checkForUndeliverableEmail <@> UNDELIVERABLE_SUBJECT :  Ontvangstbevestiging <@> 

Routing Failure

One severe example of queued integrated emails going to the exception queue is a dual Router failure with no nIPTA labels/queues configured. When the router process fails, the activities will fail to a nIPTA label if defined. For customers that don't use nIPTA, the mails will instead go to the exception queue.

Malformed Emails

Under certain conditions, spam or Exception emails are written to a file instead of the eGActiveDB.

• C:\CIM\eService\logs\RxSpamEmails.txt
  • Incoming messages with "From" addresses that match blocked addresses configured for the EIM department.

• C:\CIM\eService\storage\1\mail\Exception Emails\RxExcepEmails.txt
  Messages are not according to RFC 822 message standards. For example:
  • Content type field is missing from the message header.
  • Message ID is missing.
  • There is no start boundary.
  • The mail header character set value is not recognized by Java Mail. For example, it contains characters like “iso 8859-1” where as the correct format is “iso-8859-1”.

The settings which decide how to handle these mails are at the Partition-level.

Getting Emails Out

Once you understand the reasons why an email enters the Exception Queue, you can determine how to get it out.