MQ messaging architecture for managing rejected messages

I am having some difficulty deciding between 2x approaches to managing the rejection of messages on an MQ client. Admittedly, it's more an ideological argument than a technical one.

Consider this: a message (XML) on a queue is read by a client. The client checks the digital signature (and, by extension, whether the message adheres to a certain schema), before further processing. Let's say the verification of the digital signature fails though. I don't want the message to be further processed. It needs to go back to source and be sorted out 'by hand'.

As far as I can see, there are 2x approaches I could take:

Option 1

Client reads message
Client acknowledges receipt
Client discovers message is somehow invalid

Client writes invalid message onto 'reject' queue

                  CLIENT   MQ CLIENT
                   READ    +-------+        +----+ 
   OUT Q | --- | --------> |PROCESS| -----> |NEXT| 
         | --- |           |MESSAGE|        |STEP| 
         +-----+           +-------+        +----+ 
                               | 
                               | 
REJECT Q | --- | <-------------+ 
         | --- |     FAILURE
         +-----+

Option 2

Client reads message
Client discovers message is somehow invalid
Client does not acknowledge receipt of message

MRRTY = 0 (?) so QM writes message onto reject Q

                   CLIENT   MQ CLIENT
                    READ    +-------+        +----+
   OUT Q  | --- | --------> |PROCESS| -----> |NEXT|
          | --- | <-------- |MESSAGE|        |STEP|
          +-----+  FAILURE  +-------+        +----+
             |
             |
             V
REJECT Q  | --- |
          | --- |
          +-----+

I'm biased towards Option 2, where the QM is responsible for writing failed messaged onto a reject queue, as it seems to me to be a neater solution. This would also mean that the comms to the client is in one direction only. I understand the CLIENT_ACKNOWLEDGE is for the receipt of all messages up to point of acknowledgement: Am I misguided in thinking that ACKing per-message would be the mechanism that would allow me to have the QM write failed messaged onto the rejected Q per MRRTY parameter?

Any opinion / discussion re standard patterns / architecture much appreciated.

Solution

Thanks to both Morag and Attila for their help and input.

What it came down to was essentially this:

The application should handle the application errors, and a malformed message is an application error. The queue manager should only handle transport errors. (Attila)

and this...

There is no mechanism for having the queue manager route a failed message to a side queue. It is the responsibility of the application. (Morag)

So in the case of application errors the client itself will be expected to write failed / malformed messages back onto a separate queue out-of-band.