MQ Advanced Message Security – part of MQ Advanced – requires an error queue to store undeliverable messages. This works similar to the dead-letter queue (DLQ) where AMS routes messages that cannot be processed to this queue. Messages which are suspected to be tampered with or that cannot be processed properly due to various reasons are placed in the SYSTEM.PROTECTION.ERROR.QUEUE. AMS error queue processing only occurs when an MQGET call fails for the reasons listed in the Knowledge Center (KC).

All messages that cannot be processed by AMS are prefixed with the MQ dead-letter header structure, MQDLH. The MQDLH header is filled with much information and the details are mentioned in the KC. In order to process messages from a DLQ, either runmqdlq which is shipped with MQ can be used or a dead letter queue application can be written, taking into consideration a few set of things as described in the below link:

https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.0.0/com.ibm.mq.dev.doc/q029190_.htm

Although SYSTEM.PROTECTION.ERROR.QUEUE is similar to the DLQ in many ways, it differs in some ways, one being that the messages in this queue are all AMS messages which are encrypted and can be processed only by authorized users. Which means if MQ Admins want to retrieve messages from this queue then they should be a part of the authorized group.


How to handle the message in the error queue

In order to process the messages present in the SYSTEM.PROTECTION.ERROR.QUEUE, the recommended way is to run the DLQ handler from an authorized user and send the message to any queue using the rule to forward the message to some other queue, something similar to
“ACTION(FWD) FWDQ(‘Q’) FWDQM(‘QM’) HEADER(NO)”.
Again I would repeat, ONLY authorized users should access the messages in an AMS system, any other solution is not recommended. If MQ Admin cant be authorized then one of the other authorized users should run the DLQ handler.

Users can also write an application which can monitor the error queue and then read the header to examine the reason field and do necessary action. Even runmqdlq can be used in this case however the user should be authorized to get the message. In any end to end encryption solution, nobody except the intended recipient can view the message – even if they’re an MQ admin. It presents a much higher level of security. If MQ admins need to see the unencrypted body of the message then they need certificates and be configured as recipients of the messages. If the messages need to be moved or discarded then a QALIAS can be used which is not protected by an AMS policy.

Note that above methods are suggestions for handling with messages in the error queue in a particular situation. But in an ideal production system, any unintended user trying to access a message points to an attempt to tamper the message and hence will be put to the error queue. Such tampered messages will ideally be of no use to be put back to the destination queue without proper introspection. Hence I would not see a reason for this information becoming a standard method as can be suggested in any MQ manuals. This information should be treated for test and other purposes where such needs can arise.

1 comment on"Handling Messages In The IBM MQ Advanced Message Security Error Queue"

  1. Of course, not all messages on the SYSTEM.PROTECTION.ERROR.QUEUE are AMS protected, as one of the reasons a message might end up there, is because it was unprotected on a policy protected queue where the policy has no toleration for non-protected messages.

Leave a Reply