OAM Security the only thing protecting you in the end whether the Edge QM is in the internal cluster or not.
It can be QMZ-->EDGEQM-->THISQM-->THATQM-->GATEWAYQM
If OAM Security isn't correct at EDGEQM, they'll get to THISQM, and if its wrong there, they can get to THATQM, and if its wrong there, they can get to GATEWAYQM.
I'd like to understand if there is any vulnerability in having EDGEQM and GATEWAYQM be one and the same that can't be mitigated by proper OAM rules and MCAUSER values on secured incoming channels. If we can avoid the costs of an additional QM and be no less secure, I'd prefer one less QM in the environment and one less hop in the route between companies.
I'd never allow the QMZ QM in my cluster.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Friday, June 06, 2014 8:34 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: How do you get a QM to QM Alias itself
OK, I see what's going on now.
That's clever... devious AND clever.
The security check is still against the QR, which then resolves to the cluster visible qmgr alias, but you don't have to grant access to that, because MQ only performs the security check against the original queue name.
I think it will work for you. I would still prefer personally that my external gateway queue manager wasn't in an internal cluster because qmgr names have to be resolvable, and only OAM security is protecting you, but that is a matter of whether you need a belt and braces, or feel comfortable with just one layer of protection.
All the best.
Regards,
Neil C.
On 6 Jun 2014, at 10:18 pm, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>> wrote:
Neil,
I don't think the security hole is there.
If Company Z defined the ATTACK.VECTOR queue as you describe below
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)
the RCVR channel in EDGEQM will attempt to resolve to the FROMZ object, which the User ID the RCVR channel is running as does not have access to. The message will go to the DLQ with a 2035, and an Authority Event will be generated by the EDGEQM (if Auth Events are enabled like they should be). Testing confirms this.
If Company Z then tried this
define qr(ATTACK.VECTOR) +
rqmname(EDGEQM) +
rrname(ANY.QUEUE.NAME.YOU.WANNA.TRY.PUNK)
xmitq(EDGEQM)
any attempt to use this would also end up in the DLQ with a corresponding Auth event.
Company Z can only address the specific queues I intend them to use on EDGEQM, because the channel they are restricted to can only put to a very specific subset of queues that only exist on EDGEQM. I do not need to give them access to the S.C.T.Q. or the clustered QM alias names on the internal QMs.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Thursday, June 05, 2014 6:59 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself
Hi Peter,
I believe your plan will work, but is exposing a security hole, albeit perhaps a small one, depending on your point of view.
Since the routing to QMB and QMC is now via the QMgr alias, instead of via the QName, your OAM rules on EDGEQM will have to grant +PUT +SETALL access to FROMZ to the MCAUSER of the incoming channel from QMZ. I believe FROMZ is the profile which will be checked, not THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF, and in fact, THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF doesn't need to be exposed in the cluster at all. Its definition won't get used.
So, If the administrators of QMZ were to create a new QRemote pointing to EDGEMQ:
define qr(ATTACK.VECTOR) +
rqmname(FROMZ) +
rrname(SYSTEM.ADMIN.COMMAND.QUEUE)
xmitq(EDGEQM)
Then the message will flow to EDGEQM, be routed to FROMZ (which is actually QMB or QMC) via the cluster (which will be allowed). The message will only be blocked when arriving at QMB or QMC by well planned OAM rules and MCAUSER configuration at those queue managers.
So if nothing else, QMZ could manage to place messages on the DLQ of QMB and QMC either by putting to non-existent queues, or by putting to queues which it doesn't have access to.
Either way, my view of the purpose of having a gateway queue manager is to block access attempts at it, and not allow the potential for messages to flow through to queue managers closer to the heart of your organisation unless they are explicitly permitted. Allowing routing to queue managers via a clustered QMgr alias violates that function of the gateway. The same exposure would be in place if you granted access to the channel to put messages to a conventional (distributed) queue manager alias too.
So, to recap, your plan should work, but allows messages to flow to QMB and QMC which should not reach there. Even though OAM should block the messages from reaching non-permitted queues, your are still exposing core queue managers to exposures that should be blocked at the gateway.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
<image001.jpg> +61 414 615 334<tel:+61%20414%20615%20334><image002.jpg> neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
On 6 Jun 2014, at 1:33 am, Potkay, Peter M (CTO Architecture + Engineering) <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>> wrote:
I got it to work without introducing any additional QMs, or compromising security, or making the 3rd party change their remote queue def. Let me know if there are any holes in the below design.
On QMZ they have the following remote queue. This is unchanged.
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('EDGEQM') +
XMITQ('EDGEQM')
On EDGEQM I do not delete the Remote Queue Def, I alter it to look like this:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('FROMZ') +
XMITQ(' ')
I do not create an Alias queue of any kind on EDGEQM.
On QMB and QMC I still have the clustered destination queue THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF'
But then I add this to QMB and QMC:
DEFINE QREMOTE('FROMZ') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ') +
CLUSTER ('My ClusterName')
And now that remote queue def on EDGEQM load balances to QMB and QMC, and the remote queue def at Company Z remains unchanged. And the RCVR channel from Company Z still only has access to the DLQ and the one queue.
It seems to work fine, just worried about unintended consequences or security gaps. Seems kinda simple now, makes me wonder what's wrong with it.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Thursday, June 05, 2014 11:18 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself
"define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster."
The final destination queue is on QMB and QMC (called 'THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') and its already clustered. So I'll skip the step of definining another Q Alias on QMB and QMC - not sure what it buys.
"define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM"
I tried the following, since that is the clustered name
"define QREMOTE ('FOR.COMPANYZ') RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') RQMNAME('') on EDGEQM"
But it throws a MQRC 2087 when you try and put to it - Unknown Remote QM. It won't take a blank RQMNAME.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 10:12 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself
Ok.
define qalias('FROM.COMPANYZ') on QMB and QMC. Share it in the cluster.
define QREMOTE ('FOR.COMPANYZ') RNAME('FROM.COMPANYZ') RQMNAME('') on EDGEQM
note the difference between FOR and FROM.
Don't currently have a cluster I can play with, but this should do the trick.
Thank you,
Jeff Lowrey
From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>
Date: 06/05/2014 09:06 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________
Jeff,
Company Z's Remote Queue def specifies EDGEQM as the RQMNAME, which is telling EDGEQM to only consider EDGEQM as potential targets for the message. This was fine when the destination queue on EDGEQM was a remote queue, but is a problem when we want/need to replace that with an Alias queue on our end.
If we cluster the destination queues on QMB and QMC, even though EDGEQM might see the clustered instances on QMB and QMC, its not free to load balance to them.
I thought a simple QM Alias on EDGEQM would wipe the destination QM from the incoming messages but apparently you can't QM Alias a QM to itself. The below def when created on EDGEQM:
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
is ignored by EDGEQM. As soon as it sees its own name as the destination QM in the incoming message it gives up on any funky happenings with changing the destination QM by aliases.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Thursday, June 05, 2014 9:48 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself
What happens if you make FOR.COMPANYZ a QALIAS on both QMB and QMC and then share it in the cluster?
Thank you,
Jeff Lowrey
From: "Potkay, Peter M (CTO Architecture + Engineering)" <Peter.Potkay-***@public.gmane.org<mailto:Peter.Potkay-***@public.gmane.org>>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80Ties2YCUG/***@public.gmane.orgniwien.ac.at>
Date: 06/05/2014 07:47 AM
Subject: Re: [MQSERIES] How do you get a QM to QM Alias itself
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org<mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>>
________________________________
Tim,
I did the following:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')
And the messages just sit in the S.C.T.Q. on HIGEDGED1. I guess this is expected - we forced the messages into the S.C.T.Q with the Remote Queue Definition specifying the XMITQ to use, but there are no cluster channels looking for messages for 'BOBLOBLAW', so the just sit there. I don't think its ever appropriate to specify 'SYSTEM.CLUSTER.TRANSMIT.QUEUE' in the XMITQ parameter of a remote queue def. If the message won't resolve on its own into the SYSTEM.CLUSTER.TRANSMIT.QUEUE, then forcing it there won't work either.
I tried both of these on EDGEQM, but then get messages in the DLQ on EDGEQM with 2091 XMIT queue type error, and the Destination QM still showing as EDGEQM
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ(' ')
DEFINE QREMOTE('BOBLOBLAW') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
I don't think there is any way to make a remote queue definition >>>defined on a QM in the cluster<<< load balance to the queues on other QMs in that same cluster.
Neil,
If I can get this to work thru an pre defined Alias queue on EDGEQM, and the MCAUSER on the RCVR channel from the business partner only has access to that Alias queue , the DLQ and nothing else, I think its secure.
But I think I'm stuck if the remote queue def on the 3rd party QM specifies the name of the EDGEQM in the RQMNAME field. It eliminates the use of an Alias queue on EDGEQM, and forces the use of a Remote Q on EDGEQM, which doesn't allow load balancing to occur. <:-/
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Tim Zielke
Sent: Thursday, June 05, 2014 8:10 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself
Hi Neil,
BOBLOBLAW does not exist anywhere. It is just garbage text, but something that is not spaces. I got an error in my testing when the RQMNAME was spaces.
From a security perspective, I am thinking QMZ still only has access to PUT to FOR.COMPANYZ, with the current qremote set up. So they really can only access the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue in the clustering that QMEDGE participates in, via the qremote definition on QMEDGE. So I would think they are still limited to just accessing the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF queue.
Thanks,
Tim
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Neil Casey
Sent: Wednesday, June 04, 2014 10:49 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: Re: How do you get a QM to QM Alias itself
Hi Tim,
this is interesting, but I am shocked that it would work. I would expect the resolution of BOBLOBLAW to fail, and the message to end up on a DLQ on QMEDGE.
Did you define a queue manager alias BOBLOBLAW on QMB and QMC, and publish it in the cluster? I would expect that to work, but it doesn't do a good job of locking down the security, as it could be used to target any queue on QMB or QMC (although hopefully the OAM rules would prevent the messages actually reaching vulnerable queues).
Actually, from a security perspective, having the gateway in a cluster is a problem, because without an exit, there is nothing to prevent the 3rd party from trying to send to any queue on any cluster connected queue manager. Only OAM rules would stop the messages from arriving.
Without using an exit, a properly secure way to configure this would be to add a new cluster gateway queue manager between QMEDGE and QMB/QMC so that QMEDGE is not a member of the cluster. This also solves the resolution problem as the QR on QMEDGE can map the actual queue manager name to an alias which resolves to blank on the cluster gateway.
In other words:
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
would become
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMGWAY-->CLUSTER CHANNEL-->QMB or QMC
The QMZ queue definition is unchanged, and on QMEDGE, the QRemote changes to:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('NOQMGR') +
XMITQ('QMGWAY')
On QMGWAY, there is a QMgr Alias to map NOQMGR to a blank name:
DEFINE QREMOTE('NOQMGR') +
RQMNAME(' ') +
RNAME(' ') +
XMITQ(' ')
And QMB and QMC advertise THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF into the cluster.
Regards,
Neil
--
Neil Casey
Senior Consultant | Syntegrity Solutions
<image001.jpg>+61 414 615 334<tel:+61%20414%20615%20334><image002.jpg> neil.casey-VLLIzlmz+***@public.gmane.org <mailto:neil.casey-VLLIzlmz+***@public.gmane.org>
Syntegrity Solutions Pty Ltd<http://www.syntegrity.com.au/> | Level 23 | 40 City Road | Southgate | VIC 3006
Analyse >> Integrate >> Secure >> Educate
<image003.png>
On 5 Jun 2014, at 1:27 pm, Tim Zielke <tim.zielke-PR+tvw7B/***@public.gmane.org<mailto:***@AON.COM>> wrote:
Hi Peter,
I don't know how you feel about this change, but it looks like this would work (at least in my Sandbox test). Maybe this is too unorthodox:
Change the QREMOTE('FOR.COMPANYZ') on QMEDGE to the following:
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('BOBLOBLAW') +
XMITQ('SYSTEM.CLUSTER.TRANSMIT.QUEUE')
Make the RQMNAME something bogus but not spaces, and the clustering on QMEDGE should see the THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF on both QMB and QMC and load balance between them.
Thanks,
Tim
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, June 04, 2014 8:10 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgAC.AT>
Subject: How do you get a QM to QM Alias itself
QMZ is in another company, a company presumably infested with people who want to send messages to queues on your QMs that they have no business sending to.
QMEDGE is your internal QM that sits between your internal QMs and QMZ.
QMA is an internal queue manager that host a local queue called THE.LOCAL.QUEUE.FOR.QMZ.STUFF
QMZ-->SNDR/RCVR CHANNEL-->QMEDGE-->SNDR/RCVR CHANNEL-->QMA
There is a remote queue def called FOR.COMPANYZ on QMEDGE
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('THE.LOCAL.QUEUE.FOR.QMZ.STUFF') +
RQMNAME('QMA') +
XMITQ('QMA')
And on QMZ they have the following remote queue
DEFINE QREMOTE('FOR.COMPANYZ') +
RNAME('FOR.COMPANYZ') +
RQMNAME('QMEDGE') +
XMITQ('QMEDGE')
The QMZ.QMEDGE Receiver channel is running with an MCAUSER filler in with an ID that only allows puts to happen to FOR.COMPANYZ.
Everything is fine. Company Z can only send to the remote queue we set up for them on QMEDGE, and all other queues on QMEDGE and QMA are safe from Company Z. And they don't even know the name of the final queue.
Here's the topology change and my question.
QMB and QMC are internal QMs, and they are in the same MQ cluster as QMEDGE. QMZ and QMA are not and will not be in this MQ cluster.
QMB and QMC host a clustered local queue called THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF.
We have to direct traffic thru QMEDGE to QMB and QMC and no longer to QMA. And QMZ should not have to change anything. Oh boy.
The remote queue def on QMEDGE must be deleted - I can't figure out how to have a remote queue on a clustered QM aim at clustered queues on other QMs in that cluster and get load balancing. (if you know a way stop reading now and lemme know!)
But if we replace that remote queue def with an Alias queue of the same name, it can load balance. On QMEDGE I delete the remote queue def and replace it with:
DEFINE QALIAS('FOR.COMPANYZ') +
TARGET('THE.NEW.LOCAL.QUEUE.FOR.QMZ.STUFF')
I use amqsputc to put to this alias queue, I get load balancing to QMB and QMC, and I'm feeling good.
Company Z starts putting to their remote queue and the DLQ on QMEDGE starts getting messages with 2082 - Unknown Alias Base Queue. Their remote queue def specifies QMEDGE as the destination QM. That locks in the name resolution to QMEDGE and doesn't allow the Alias queue def to pass the message thru and into the cluster.
I thought I could fake it out by defining the following QM Alias on QMEDGE, thinking maybe it would replace the Destination QM name of QMEDGE with blanks and thus allow load balancing.
DEFINE QREMOTE('QMEDGE') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But this has no effect. Apparently in the Name Resolution chain if the destination QM is the same as the local QM, it skips any QM Alias magic.
A change on QMZ that works is changing RQMNAME to ('QMEDGEx'), then defining a good ol' fashioned QM Alias on EDGE QM called QMEDGEx.
DEFINE QREMOTE('QMEDGEx') +
RNAME(' ') +
RQMNAME(' ') +
XMITQ(' ')
But I don't want to have to make Company Z change anything. How do I get around this without making a change on QMZ? I thought a QM Alias to itself to blank out the QM name would work, but no luck. I was hoping I could stay with Remote Queue Defs but they don't allow load balancing apparently.
Peter Potkay
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>
Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>
************************************************************
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential and/or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
************************************************************
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html