Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-12 Thread Kevin Brown
Bruce Momjian wrote:
 If it is true that the linker only matches the major number, what value
 is there in incrementing the minor number, as we have done in the
 past?

It's main value is in indicating to the system administrator which
version of the library he has.  This is particularly useful in the
face of security updates.

A library can have bugfixes (even significant ones) and still be
binary compatible with a previous revision.  Situations like that are
what the minor number is useful for.  It can make the developer's (or
administrator's) life a little easier, since it means he can have
multiple minor revisions installed on his system and change the major
revision symlink to point to whichever one he wishes to actually use
(given the way the dynamic linker works, the administrator can name
the actual target of the symlink whatever he wishes so it's not
mandatory that the developers do that for him...it just makes his life
easier).

I probably should have gone into a little more detail about how the
linker does its thing: it looks for a literal match for what the
application says it was compiled against.  When the application was
linked, if the library it was linked against said it was 'libpg.so.2'
(As far as I know, the compile-time linker retrieves this from the
library's header information, not from its filename), then that's what
gets stored in the application's executable header and is what the
runtime linker looks for.  libpg.so.2 may be a symlink to (e.g.) 
libpg.so.2.1 or a hard link, or a copy of a library for that matter.
The runtime linker will successfully link the shared library into the
program's memory image in any of those cases -- it only has to find a
shared library whose filename is the same as what's requested *and*
whose header information provides the same name.



-- 
Kevin Brown   [EMAIL PROTECTED]

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



[HACKERS] Please, apply patch for 7.3.1 and current CVS

2002-12-12 Thread Teodor Sigaev
This patch fixes minor bugs in dictionary generator in contrib/tsearch 
(contrib/tsearch/makedict/makedict.pl)

Thank you.

--
Teodor Sigaev
[EMAIL PROTECTED]



tsearch_patch.gz
Description: application/gzip

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Problems with ALTER DOMAIN patch

2002-12-12 Thread Rod Taylor
On Wed, 2002-12-11 at 19:00, Bruce Momjian wrote:
 It is an idea if no better one can be found, unless we don't want ALTER
 DOMAIN at all, which doesn't seem good.

I'll make a proposal for 'Object' locks as suggested, and we'll see
where we go from there.

-- 
Rod Taylor [EMAIL PROTECTED]

PGP Key: http://www.rbt.ca/rbtpub.asc



signature.asc
Description: This is a digitally signed message part


[HACKERS] Logging Feature

2002-12-12 Thread mlw
Is there a way to get pg logging of plans to be produced in the terse 
format like when a user types explain select * from foo where bar = x

The plan logging is very verbose. Having a lighter version of the 
logging would be helpful in pinpointing troublesome queries without 
slogging through pages of explain info.

Am I out to lunch? Is there a way to do this (I haven't found it yet, 
and I have tried several permutations of log parameters) If not, does 
anyone else see the value?




---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] Postgres syscalls

2002-12-12 Thread Stephan Szabo

On Fri, 13 Dec 2002, [iso-8859-1] Diego T. wrote:

 Hello I'm an Italian student of computer science at
 University of Rome La Sapienza. I've to analyze some
 daemons which run under root privileges with a tool
 developed by my departement. This tool intercepts
 critical syscalls, like Execve, and blocks illegal
 invocation of that primitives (E.g. Execve(/bin/sh))
 performed by a daemon which runs under root
 privileges. This approach blocks buffer overflow
 attacks before they can complete (or I hope so). Now,
 the problem is that postgres doesn' t run under root
 privileges and that the tool intercepts only the
 syscalls invoked by a process with root privileges. Is
 possible to force postgres to run under root
 privileges? How can be done? I know my request is
 anomalous but i've to do this for my laboratory
 project course. I should be very grateful if you'll
 answer as soon as possible.

You could probably just hack out the checks in main/main.c
and recompile, but postgres does call system and such to do
things (like create databases) so I'm not sure it'd be terribly
useful for you.



---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



[HACKERS] invalid tid errors.

