Going back to this.
>> But if the first thing MBX or the Toolkit did is issue a command to get a
list of what the user was authorized to see, then the GUI tool could only
paint the screen to show those objects. At that point the GUI tool is not
banging its head every x seconds asking to see or open something it has no
need to and that the user did not ask it to do. And at that point you are
not showing the user things the user can't access anyway.
That's what the GUI is trying to do now. The behavior change doesn't need
to be on the client side. When a client does DIS [object type](*) the QMgr
can omit throwing the 2035 and just return the list of authorized objects.
If the inquiry subject is * then this would be fine. But if the inquiry
were more specific, then throw the 2035 if a non-authorized queue is in
there. This not only prevents the errors, but it prevents enumeration of
the non-authorized objects and does not require re-mapping of authorizations
that should never have been based on +inq to begin with.
But this is a LOT different than suppressing 2035 errors globally, filtering
them in logs, etc. The goal is to not throw them at all for a routine and
necessary operation such as painting a screen in the official management
tool.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Wednesday, July 17, 2013 9:21 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMB 8 Broker Administration Security - Causes lots of MQ
Authority Events
"Unless you with to grant EG access to every user of WMQ Explorer, IR-360,
QPasa!, AppWatch, et., etc. every one of those programs would need to change
so as to inquire on auths rather than enumerating the queues with the PCF
equivalent of DIS Q(*)."
But these tools typically run under the authority of mqm because they
typically do need to see and do everything. Other than MQ Explorer,
restricting what these can do is handled in the tool via non MQ methods.
Using MQ Explorer in something less than an mqm capacity is a valid need
(since it's the only officially supported GUI tool IBM provides to manage
MQ), but it'll never be perfect because MQ Explorer was not designed from
the ground up to run under various levels of authorities. Each MQ Explorer
runs as its own instance and attempts to do the job it was written to do -
which requires mqm level authority. MO71 is the same way. But all those
other tools all rely on some central repository where the admin of that tool
can determine what each user of the tool can do.
"But setting that aside for a moment, let's say you use MBX to connect from
Windows to Linux and your windows user ID is mapped by CHLAUTH to a locally
relevant Linux account. How does MBX inquire as to what account it is
running as? Get a queue handle status on its reply-to-queue?"
I'm thinking it just asks "What can I see? What can I do?" and doesn't make
any assumptions as to what ID that session is running under. The MQMD User
Identifier of that What-Can-I-See message would contain the ID that the MQ
Admin decided (thru any number of methods) that this session should run as.
The response from the Broker gives that Toolkit session a reply message that
first tells the user what ID was used for granting authority, and then a
list of resources it has at least +inq authority on. That's all that get's
displayed in the GUI. If the user then tries to do something against those
objects that is more than +inq and they only have +inq on that object, to me
that is a legitimate Authority Event type situation (as Mr.Tony would say).
Or, since the TK and MBX could know exactly what the user can and can't do
at that point, the GUI could only allow the user the options to do things
they can do and not give them extra rope to hang themselves.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
T.Rob
Sent: Tuesday, July 16, 2013 7:58 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMB 8 Broker Administration Security - Causes lots of MQ
Authority Events
That's assuming the MBX or Toolkit is the thing generating the error
messages. Unless you with to grant EG access to every user of WMQ Explorer,
IR-360, QPasa!, AppWatch, et., etc. every one of those programs would need
to change so as to inquire on auths rather than enumerating the queues with
the PCF equivalent of DIS Q(*).
But setting that aside for a moment, let's say you use MBX to connect from
Windows to Linux and your windows user ID is mapped by CHLAUTH to a locally
relevant Linux account. How does MBX inquire as to what account it is
running as? Get a queue handle status on its reply-to-queue?
That seems to me like a helluvalotta complexity compared to creating some
ACL's in a queue similar to WMQ or AMS. We went through this with AMS, by
the way. There was no way to map queue permissions to AMS policy
(thankfully) so that wasn't tried ever, to the best of my knowledge. AMS
went straight to ACL's in a queue. At first, the code needed permissions to
browse the ACL's in the queue. Of course, this means the same user could
connect without AMS and browse the queue as well. Nowadays, the queue is
treated specially and the app simply uses the API and the QMgr access the
ACL's on its behalf. Now it's not necessary to grant the apps access to
browse the queue. WMB and FTE could and should go the same direction.
Ideally, these special queues would be hidden from the public API so that
non-mqm users would not see them when issuing the PCF equivalent of DIS Q(*)
and therefore no 2035 thrown.
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Potkay, Peter M (CTO Architecture + Engineering)
Sent: Tuesday, July 16, 2013 3:13 PM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMB 8 Broker Administration Security - Causes lots of MQ
Authority Events
But if the first thing MBX or the Toolkit did is issue a command to get a
list of what the user was authorized to see, then the GUI tool could only
paint the screen to show those objects. At that point the GUI tool is not
banging its head every x seconds asking to see or open something it has no
need to and that the user did not ask it to do. And at that point you are
not showing the user things the user can't access anyway.
Peter Potkay
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
T.Rob
Sent: Tuesday, July 16, 2013 6:24 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMB 8 Broker Administration Security - Causes lots of MQ
Authority Events
Unfortunately, the +inq queue authority has been mapped to WMB
authorizations. So anyone using WMQ Explorer would generate an auth errors
every time it needed to render the queues screen. Unless of course everyone
using WMQ Explorer is granted +inq on all queues. For people not needing
access to WMB it's arguably possible to not provide +put access to its
control queue. However, for people who legitimately require access to
broker, it's impossible to grant that with granularity since they must
either have +inq on *all* SYSTEM.BROKER.AUTH.EG queues or else generate
2035s all day long.
So in addition to switching to use PCF for the inquiries, WMB (or FTE or
anything else mapping WMQ auths to application layer security objects) must
NOT use +inq or +dsp in the mapping and leave these for exclusive use of
Explorer. (Or Omegamon, or whatever.)
-- T.Rob
From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Jefferson Lowrey
Sent: Tuesday, July 16, 2013 1:11 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMB 8 Broker Administration Security - Causes lots of MQ
Authority Events
There is a PCF request to list authorities these days. I strongly suspect
that it didn't exist when this feature was initially built, with the release
of Broker v7.
This would allow the Broker to find out what EGs a user is allowed to access
without trying to access the relevant queues, and thus avoid the authority
event. It would also allow the Broker to know, as it was determining what
EGs exist, whether the user was able to access that EG or not.
You might discuss this with your fine L3 technician, to see if this is a
workable solution.
It does leave a window open, where the initial connection could show that
the user has access to the EG, but subsequent authority changes are made to
block access. This could occur in such a way that the user wouldn't know
they didn't have access until they tried to view or modify the EG, thus
generating the authority exception.
Thank you,
Jeff Lowrey
IT Specialist, Consultant
Internet jlowrey-r/Jw6+rmf7HQT0dZR+***@public.gmane.org
From: "Potkay, Peter M (CTO Architecture + Engineering)"
<Peter.Potkay-***@public.gmane.org>
To: MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 07/15/2013 08:51 PM
Subject: Re: [MQSERIES] WMB 8 Broker Administration Security - Causes
lots of MQ Authority Events
Sent by: MQSeries List <MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
_____
MB Explorer is showing the same problem as WMB Toolkit for barfing up all
these Authority Events even though the user did nothing wrong. I have a PMR
open and they reproduced the problem and kicked it up to level 3.
I think if IBM was going to use just 3 permissions (Read, Write, Execute) to
control access to a couple of dozen tasks to various execution groups, they
should have had an Alias queue for each task / execution group. This would
have allowed the MQ Admin to set very specific permissions. The way it sits
now there is way too much overlap. If I grant +inq against
SYSTEM.BROKER.AUTH and +put against SYSTEM.BROKER.AUTH.yourEGnameHere to
allow a user to deploy to that execution group, they automatically get the
ability to do all of the following as well since the following tasks have
the same or fewer permissions.
View broker properties
View configurable services properties
List execution groups
View execution group properties
Set execution group properties
Delete resources from an execution group
Logon to the web user interface
That would solve one problem, the lack of granularity. But it still leaves
us dealing with the other problem of at least some Authority Events being
produced.
Its fine for the Toolkit to want to list all the Execution Groups. Every
user is going to have that most basic access if they have any access via the
TK or MBX - read access to SYSTEM.BROKER.AUTH. That is all that is required
to list execution groups. But why is the tool trying to inquire against each
execution group at that point if the user is not attempting to open the EG
in their GUI? This is what causes the flurry of events.
Alas it will never be fully remediated with this security model. For if the
user is presented a list of EGs sooner or later curiosity will drive them to
try and open an EG they are supposedly not allowed to (how would they know?)
and that will cause a somewhat legitimate event, to which the user might say
"Why do you show me that EG if I don't have access to it? In WMB 6.1 it was
flagged as restricted in my view so I knew not to go into it. And even if I
did attempt to expand it (and failed) you didn't get an alert every time I
tried". Entrapment!
Peter Potkay
From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Meekin, Paul
Sent: Thursday, July 11, 2013 7:26 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMB 8 Broker Administration Security - Causes lots of MQ
Authority Events
Of course the issue of MQ resource access not mapping fully to the chosen
security auth system is not new as seen by the inability of SAF on the
mainframe to distinguish between PUT and GET access since both are Update
operations.
But despite that, it sounds to me like what we need is SAF-like mechanism
that allows an authorised entity to check if Id A has the requested access B
to resource C.
At the risk of over-simplifying surely that can't be difficult to do -
instead of trying to open the specified queue why not simply query to see if
the user has access to the queue as per dspmqaut etc? As T. Rob says, a
failure to access the broker auth queues is a different type of event to a
failure to open a proper queue so there is no need to generate an MQ auth
event.
From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of T.Rob
Sent: 11 July 2013 00:34
To: <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMB 8 Broker Administration Security - Causes lots of MQ
Authority Events
You missed the point entirely. Yes, you are absolutely correct regarding
how WMQ functions with respect to access control. My point was that things
built on WMQ should not rely on WMQ's access control for application-layer
stuff.
The QMgr has a command queue.
The broker or agent has a command queue.
The QMgr authorizes requests in the command queue based on the identity in
the message.
The MFT agent and Broker authorize at least in part based on whether an
identity that is associated with the connection and/or with the message is
able to perform some arbitrary API call on a queue which exists for no other
purpose than to make WMQ API auths visible to the application layer above to
be used for application-layer things that have nothing whatsoever to do with
the queues to which they are attached.
See the difference?
This is roughly equivalent to the TSA requiring you to have a valid library
card at your destination city in order to fly there. If a city wanted to
have an airport, they'd then need to build a library first. Then people
monitoring the library patron activity would be scratching their heads going
WTF? due to all the unusual card verification activity showing up as DOS
attacks. Then you'd advise them how simple it is to ignore the alerts.
We have applications built on WMQ that wish to perform authorizations
against resources - agents and EGs - that have no direct counterpart in WMQ.
Instead of equipping them with an authorization mechanism that maps directly
to the application-layer objects requiring access control, the app resources
and API calls were mapped to objects in WMQ. The result, predictably
enough, is that the non-native mapping form one security domain to another
breaks and the administrator is forced to choose between getting notified of
security events or setting up granular security at the application level.
And, no it is NOT "a simple problem to either completely ignore these
warnings or take basic steps to identify these warnings as not meaningful."
Well, perhaps for you. But certainly not for the admin charged with
explaining to the auditor why they need to turn off notifications of
security relevant events. Or not for the same admin explaining to
management why they need to take time to try and identify all possible
events because the product has no capability of selectively suppressing ONLY
the ones related to WMB or FTE and because there is no definitive list, and
why these will pop up again and again every time someone adds a new agent or
EG. Turning off auths events GLOBALLY is not the answer. Making thousands
of customers individually responsible for ferreting out the solution, to
varying degrees of success, is also not the answer.
Just as those are not the answer, "the fact that MQ is a resource manager
and not an authorization server" is not the problem. The problem begins
with taking resources in one security domain and applying access control
from another, and is complicated by the fact that the two security domains
have unlike security models, unlike subjects, unlike objects, lack identity
propagation across the domains, and have no 1:1 correspondence for the
mapping.
Nor is this a choice between restoring the DB2 pre-req vs. dodgy security.
The broker or agent could implement a flat-file ACL database or store the
ACLs in a KDB. As long as WMQ continues to be a pre-req, , store the ACLs
in a queue. These queues might even be able to be designated as authority
queues, same as SYSTEM.AUTH.DATA.QUEUE, so that they do not themselves fire
off events.
I don't know if you remember but we've had this problem before. For several
years I told people in my articles and conference sessions to enable auth
events and to get everyone out of the mqm group. The first customer to
actually do this thought they were being attacked when they got thousands of
auth events a day. Turned out that EVERY time Explorer painted a list of
queues as a non-mqm user, it inquired on S.A.D.Q and caused an auths error.
Nobody at the time said "Yes, these errors are a PITA, and it's annoying and
sucky. I view it as better than the alternatives, and I view it as a simple
problem to either completely ignore these warnings or take basic steps to
identify these warnings as not meaningful." It got fixed. So should this.
I'm glad we at least agree the situation sucks. Here's your soapbox back.
Thanks for letting me borrow it.
-- T.Rob
From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Jefferson Lowrey
Sent: Wednesday, July 10, 2013 10:59 AM
To: <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMB 8 Broker Administration Security - Causes lots of MQ
Authority Events
MQ's fundamental authorization model is "check on access". It's not "check
on request". So you can't ask MQ before hand if you're eligible to GET
messages from a queue. You can only open the queue for input, and suceed or
fail.
This is, oddly enough, likely a direct consequence of the fact that MQ is a
resource manager and not an authorization server.
The broker team spent a lot of time making sure that the Broker product
could run with a minimum amount of preinstalled and required technologies.
In choosing to only require MQ, this then limited the choices they had for
authorization services.
Would you rather still have to install and manage DB2 with each and every
Broker? Or worse, TFIM?
Every RFE for additional error logging and reporting that is completed means
that the issue of managing and responding to logged events gets more
complicated. Powerful features means advanced management is required.
Yes, these errors are a PITA, and it's annoying and sucky. I view it as
better than the alternatives, and I view it as a simple problem to either
completely ignore these warnings or take basic steps to identify these
warnings as not meaningful.
I'm sure a lot of people will believe that last statement is a direct result
of the eight bars in front of my glasses. (important safety tip, I don't
wear glasses)
Who keeps putting that soapbox right where I'm trying stand?
Thank you,
Jeff Lowrey
From: "T.Rob" < <mailto:t.rob-KmGCPHWAkSrA+***@public.gmane.org> t.rob-KmGCPHWAkSrA+***@public.gmane.org>
To: <mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org,
Date: 07/10/2013 08:48 AM
Subject: Re: [MQSERIES] WMB 8 Broker Administration Security - Causes
lots of MQ Authority Events
Sent by: MQSeries List < <mailto:MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
MQSERIES-JX7+OpRa80QeFbOYke1v4oOpTq8/***@public.gmane.org>
_____
Part of the problem is the notion of using queue permissions as the Access
Control List for Broker or FTE. When asked about this, I specifically
raised this issue. The Broker or FTE agent determines it's authorization by
attempting to open queues with specific options. GET maps to something with
update capability, BROWSE maps to inquiry and so on. The problem with this
approach is that any negative result generates an authorization error. For
WMQ Explorer, or the WMB/FTE components of it, to function, it needs to
enumerate all the resources. That means at a minimum they need to have INQ
and DSP for the principal requesting the info. If these are mapped to
higher level authorizations in the stacked product you get error messages
FOR EVERY TIME EXPLORER PAINTS A SCREEN.
The *best* possible case using this approach is that INQ and DSP are
reserved for Explorer and that the layered app (WMB, FTE, whatever) only
uses PUT, GET, BROWSE and other auths not already needed by WMQ Explorer.
Even in this best case, the NORMAL operation of the layered component will
generate auths errors all day long.
So you can choose to implement granular security, or you can choose to be
able to monitor your security-relevant events, but not both. Perhaps you'll
have better luck explaining why this is a problem than I did. I was never
able to put the brakes on this trend, let alone reverse it. If for whatever
reason it isn't possible to implement first-class access control in the
layered products, at the very least it should be possible to switch off
alerts on these queues. Problem is that the ability to switch off
security-relevant alerts is in itself a security weakness and the only way
to make that safe is to have a special kind of queue for which there is no
actual storage and it exists only as a hanger for ACLs. Of course if one
were to go to that much trouble, might as well implement a first-class ACL
system like SYSTEM.FTE.AUTH.DATA or SYSTEM.WMB.AUTH.DATA.
Oh wait, sorry. I obviously meant SYSTEM.MFT.AUTH.DATA or
SYSTEM.IMB.AUTH.DATA.
-- T.Rob
-----Original Message-----
From: MQSeries List [ <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of
Darren Douch
Sent: Tuesday, July 09, 2013 4:54 PM
To: <mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: Re: WMB 8 Broker Administration Security - Causes lots of MQ
Authority Events
Personally I don't think so, Peter. How else can the toolkit present to the
user 'everything' that he/she is authorised to see, without trying
everything that there is? Either you would have to move the security into
the broker and out of mq, or do some hacking around of mq authorities before
attempting to discover the broker info.
Regards
Darren.
On 03/07/2013 13:29, Potkay, Peter M (CTO Architecture + Engineering) wrote:
> Broker Admin Security is enabled for the Broker. The Broker has 10
> execution groups, EG1, EG2, ..... EG10.
> GroupA is meant for users who only need limited access to EG1. No need
> for any access to EG2 thru EG10.
> GroupA is granted an appropriate level of access to SYSTEM.BROKER.AUTH.
> setmqaut -m BROKER1 -n 'SYSTEM.BROKER.AUTH' -t queue -g groupa -all
> +inq And to SYSTEM.BROKER.AUTH.EG1.
> setmqaut -m BROKER1 -n 'SYSTEM.BROKER.AUTH.EG1' -t queue -g groupa
> -all +inq
> +put +set
> While the table at the following link doesn't call it out (feedback
> raised via the InfoCenter to correct this gap), the following commands
were also run.
> <http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm>
http://publib.boulder.ibm.com/infocenter/wmbhelp/v8r0m0/topic/com.ibm.
> etools.mft.doc/bp43530_.htm
>
> setmqaut -m BROKER1 -t qmgr -g groupa -all +connect +inq setmqaut -m
> BROKER1 -n 'SYSTEM.BROKER.DEPLOY.QUEUE' -t queue -g groupa -all +put
> setmqaut -m BROKER1 -n 'SYSTEM.BROKER.DEPLOY.REPLY' -t queue -g groupa
> -all
> +put +get
> And all works as intended. Users in groupa have access to to see / do
> what we intend, and nothing else.
> Here's the problem. When a user in this group opens their toolkit and
> connects to this broker, and does nothing else in the toolkit, we get
> a flurry of authority event messages in the Queue Manager's
SYSTEM.ADMIN.QMGR.EVENT queue.
> These messages are flagging the lack of +ing access to the
> 'SYSTEM.BROKER.DC.AUTH' queue, and each of the 'SYSTEM.BROKER.AUTH.*'
> queues for all the other Execution Groups.
> So the user did nothing wrong, yet we have to deal with all the
> authority event messages. And its going to happen every time any user
> connects to the toolkit. Apparently the toolkit is trying to do a
> bunch of stuff under the covers as soon as it connects.
> Anyway around all this noise? Could it be considered a defect that the
> toolkit is trying to do all this extra stuff without a user asking it to?
> I do not want to cheese out and grant +inq to all those other queues.
> *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>
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>
http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> -
> Unsubscribe
> < <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=si>
mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=si
> gnoff%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
> < <http://www.lsoft.com/resources/manuals.asp>
http://www.lsoft.com/resources/manuals.asp>
>
To unsubscribe, write to <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
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/> http://www.lsoft.com
Archive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html
To unsubscribe, write to <mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>
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/>
http://www.lsoft.com
Archive: <http://listserv.meduniwien.ac.at/archives/mqser-l.html>
http://listserv.meduniwien.ac.at/archives/mqser-l.html
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
Instructions for managing your mailing list subscription are provided in the
Listserv General Users Guide available at
<http://www.lsoft.com/resources/manuals.asp> http://www.lsoft.com
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
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>
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
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.
************************************************************
_____
<http://listserv.meduniwien.ac.at/archives/mqser-l.html> List Archive -
<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> Manage Your
List Settings -
<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%
20mqseries> Unsubscribe
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>
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