Exception Queue 101
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:
- Standalone Users with the Administrator role
- Integrated users with the Administrator role.
- 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.
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, "email@example.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 <@>
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.
Under certain conditions, spam or Exception emails are written to a file instead of the eGActiveDB.
- 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.
|Where is it?||activity_sub_type from egpl_casemgmt_activity in eGActiveDB?||Why did it go there?||Using an Integrated or Standalone User to get it out?||Administrator Role?||Permission for Exception Queue?||Destination?||How?|
|Exception Queue||1||Routing Failure||Integrated||Yes||N/A||Integrated Queue||Click "Pick" and choose the Exception Queue, then find the mail. Handle the mail as that agent, or transfer it to the destination queue.|
|Exception Queue||1||Routing Failure||Standalone||No||Yes||Standalone Queue||Click "Pick" and choose the Exception Queue, then find the mail. Handle the mail as that agent, or transfer it to the destination queue.|
|Exception Queue||4 or 5||Delivery Exception||Integrated||Yes||N/A||Integrated Queue||Click "Pick" and choose the Exception Queue, then find the mail. Mail must be handled by that agent. If mail is transferred to an integrated queue, it will never be routed by EAAS and will appear as "stuck" to users looking at queue load.|
|Exception Queue||4 or 5||Delivery Exception||Standalone||No||Yes||Standalone Queue||Click "Pick" and choose the Exception Queue, then find the mail. Handle the mail as that agent, or transfer it to the destination queue.|
|nIPTA Queue||1||Routing Failure||Integrated||Yes||N/A||Integrated Queue||Log in as nIPTA Agent, go ready, and receive email waiting in queue. Handle the mail as that agent, or transfer it to the destination queue.|
|C:\CIM\eService\logs\RxSpamEmails.txt||N/A - Not in DB||Blocked "From" address||N/A||N/A||N/A||Standalone or Integrated||No defined procedure available.|
|C:\CIM\eService\storage\1\mail\Exception Emails\RxExcepEmails.txt||N/A - Not in DB||Malformed email content||N/A||N/A||N/A||Standalone or Integrated||No defined procedure available.|