2002-12-12 Thread wade
Hello,
  Using Postgresql 7.3 (CVS REL7_3_STABLE today), I received the following
error:

dropsites= delete from cart_stores;
ERROR:  heap_update: (am)invalid tid

This came from a database that was dumped from 7.2.1 using 7.2.1's pg_dump
and imported into 7.3.  I was able to delete the rows individually with a
where clause ( WHERE id = ... ).  The problem attempting to delete all rows
persisted even when there was only 1 row left, even though this last row
deleted fine when I specified it explicitly with a where clause.  I was
able to delete the contents of other tables in the db without incident.  I
was also able to reproduce this on a second box, also CVS REL7_3_STABLE
from about a week ago.  This problem is not exhibited under 7.2.1.

So, the question is, how do I go about tracking this down?  Has anyone seen
this?  It was suggested by one person that memory may be the issue, but the
 fact that it is exhibited on two boxen makes that seem unlikely.

FYI:
  Machine 1:
PIII 600 w/ 256MB
FreeBSD 4.6 STABLE
  Machine 2:
Dual PIII 600 w/ 512MB
FreeBSD 4.7 STABLE

Thanx in advance.
 -Wade Klaver

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] Problem with function permissions

2002-12-12 Thread Dave Page


 -Original Message-
 From: Tom Lane [mailto:[EMAIL PROTECTED]] 
 Sent: 12 December 2002 16:48
 To: Dave Page
 Cc: [EMAIL PROTECTED]
 Subject: Re: [HACKERS] Problem with function permissions 
 
 
 Dave Page [EMAIL PROTECTED] writes:
  I would not have expected public to now have execute 
 permission. Any 
  reason for this, or is it a bug?
 
 The default permissions for functions grant execute to 
 public; the system is just instantiating that default when 
 you do an explicit grant.
 
 The original implementation of function permissions didn't 
 grant anything to public, but we concluded that that would 
 break too many applications to be a reasonable default.

OK, thanks.

Regards, Dave.

---(end of broadcast)---
TIP 6: Have you searched our list archives?

http://archives.postgresql.org



Re: [HACKERS] Creating a zero-column table

2002-12-12 Thread Philip Warner
At 04:08 PM 12/12/2002 -0500, Tom Lane wrote:

Should we remove this error check, thereby effectively making
zero-column tables first-class citizens?


It's a bit daft, but I suspect it's the way to go. There has to be a 
non-zero chance that a future version of pg_dump may want to add attributes 
to tables in a piecemeal fashion (cyclic FKs? Yuk).




Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


Re: [HACKERS] Creating a zero-column table

2002-12-12 Thread Philip Warner
At 04:08 PM 12/12/2002 -0500, Tom Lane wrote:

Should we remove this error check, thereby effectively making
zero-column tables first-class citizens?


I should wait 2 minutes before hitting 'send'.

The other option is to disallow the steps that resulted in the zero-column 
table in the first place. This is probably more rational.




Philip Warner| __---_
Albatross Consulting Pty. Ltd.   |/   -  \
(A.B.N. 75 008 659 498)  |  /(@)   __---_
Tel: (+61) 0500 83 82 81 | _  \
Fax: (+61) 03 5330 3172  | ___ |
Http://www.rhyme.com.au  |/   \|
 |----
PGP key available upon request,  |  /
and from pgp5.ai.mit.edu:11371   |/


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly


Re: [HACKERS] Postgres syscalls

2002-12-12 Thread Shridhar Daithankar
On 12 Dec 2002 at 16:09, Stephan Szabo wrote:

 
 On Fri, 13 Dec 2002, [iso-8859-1] Diego T. wrote:
 
  Hello I'm an Italian student of computer science at
  University of Rome La Sapienza. I've to analyze some
  daemons which run under root privileges with a tool
  developed by my departement. This tool intercepts
  critical syscalls, like Execve, and blocks illegal
  invocation of that primitives (E.g. Execve(/bin/sh))
  performed by a daemon which runs under root
  privileges. This approach blocks buffer overflow
  attacks before they can complete (or I hope so). Now,

