scrollkeeper loading external (online) DTD
Hi, This a real example : The xbill package contains : /usr/share/gnome/help/xbill/C/xbill.xml In this file the DTD is refered by an absolute external link : http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; Thus : scrollkeeper-update blindly connect to www.oasis-open.org to get the docbookx.dtd. I can trust signed debian packages but I can't trust www.oasis-open.org. More than 18 files in /usr/share/gnome/help/ induce this download. I'am about to make bug report against scrollkeeper (for acting blindly, and dowloading the same file more than once) and against packages that provides the xml files (for using external DTD instead of provinding it)... Your opinion? Cheers, SEb
Re: raw disk access
viv <[EMAIL PROTECTED]> writes: > i thought originally that dd would work and tried to 'image' > a couple of CDs, but they came out to different sizes although > both were 650MB CDs. The disk sizes differed by about 3 MB, > so i assumed dd was missing something. Imaging 2 floppies > yielded different sized images as well. CDs are different from floppies. It's normal that different CDs have different sizes (and AFAIK, there's no clear end marker, so I wouldn't be surprised if the readable area is larger with some drivers than with others). -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
scrollkeeper loading external (online) DTD
Hi, This a real example : The xbill package contains : /usr/share/gnome/help/xbill/C/xbill.xml In this file the DTD is refered by an absolute external link : http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; Thus : scrollkeeper-update blindly connect to www.oasis-open.org to get the docbookx.dtd. I can trust signed debian packages but I can't trust www.oasis-open.org. More than 18 files in /usr/share/gnome/help/ induce this download. I'am about to make bug report against scrollkeeper (for acting blindly, and dowloading the same file more than once) and against packages that provides the xml files (for using external DTD instead of provinding it)... Your opinion? Cheers, SEb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: raw disk access
viv <[EMAIL PROTECTED]> writes: > i thought originally that dd would work and tried to 'image' > a couple of CDs, but they came out to different sizes although > both were 650MB CDs. The disk sizes differed by about 3 MB, > so i assumed dd was missing something. Imaging 2 floppies > yielded different sized images as well. CDs are different from floppies. It's normal that different CDs have different sizes (and AFAIK, there's no clear end marker, so I wouldn't be surprised if the readable area is larger with some drivers than with others). -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Gnutella? (was Re: TCP port 6352?)
On Tue, Jan 07, 2003 at 03:19:17PM -0800, Josh Carroll wrote: > Having failed to find any information about TCP port 6352 via google or > /etc/services, I > figured I'd ask here. I'm seeing an awful lot of dropped packets on this port > recently, > and I'm curious if anyone else has seen this. If so, what purpose does TCP > port 6352 serve > (either in the *nix domain or windows if known), and should it be a concern. > Below is > an example of the dropped packets I'm seeing. > I have done some google searching and I believe the culprit might be gnutella. Take a look at this search (try google's cached files since the servers are no longer up) http://www.google.com/search?hl=es&ie=UTF-8&oe=UTF-8&q=6352+gnutella&lr= You will see that the listing for many servers/clients in the network are usually port 6346 [1]. But it seems port 6352 is also used sometimes. Regards Javi [1] Check the source: /tmp/jfs/gtk-gnutella-0.91.1$ grep 634 src/*.c src/gnet_property.c:guint32 listen_port = 6346; src/gnet_property.c:guint32 listen_port_def = 6346; pgpSJi1A2xxG2.pgp Description: PGP signature
Re: Can this be considered a DoS-attack?
No, and it seems they've fixed their problem on their end. I think it hurt them a lot worse (on bandwidth) than it hurt you :) On Wed, 8 Jan 2003 19:21:45 +0100 (CET) Cristian Ionescu-Idbohrn <[EMAIL PROTECTED]> wrote: > http://www.raycomm.com/techwhirl/magazine/technical/linux.html pgp9lyvIGfomj.pgp Description: PGP signature
Re: Can this be considered a DoS-attack?
On Wed, Jan 08, 2003 at 07:21:45PM +0100, Cristian Ionescu-Idbohrn wrote:
> Using mozilla 1.2.1 (but I don't think the browser matters).
> Browsed to:
>
> http://www.raycomm.com/techwhirl/magazine/technical/linux.html
>
> and tried the "Printer-friendly version" link (CAREFUL HERE: don't
> click on the link and then leave home):
>
>
> http://www.raycomm.com/techwhirl/phpapps/pfv/pfv.php?/techwhirl/magazine/technical/linux.html
>
> Obviously, there's some buggy code on that web server:
>
> Apache/1.3.27 (Unix) mod_throttle/3.1.2 PHP/4.2.3
>
> Anyway, the result is that the server will vomit thousends of error
> messages like this:
>
> ,
> | Warning: fopen("", "rb") - Inappropriate ioctl for device in
> | /home/raycomm/web/techwhirl/phpapps/pfv/pfv.php on line 37
> |
> | Warning: feof(): supplied argument is not a valid File-Handle resource
> | in /home/raycomm/web/techwhirl/phpapps/pfv/pfv.php on line 39
> `
>
> Leave it going an watch your RAM and swap growing. Memory will be
> exausted at some point. I had to:
>
> # killall mozilla-bin
>
> to stop that (when I noticed there wad unnormal load on my box).
Those are standard PHP errors, but it looks like there were a LOT of
them. However, whatever the problem was on their end is fixed, because
the Printer Friendly link works now.
--
:wq
Matthew Daubenspeck
http://www.oddprocess.org
Can this be considered a DoS-attack?
Using mozilla 1.2.1 (but I don't think the browser matters).
Browsed to:
http://www.raycomm.com/techwhirl/magazine/technical/linux.html
and tried the "Printer-friendly version" link (CAREFUL HERE: don't
click on the link and then leave home):
http://www.raycomm.com/techwhirl/phpapps/pfv/pfv.php?/techwhirl/magazine/technical/linux.html
Obviously, there's some buggy code on that web server:
Apache/1.3.27 (Unix) mod_throttle/3.1.2 PHP/4.2.3
Anyway, the result is that the server will vomit thousends of error
messages like this:
,
| Warning: fopen("", "rb") - Inappropriate ioctl for device in
| /home/raycomm/web/techwhirl/phpapps/pfv/pfv.php on line 37
|
| Warning: feof(): supplied argument is not a valid File-Handle resource
| in /home/raycomm/web/techwhirl/phpapps/pfv/pfv.php on line 39
`
Leave it going an watch your RAM and swap growing. Memory will be
exausted at some point. I had to:
# killall mozilla-bin
to stop that (when I noticed there wad unnormal load on my box).
Cheers,
Cristian
Gnutella? (was Re: TCP port 6352?)
On Tue, Jan 07, 2003 at 03:19:17PM -0800, Josh Carroll wrote: > Having failed to find any information about TCP port 6352 via google or >/etc/services, I > figured I'd ask here. I'm seeing an awful lot of dropped packets on this port >recently, > and I'm curious if anyone else has seen this. If so, what purpose does TCP port >6352 serve > (either in the *nix domain or windows if known), and should it be a concern. Below is > an example of the dropped packets I'm seeing. > I have done some google searching and I believe the culprit might be gnutella. Take a look at this search (try google's cached files since the servers are no longer up) http://www.google.com/search?hl=es&ie=UTF-8&oe=UTF-8&q=6352+gnutella&lr= You will see that the listing for many servers/clients in the network are usually port 6346 [1]. But it seems port 6352 is also used sometimes. Regards Javi [1] Check the source: /tmp/jfs/gtk-gnutella-0.91.1$ grep 634 src/*.c src/gnet_property.c:guint32 listen_port = 6346; src/gnet_property.c:guint32 listen_port_def = 6346; msg08407/pgp0.pgp Description: PGP signature
Re: Can this be considered a DoS-attack?
No, and it seems they've fixed their problem on their end. I think it hurt them a lot worse (on bandwidth) than it hurt you :) On Wed, 8 Jan 2003 19:21:45 +0100 (CET) Cristian Ionescu-Idbohrn <[EMAIL PROTECTED]> wrote: > http://www.raycomm.com/techwhirl/magazine/technical/linux.html msg08406/pgp0.pgp Description: PGP signature
Re: Can this be considered a DoS-attack?
On Wed, Jan 08, 2003 at 07:21:45PM +0100, Cristian Ionescu-Idbohrn wrote:
> Using mozilla 1.2.1 (but I don't think the browser matters).
> Browsed to:
>
> http://www.raycomm.com/techwhirl/magazine/technical/linux.html
>
> and tried the "Printer-friendly version" link (CAREFUL HERE: don't
> click on the link and then leave home):
>
>
>http://www.raycomm.com/techwhirl/phpapps/pfv/pfv.php?/techwhirl/magazine/technical/linux.html
>
> Obviously, there's some buggy code on that web server:
>
> Apache/1.3.27 (Unix) mod_throttle/3.1.2 PHP/4.2.3
>
> Anyway, the result is that the server will vomit thousends of error
> messages like this:
>
> ,
> | Warning: fopen("", "rb") - Inappropriate ioctl for device in
> | /home/raycomm/web/techwhirl/phpapps/pfv/pfv.php on line 37
> |
> | Warning: feof(): supplied argument is not a valid File-Handle resource
> | in /home/raycomm/web/techwhirl/phpapps/pfv/pfv.php on line 39
> `
>
> Leave it going an watch your RAM and swap growing. Memory will be
> exausted at some point. I had to:
>
> # killall mozilla-bin
>
> to stop that (when I noticed there wad unnormal load on my box).
Those are standard PHP errors, but it looks like there were a LOT of
them. However, whatever the problem was on their end is fixed, because
the Printer Friendly link works now.
--
:wq
Matthew Daubenspeck
http://www.oddprocess.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Can this be considered a DoS-attack?
Using mozilla 1.2.1 (but I don't think the browser matters).
Browsed to:
http://www.raycomm.com/techwhirl/magazine/technical/linux.html
and tried the "Printer-friendly version" link (CAREFUL HERE: don't
click on the link and then leave home):
http://www.raycomm.com/techwhirl/phpapps/pfv/pfv.php?/techwhirl/magazine/technical/linux.html
Obviously, there's some buggy code on that web server:
Apache/1.3.27 (Unix) mod_throttle/3.1.2 PHP/4.2.3
Anyway, the result is that the server will vomit thousends of error
messages like this:
,
| Warning: fopen("", "rb") - Inappropriate ioctl for device in
| /home/raycomm/web/techwhirl/phpapps/pfv/pfv.php on line 37
|
| Warning: feof(): supplied argument is not a valid File-Handle resource
| in /home/raycomm/web/techwhirl/phpapps/pfv/pfv.php on line 39
`
Leave it going an watch your RAM and swap growing. Memory will be
exausted at some point. I had to:
# killall mozilla-bin
to stop that (when I noticed there wad unnormal load on my box).
Cheers,
Cristian
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: raw disk access
This may have something to do with the block size. I'm not sure of the default options for dd, but it does allow you to specify the size of blocks you are copying. Another thing to check is the options for padding blocks for newline terminated records. You might also need the 'noerror' option. Good Luck :) Colin http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED] Sent: 08 January 2003 07:19 To: DebianSecurity Cc: Colin Ellis Subject: RE: raw disk access Thanks to all for your quick replies. i thought originally that dd would work and tried to 'image' a couple of CDs, but they came out to different sizes although both were 650MB CDs. The disk sizes differed by about 3 MB, so i assumed dd was missing something. Imaging 2 floppies yielded different sized images as well. From the replies thus far, it seems that dd is exactly what i am looking for. However, i am still at a loss to explain the differences in image sizes. Does dd copy every bit from a device from start to finish, or does it skip / miss something somewhere? Thanks again. On Wed, 2003-01-08 at 11:29, Colin Ellis wrote: > The best that can be achieved is via 'dd'. > > however it is actually impossible to get _real_ raw disk access due to the > disk IO controllers. As far as I know, all disk IO controllers have > automatic data correction etc and so do hard disks. An accurate copy of the > surface of the disk cannot be gained by this method. > > Has anyone any ideas on whether it's possible to bypass the automatic checks > performed by the IO controllers? > > Colin > Solution City Ltd > http://www.solution-city.com > > > > -Original Message- > From: viv [mailto:[EMAIL PROTECTED] > Sent: 07 January 2003 21:08 > To: DebianSecurity > Subject: raw disk access > > > Hi. > > As a Debian user, i am posting to this list first in the hopes > that what i am looking for can be found as a Debian package. > > i am looking for forensics tools that can be used in computer > crime investigations, and am particularly interesting in a tool > that provides raw drive (hard, floppy, CD, DVD, etc.) access in > order to create complete and accurate drive images. > > If such a tool does not exist within Debian, is anyone aware of > any application (GPLed, please) that does? Failing that, i am > willing to write my own tool, if necessary, and would appreciate > any pointers to good reference material (raw drive access and > how to work with the images created). > > If it helps, i am running with the latest 'unstable' packages. > > Many thanks. > > -- > viv <[EMAIL PROTECTED]> -- viv <[EMAIL PROTECTED]>
RE: TCP port 6352?
> -Original Message- > From: Josh Carroll [mailto:[EMAIL PROTECTED] > Sent: Wednesday 8 January 2003 00:30 > To: debian-security@lists.debian.org > Subject: TCP port 6352? > > > Having failed to find any information about TCP port 6352 via > google or /etc/services, I > figured I'd ask here. I'm seeing an awful lot of dropped > packets on this port recently, > and I'm curious if anyone else has seen this. If so, what > purpose does TCP port 6352 serve > (either in the *nix domain or windows if known), and should > it be a concern. Below is > an example of the dropped packets I'm seeing. > > Thanks in advance, > Josh > According to http://outpostfirewall.com/guide/rules/preset_rules/p2p.htm It might be some Peer to peer protocol. Vincent
RE: raw disk access
Thanks to all for your quick replies. i thought originally that dd would work and tried to 'image' a couple of CDs, but they came out to different sizes although both were 650MB CDs. The disk sizes differed by about 3 MB, so i assumed dd was missing something. Imaging 2 floppies yielded different sized images as well. From the replies thus far, it seems that dd is exactly what i am looking for. However, i am still at a loss to explain the differences in image sizes. Does dd copy every bit from a device from start to finish, or does it skip / miss something somewhere? Thanks again. On Wed, 2003-01-08 at 11:29, Colin Ellis wrote: > The best that can be achieved is via 'dd'. > > however it is actually impossible to get _real_ raw disk access due to the > disk IO controllers. As far as I know, all disk IO controllers have > automatic data correction etc and so do hard disks. An accurate copy of the > surface of the disk cannot be gained by this method. > > Has anyone any ideas on whether it's possible to bypass the automatic checks > performed by the IO controllers? > > Colin > Solution City Ltd > http://www.solution-city.com > > > > -Original Message- > From: viv [mailto:[EMAIL PROTECTED] > Sent: 07 January 2003 21:08 > To: DebianSecurity > Subject: raw disk access > > > Hi. > > As a Debian user, i am posting to this list first in the hopes > that what i am looking for can be found as a Debian package. > > i am looking for forensics tools that can be used in computer > crime investigations, and am particularly interesting in a tool > that provides raw drive (hard, floppy, CD, DVD, etc.) access in > order to create complete and accurate drive images. > > If such a tool does not exist within Debian, is anyone aware of > any application (GPLed, please) that does? Failing that, i am > willing to write my own tool, if necessary, and would appreciate > any pointers to good reference material (raw drive access and > how to work with the images created). > > If it helps, i am running with the latest 'unstable' packages. > > Many thanks. > > -- > viv <[EMAIL PROTECTED]> -- viv <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
RE: raw disk access
This may have something to do with the block size. I'm not sure of the default options for dd, but it does allow you to specify the size of blocks you are copying. Another thing to check is the options for padding blocks for newline terminated records. You might also need the 'noerror' option. Good Luck :) Colin http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED]] Sent: 08 January 2003 07:19 To: DebianSecurity Cc: Colin Ellis Subject: RE: raw disk access Thanks to all for your quick replies. i thought originally that dd would work and tried to 'image' a couple of CDs, but they came out to different sizes although both were 650MB CDs. The disk sizes differed by about 3 MB, so i assumed dd was missing something. Imaging 2 floppies yielded different sized images as well. From the replies thus far, it seems that dd is exactly what i am looking for. However, i am still at a loss to explain the differences in image sizes. Does dd copy every bit from a device from start to finish, or does it skip / miss something somewhere? Thanks again. On Wed, 2003-01-08 at 11:29, Colin Ellis wrote: > The best that can be achieved is via 'dd'. > > however it is actually impossible to get _real_ raw disk access due to the > disk IO controllers. As far as I know, all disk IO controllers have > automatic data correction etc and so do hard disks. An accurate copy of the > surface of the disk cannot be gained by this method. > > Has anyone any ideas on whether it's possible to bypass the automatic checks > performed by the IO controllers? > > Colin > Solution City Ltd > http://www.solution-city.com > > > > -Original Message- > From: viv [mailto:[EMAIL PROTECTED]] > Sent: 07 January 2003 21:08 > To: DebianSecurity > Subject: raw disk access > > > Hi. > > As a Debian user, i am posting to this list first in the hopes > that what i am looking for can be found as a Debian package. > > i am looking for forensics tools that can be used in computer > crime investigations, and am particularly interesting in a tool > that provides raw drive (hard, floppy, CD, DVD, etc.) access in > order to create complete and accurate drive images. > > If such a tool does not exist within Debian, is anyone aware of > any application (GPLed, please) that does? Failing that, i am > willing to write my own tool, if necessary, and would appreciate > any pointers to good reference material (raw drive access and > how to work with the images created). > > If it helps, i am running with the latest 'unstable' packages. > > Many thanks. > > -- > viv <[EMAIL PROTECTED]> -- viv <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: TCP port 6352?
> -Original Message- > From: Josh Carroll [mailto:[EMAIL PROTECTED]] > Sent: Wednesday 8 January 2003 00:30 > To: [EMAIL PROTECTED] > Subject: TCP port 6352? > > > Having failed to find any information about TCP port 6352 via > google or /etc/services, I > figured I'd ask here. I'm seeing an awful lot of dropped > packets on this port recently, > and I'm curious if anyone else has seen this. If so, what > purpose does TCP port 6352 serve > (either in the *nix domain or windows if known), and should > it be a concern. Below is > an example of the dropped packets I'm seeing. > > Thanks in advance, > Josh > According to http://outpostfirewall.com/guide/rules/preset_rules/p2p.htm It might be some Peer to peer protocol. Vincent -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: raw disk access
Thanks to all for your quick replies. i thought originally that dd would work and tried to 'image' a couple of CDs, but they came out to different sizes although both were 650MB CDs. The disk sizes differed by about 3 MB, so i assumed dd was missing something. Imaging 2 floppies yielded different sized images as well. From the replies thus far, it seems that dd is exactly what i am looking for. However, i am still at a loss to explain the differences in image sizes. Does dd copy every bit from a device from start to finish, or does it skip / miss something somewhere? Thanks again. On Wed, 2003-01-08 at 11:29, Colin Ellis wrote: > The best that can be achieved is via 'dd'. > > however it is actually impossible to get _real_ raw disk access due to the > disk IO controllers. As far as I know, all disk IO controllers have > automatic data correction etc and so do hard disks. An accurate copy of the > surface of the disk cannot be gained by this method. > > Has anyone any ideas on whether it's possible to bypass the automatic checks > performed by the IO controllers? > > Colin > Solution City Ltd > http://www.solution-city.com > > > > -Original Message- > From: viv [mailto:[EMAIL PROTECTED]] > Sent: 07 January 2003 21:08 > To: DebianSecurity > Subject: raw disk access > > > Hi. > > As a Debian user, i am posting to this list first in the hopes > that what i am looking for can be found as a Debian package. > > i am looking for forensics tools that can be used in computer > crime investigations, and am particularly interesting in a tool > that provides raw drive (hard, floppy, CD, DVD, etc.) access in > order to create complete and accurate drive images. > > If such a tool does not exist within Debian, is anyone aware of > any application (GPLed, please) that does? Failing that, i am > willing to write my own tool, if necessary, and would appreciate > any pointers to good reference material (raw drive access and > how to work with the images created). > > If it helps, i am running with the latest 'unstable' packages. > > Many thanks. > > -- > viv <[EMAIL PROTECTED]> -- viv <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
RE: raw disk access
The best that can be achieved is via 'dd'. however it is actually impossible to get _real_ raw disk access due to the disk IO controllers. As far as I know, all disk IO controllers have automatic data correction etc and so do hard disks. An accurate copy of the surface of the disk cannot be gained by this method. Has anyone any ideas on whether it's possible to bypass the automatic checks performed by the IO controllers? Colin Solution City Ltd http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED] Sent: 07 January 2003 21:08 To: DebianSecurity Subject: raw disk access Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv <[EMAIL PROTECTED]>
RE: raw disk access
The best that can be achieved is via 'dd'. however it is actually impossible to get _real_ raw disk access due to the disk IO controllers. As far as I know, all disk IO controllers have automatic data correction etc and so do hard disks. An accurate copy of the surface of the disk cannot be gained by this method. Has anyone any ideas on whether it's possible to bypass the automatic checks performed by the IO controllers? Colin Solution City Ltd http://www.solution-city.com -Original Message- From: viv [mailto:[EMAIL PROTECTED]] Sent: 07 January 2003 21:08 To: DebianSecurity Subject: raw disk access Hi. As a Debian user, i am posting to this list first in the hopes that what i am looking for can be found as a Debian package. i am looking for forensics tools that can be used in computer crime investigations, and am particularly interesting in a tool that provides raw drive (hard, floppy, CD, DVD, etc.) access in order to create complete and accurate drive images. If such a tool does not exist within Debian, is anyone aware of any application (GPLed, please) that does? Failing that, i am willing to write my own tool, if necessary, and would appreciate any pointers to good reference material (raw drive access and how to work with the images created). If it helps, i am running with the latest 'unstable' packages. Many thanks. -- viv <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh and lastlog
Hi, sorry for replying to my own posting, but of course it should read * /var/log/lastlog not world readable instead of > * /var/log/wtmp not world readable Cheers, Thomas
Re: ssh and lastlog
Hi, sorry for replying to my own posting, but of course it should read * /var/log/lastlog not world readable instead of > * /var/log/wtmp not world readable Cheers, Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