OK..

  the problem is that postgres doesn' t run under root
  privileges and that the tool intercepts only the
  syscalls invoked by a process with root privileges. Is
  possible to force postgres to run under root

 You could probably just hack out the checks in main/main.c
 and recompile, but postgres does call system and such to do
 things (like create databases) so I'm not sure it'd be terribly
 useful for you.

I agree. Not running root is a god idea from secutiry point of view. That way 
any buffer overflow attacks would be half dead as it is.

Secondly In my understanding, buffer overflow attacks can be stopped very 
effectivelyif compiler has stack smashing patches. ( Or is it kernel as well?)

And do look at strace. I feel you are shooting at same target..

HTH


Bye
 Shridhar

--
Grinnell's Law of Labor Laxity: At all times, for any task, you have not got 
enough done today.


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Big 7.4 items

2002-12-12 Thread Shridhar Daithankar
On 13 Dec 2002 at 1:22, Bruce Momjian wrote:
 Replication
 
   I have talked to Darren Johnson and I believe 7.4 is the time to
   merge the Postgres-R source tree into our main CVS.  Most of the
   replication code will be in its own directory, with only minor
   changes to our existing tree.  They have single-master
   replication working now, so we may have that feature in some
   capacity for 7.4.  I know others are working on replication
   solutions.  This is probably the time to decide for certain if
   this is the direction we want to go for replication.  Most who
   have have studied Postgres-R feel it is the most promising
   multi-master replication solution for reliably networked hosts.
 
 Comments?

Some.

1) What kind of replication are we looking at? log file replay/syncnronous etc. 
If it is real time, like usogres( I hope I am in line with things here), that 
would be real good .Choice is always good..

2 If we are going to have replication, can we have built in load balancing? Is 
it a good idea to have it in postgresql or a separate application would be way 
to go?

And where are nested transactions?



Bye
 Shridhar

--
Booker's Law:   An ounce of application is worth a ton of abstraction.


---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] Creating a zero-column table

2002-12-12 Thread Tom Lane
Philip Warner [EMAIL PROTECTED] writes:
 At 12:31 AM 13/12/2002 -0500, Tom Lane wrote:
 Amy does CREATE TABLE foo(f1 beths_type);
 Beth now cannot drop her type beths_type.
 In most circles this would be called a denial of service.

 Seems like a feature - if beth made the type public, she has to deal with 
 fame.

But in every other context, Beth has the unconditional right to drop her
type: if it's not the only column in Amy's table, Beth can drop her type
and Amy's column along with it.

Basically, the no-zero-column-tables restriction for deletion was
removed because it creates more weird corner cases than it prevents.
I still agree with that decision.  What we're seeing here is that the
corresponding restriction during table creation also creates weird
corner cases.

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-12 Thread Bruce Momjian
Peter Eisentraut wrote:
 Bruce Momjian writes:
 
  We bump at the beginning only because we _know_ we want new users to use
  the newer library.  (Does the runtime linker know to get the highest
  minor numbered library with the same major number?)
 
 No, the run-time linker only looks at the major version.

Then what value is there to incrementing the minor number?

  The big question is whether a change in the API or a change in the code
  (recompile) is enough to bump that major version number.  We always make
  some force-recompile change in the library in each release, don't we?
  Do we just bump the major in every major release?
 
 The rules are pretty clear:  If you change or remove an interface (= part
 of the API) then you change the major, if you add an interface or
 improve the code, change the minor.  Whether we actually change the code

So if a recompile fixes it, increment minor, else major.  Then we
normally only do minor-level changes,. and frankly we improve the code
all during development time and during beta, so it seems pretty abitrary
when we increment the minor unless we want to increment it many times
during development, _or_ right before final to ensure that final
releaase users have the newest version.


 during a release cycle is something that is best determined *after* the
 release cycle.  Possibly we always do, but I wouldn't be surprised if some
 library like pgeasy lay dormant for a while.
 
  I usually bumped the minor at the beginning because this allows beta
  testers to not have _extra_ versions of the library laying around, and
 
 That doesn't make sense to me.  Which extra versions?

If you bump during beta, and don't delete your pgsql/ directory, you
will have the old libpq.so there and the new one because once you bump
the version, the old one just says in the directory.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly



Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-12 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 So if a recompile fixes it, increment minor, else major.

Wrong --- if you need a recompile then it's not binary-compatible, so
it should be a major version bump.

 Then we
 normally only do minor-level changes,. and frankly we improve the code
 all during development time and during beta, so it seems pretty abitrary
 when we increment the minor unless we want to increment it many times
 during development, _or_ right before final to ensure that final
 releaase users have the newest version.

I think there is definite value in incrementing the minor version once
at the start of the cycle.  Whether we do it at start or end does not
matter to end users, but it *does* help developers, who can then easily
tell whether they are looking at a devel library or the previous
release.

If we make a non-binary-compatible change during a development cycle,
we should then immediately bump the major version number.  Leaving it
till the end of the cycle is an excellent recipe for forgetting, as
indeed we just did.

regards, tom lane

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]



Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-12 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  So if a recompile fixes it, increment minor, else major.
 
 Wrong --- if you need a recompile then it's not binary-compatible, so
 it should be a major version bump.

But the previous poster said only API changes were reasons to bump the
major, right?
 

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Creating a zero-column table

2002-12-12 Thread Hannu Krosing
Tom Lane kirjutas R, 13.12.2002 kell 02:08:
 I was bemused to notice that pg_dump is currently unable to dump the
 regression database.  The domain regression test leaves an empty table
 (one with zero columns), which causes pg_dump to produce
 
 --
 -- TOC entry 172 (OID 675837)
 -- Name: domnotnull; Type: TABLE; Schema: public; Owner: postgres
 --
 
 CREATE TABLE domnotnull (
 );
 
 
 This is rejected on restore:
 
 ERROR:  DefineRelation: please inherit from a relation or define an attribute
 
 I believe that the table would be correctly restored if we simply
 removed that error check in DefineRelation.  On the other hand, for
 ordinary hand-entered CREATE TABLE commands it seems like a useful
 error check.
 
 Should we remove this error check, thereby effectively making
 zero-column tables first-class citizens? 

I would vote for removing the check. I see no reason why one should not
be able to define a zero-column table. While we cant currently do
anything useful (except select oid :) with it now, it does not mean that
it would not serve as a valid base table for inheritance hierarchies in
future. 

I'm probably going to propose an implicit zero-column base table for all
user defined tables (say any_table) so that one can get a list of all
tuple ids in all tables by doing a simple 
select tableoid,oid from any_table. This will of course not be very
useful for tables with no oids and where there is no index on oid.


-- 
Hannu Krosing [EMAIL PROTECTED]

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-12 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  Tom Lane wrote:
  Wrong --- if you need a recompile then it's not binary-compatible, so
  it should be a major version bump.
 
  But the previous poster said only API changes were reasons to bump the
  major, right?
 
 Yes.  He meant *binary* API changes, though, ie, anything that would
 break extant executables originally linked to the prior version of the
 shared library.

Just for clarification --- don't most/all our releases make a binary
change that needs are compile?  Actually, you are saying a recompile of
the client, right?  Yes, we do those rarely, and in 7.3, for the NOTIFY
structure change.  What we do often is want old binaries to use our new
libraries.  That isn't a major bump requirement, right?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-12 Thread Bruce Momjian

OK, so what do we do with 7.3.1.  Increment major or minor?

---

pgman wrote:
 Tom Lane wrote:
  Bruce Momjian [EMAIL PROTECTED] writes:
   Tom Lane wrote:
   Wrong --- if you need a recompile then it's not binary-compatible, so
   it should be a major version bump.
  
   But the previous poster said only API changes were reasons to bump the
   major, right?
  
  Yes.  He meant *binary* API changes, though, ie, anything that would
  break extant executables originally linked to the prior version of the
  shared library.
 
 Just for clarification --- don't most/all our releases make a binary
 change that needs are compile?  Actually, you are saying a recompile of
 the client, right?  Yes, we do those rarely, and in 7.3, for the NOTIFY
 structure change.  What we do often is want old binaries to use our new
 libraries.  That isn't a major bump requirement, right?
 
 -- 
   Bruce Momjian|  http://candle.pha.pa.us
   [EMAIL PROTECTED]   |  (610) 359-1001
   +  If your life is a hard drive, |  13 Roberts Road
   +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])



Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-12 Thread Tom Lane
Bruce Momjian [EMAIL PROTECTED] writes:
 OK, so what do we do with 7.3.1.  Increment major or minor?

Major.  I thought you did it already?

regards, tom lane

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] PQnotifies() in 7.3 broken?

2002-12-12 Thread Bruce Momjian
Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  OK, so what do we do with 7.3.1.  Increment major or minor?
 
 Major.  I thought you did it already?

I did only minor, which I knew was safe.  Do folks realize this will
require recompile of applications by 7.3 users moving to 7.3.1?  That
seems very drastic, and there have been very few problem reports about
the NOTIFY change.

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html



Re: [HACKERS] Please, apply patch for 7.3.1 and current CVS

2002-12-12 Thread Bruce Momjian

Patch applied.  Thanks.

Backpatched to 7.3.

---


Teodor Sigaev wrote:
 This patch fixes minor bugs in dictionary generator in contrib/tsearch 
 (contrib/tsearch/makedict/makedict.pl)
 
 Thank you.
 
 -- 
 Teodor Sigaev
 [EMAIL PROTECTED]
 

[ application/gzip is not supported, skipping... ]

 
 ---(end of broadcast)---
 TIP 4: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



Re: [HACKERS] Arrays for domain types

2002-12-12 Thread Tom Lane
Peter Eisentraut [EMAIL PROTECTED] writes:
 While playing around with a preliminary version of the information schema
 I get a failure in the type_sanity regression test here:

 SELECT p1.oid, p1.typname
 FROM pg_type as p1
 WHERE p1.typtype in ('b','d') AND p1.typname NOT LIKE '\\_%' AND NOT
 EXISTS
 (SELECT 1 FROM pg_type as p2
  WHERE p2.typname = ('_' || p1.typname)::name AND
p2.typelem = p1.oid);

For the moment I'd suggest backing off the regression test from
 p1.typtype in ('b','d')
to
 p1.typtype in ('b')
Probably eventually CREATE DOMAIN ought to create an associated array
type, but it's not really your problem if it doesn't ...

regards, tom lane

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster



[HACKERS] Big 7.4 items

2002-12-12 Thread Bruce Momjian
I wanted to outline some of the big items we are looking at for 7.4:

Win32 Port:

Katie Ward and Jan are working on contributing their Win32
port for 7.4.  They plan to have a patch available by the end of
December.

Point-In-Time Recovery (PITR)

J. R. Nield did a PITR patch late in 7.3 development, and Patrick
MacDonald from Red Hat is working on merging it into CVS and
adding any missing pieces.  Patrick, do you have an ETA on that?

Replication

I have talked to Darren Johnson and I believe 7.4 is the time to
merge the Postgres-R source tree into our main CVS.  Most of the
replication code will be in its own directory, with only minor
changes to our existing tree.  They have single-master
replication working now, so we may have that feature in some
capacity for 7.4.  I know others are working on replication
solutions.  This is probably the time to decide for certain if
this is the direction we want to go for replication.  Most who
have have studied Postgres-R feel it is the most promising
multi-master replication solution for reliably networked hosts.

Comments?

-- 
  Bruce Momjian|  http://candle.pha.pa.us
  [EMAIL PROTECTED]   |  (610) 359-1001
  +  If your life is a hard drive, |  13 Roberts Road
  +  Christ can be your backup.|  Newtown Square, Pennsylvania 19073

---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]