track bandwith used

track bandwith used

[Peter Marshall]

Hi again,

I was also wondering if anyone knows a way to track bandwith being used
through the firewall .......
I use squid as a proxy behind the firewall if that helps at all ...

Thank you again,
Peter

RE: track bandwith used

[Piszcz, Justin Michael]

There are a plethora of ways to do this:

You can setup rules to watch the amount of bytes going through them
using ipacct w/iptables(1), or use something else, like my favorite,
vnstat.

MRTGFE (front-end) can also calculate bandwidth from MRTG's logs,
although it will not be as accurate as using vnstat or iptables rules.

Examples provided below:

$ vnstat-eth1
Database updated: Wed Jun 30 09:30:01 2004

        eth1

           received:         10,232 MB (68.0%)
        transmitted:          4,819 MB (32.0%)
              total:         15,052 MB

                        rx     |     tx     |  total
        -----------------------+------------+-----------
        yesterday    109.39 MB |   92.08 MB |  201.47 MB
            today     44.30 MB |   42.55 MB |   86.86 MB
        -----------------------+------------+-----------
        estimated       110 MB |     105 MB |     215 MB

$ vnstat-eth1 -m

        eth1

           month        rx      |       tx      |    total
        ------------------------+---------------+---------------
          Mar '04    628.07 MB  |    298.45 MB  |    926.52 MB
          Apr '04     3,793 MB  |     1,189 MB  |     4,982 MB
          May '04     3,243 MB  |     1,916 MB  |     5,159 MB
          Jun '04     2,568 MB  |     1,415 MB  |     3,983 MB
        ------------------------+---------------+---------------
        estimated     2,622 MB  |     1,445 MB  |     4,067 MB

$ vnstat-eth1 -d

        eth1

            day         rx      |     tx      |  total
        ------------------------+-------------+--------------
           01.06.    113.69 MB  |   55.42 MB  |  169.12 MB
           02.06.    113.55 MB  |   54.73 MB  |  168.28 MB
           03.06.    130.42 MB  |   53.92 MB  |  184.35 MB
           04.06.    121.90 MB  |   51.18 MB  |  173.08 MB
           05.06.    109.29 MB  |   17.41 MB  |  126.70 MB
           06.06.    132.68 MB  |   14.20 MB  |  146.89 MB
           07.06.     82.54 MB  |   42.67 MB  |  125.22 MB
           08.06.     97.28 MB  |   63.38 MB  |  160.67 MB
           09.06.     95.96 MB  |   65.29 MB  |  161.25 MB
           10.06.    101.92 MB  |   74.46 MB  |  176.38 MB
           11.06.    123.68 MB  |  109.23 MB  |  232.91 MB
           12.06.     82.51 MB  |   47.83 MB  |  130.34 MB
           13.06.     49.64 MB  |    9.30 MB  |   58.94 MB
           14.06.     83.63 MB  |   48.73 MB  |  132.36 MB
           15.06.     64.12 MB  |   30.81 MB  |   94.93 MB
           16.06.     68.01 MB  |   47.18 MB  |  115.20 MB
           17.06.     69.38 MB  |   41.79 MB  |  111.17 MB
           18.06.     63.69 MB  |   27.17 MB  |   90.86 MB
           19.06.     51.91 MB  |   10.50 MB  |   62.42 MB
           20.06.     53.63 MB  |   10.54 MB  |   64.18 MB
           21.06.     84.77 MB  |   60.95 MB  |  145.72 MB
           22.06.     83.01 MB  |   60.98 MB  |     144 MB
           23.06.     49.68 MB  |   57.53 MB  |  107.22 MB
           24.06.     95.58 MB  |   79.03 MB  |  174.61 MB
           25.06.     92.69 MB  |   70.15 MB  |  162.85 MB
           26.06.     64.53 MB  |   12.19 MB  |   76.72 MB
           27.06.     54.97 MB  |   11.99 MB  |   66.96 MB
           28.06.     79.98 MB  |   52.11 MB  |  132.10 MB
           29.06.    109.39 MB  |   92.08 MB  |  201.47 MB
           30.06.     44.30 MB  |   42.55 MB  |   86.86 MB
        ------------------------+-------------+--------------
         estimated      110 MB  |     105 MB  |     215 MB



-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org] On Behalf Of Peter Marshall
Sent: Wednesday, June 30, 2004 9:07 AM
To: netfilter
Subject: track bandwith used

Hi again,

I was also wondering if anyone knows a way to track bandwith being used
through the firewall .......
I use squid as a proxy behind the firewall if that helps at all ...

Thank you again,
Peter

Re: track bandwith used

[Antony Stone]

On Wednesday 30 June 2004 2:07 pm, Peter Marshall wrote:

> Hi again,
>
> I was also wondering if anyone knows a way to track bandwith being used
> through the firewall .......

Well, there are plenty of network monitoring tools which will give you this 
sort of information as an aggregate figure for an interface, or broken down 
by source/destination address, port number etc - iptraf is not a bad start to 
see what can be done.

Other than that you can use netfilter rules to count the packets & bytes, and 
then use a cron job to record the counts at whatever intervals you want 
(every minute, every hour, every day...), and then process them yourself.

Things I would mention if you're going to try the latter option:

1. Most packets do not match against rules in the nat table, so don't try 
counting those - the only packets which match these are the first of each 
connection - all the rest are processed invisibly by netfilter in the 
background, and your rules don't see them (this is also the reason why you 
should never set a default DROP policy on a nat table!)

2. If you are using a standard -m state --state ESTABLISHED,RELATED rule in 
your FORWARD chain, remember that nearly all packets will match that, no 
matter which direction they're going through the machine, and which port/s 
they're going to or from.   Again, most of the rules in your FORWARD chain 
will only match the first packet of a given connection, so you won't see much 
traffic on these rules either (although they can give you a useful indication 
of the number of connections of that type which get created).

3. The FORWARD mangle table can be a good place to put rules which will see 
all traffic going through the system.

4. For accounting purposes, you can quite readily use rules with no target 
(eg: iptables -A FORWARD -p tcp --dport 25); these will make no difference to 
whether the packets are ACCEPTed, DROPped, LOGged, REJECTed, or whatever 
(obviously you need separate rules to do that somewhere else), but the packet 
& byte counters from iptables -L -nvx will show you how many of that type of 
packet were seen.   You can make the rules as specific as you like if you 
want to count certain connections in minute detail (eg: iptables -A FORWARD 
-p tcp --dport 25 -s my.mail.ser.ver -d ISP.mail.ser.ver)

5. Don't overlook the raw packet & byte counts available from ifconfig if all 
you want to do is monitor traffic in & out of an interface.

Hope this give you some ideas.

Regards,

Antony.

-- 
"The future is already here.   It's just not evenly distributed yet."

 - William Gibson

                                                     Please reply to the list;
                                                           please don't CC me.

RE: track bandwith used

[Aldo Lagana]

iptraf 

-----Original Message-----
From: Antony Stone [mailto:Antony@Soft-Solutions.co.uk]
Sent: Wednesday, June 30, 2004 9:41 AM
To: netfilter
Subject: Re: track bandwith used


On Wednesday 30 June 2004 2:07 pm, Peter Marshall wrote:

> Hi again,
>
> I was also wondering if anyone knows a way to track bandwith being used
> through the firewall .......

Well, there are plenty of network monitoring tools which will give you this 
sort of information as an aggregate figure for an interface, or broken down 
by source/destination address, port number etc - iptraf is not a bad start to 
see what can be done.

Other than that you can use netfilter rules to count the packets & bytes, and 
then use a cron job to record the counts at whatever intervals you want 
(every minute, every hour, every day...), and then process them yourself.

Things I would mention if you're going to try the latter option:

1. Most packets do not match against rules in the nat table, so don't try 
counting those - the only packets which match these are the first of each 
connection - all the rest are processed invisibly by netfilter in the 
background, and your rules don't see them (this is also the reason why you 
should never set a default DROP policy on a nat table!)

2. If you are using a standard -m state --state ESTABLISHED,RELATED rule in 
your FORWARD chain, remember that nearly all packets will match that, no 
matter which direction they're going through the machine, and which port/s 
they're going to or from.   Again, most of the rules in your FORWARD chain 
will only match the first packet of a given connection, so you won't see much 
traffic on these rules either (although they can give you a useful indication 
of the number of connections of that type which get created).

3. The FORWARD mangle table can be a good place to put rules which will see 
all traffic going through the system.

4. For accounting purposes, you can quite readily use rules with no target 
(eg: iptables -A FORWARD -p tcp --dport 25); these will make no difference to 
whether the packets are ACCEPTed, DROPped, LOGged, REJECTed, or whatever 
(obviously you need separate rules to do that somewhere else), but the packet 
& byte counters from iptables -L -nvx will show you how many of that type of 
packet were seen.   You can make the rules as specific as you like if you 
want to count certain connections in minute detail (eg: iptables -A FORWARD 
-p tcp --dport 25 -s my.mail.ser.ver -d ISP.mail.ser.ver)

5. Don't overlook the raw packet & byte counts available from ifconfig if all 
you want to do is monitor traffic in & out of an interface.

Hope this give you some ideas.

Regards,

Antony.

-- 
"The future is already here.   It's just not evenly distributed yet."

 - William Gibson

                                                     Please reply to the list;
                                                           please don't CC me.

Re: track bandwith used

[Peter Marshall]

ya, that was great.  I guess there was one thing that you said that worried
me ... you said almost all packets will match the ESTABLISHED,RELATED check
on the forwared chain ... would that not be a bad thing ... is it dangerous
to have RELATED as an option on the FORWAED CHAIN.

???

Thankls

----- Original Message ----- 
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 10:41 AM
Subject: Re: track bandwith used


On Wednesday 30 June 2004 2:07 pm, Peter Marshall wrote:

> Hi again,
>
> I was also wondering if anyone knows a way to track bandwith being used
> through the firewall .......

Well, there are plenty of network monitoring tools which will give you this
sort of information as an aggregate figure for an interface, or broken down
by source/destination address, port number etc - iptraf is not a bad start
to
see what can be done.

Other than that you can use netfilter rules to count the packets & bytes,
and
then use a cron job to record the counts at whatever intervals you want
(every minute, every hour, every day...), and then process them yourself.

Things I would mention if you're going to try the latter option:

1. Most packets do not match against rules in the nat table, so don't try
counting those - the only packets which match these are the first of each
connection - all the rest are processed invisibly by netfilter in the
background, and your rules don't see them (this is also the reason why you
should never set a default DROP policy on a nat table!)

2. If you are using a standard -m state --state ESTABLISHED,RELATED rule in
your FORWARD chain, remember that nearly all packets will match that, no
matter which direction they're going through the machine, and which port/s
they're going to or from.   Again, most of the rules in your FORWARD chain
will only match the first packet of a given connection, so you won't see
much
traffic on these rules either (although they can give you a useful
indication
of the number of connections of that type which get created).

3. The FORWARD mangle table can be a good place to put rules which will see
all traffic going through the system.

4. For accounting purposes, you can quite readily use rules with no target
(eg: iptables -A FORWARD -p tcp --dport 25); these will make no difference
to
whether the packets are ACCEPTed, DROPped, LOGged, REJECTed, or whatever
(obviously you need separate rules to do that somewhere else), but the
packet
& byte counters from iptables -L -nvx will show you how many of that type of
packet were seen.   You can make the rules as specific as you like if you
want to count certain connections in minute detail (eg: iptables -A FORWARD
-p tcp --dport 25 -s my.mail.ser.ver -d ISP.mail.ser.ver)

5. Don't overlook the raw packet & byte counts available from ifconfig if
all
you want to do is monitor traffic in & out of an interface.

Hope this give you some ideas.

Regards,

Antony.

-- 
"The future is already here.   It's just not evenly distributed yet."

 - William Gibson

                                                     Please reply to the
list;
                                                           please don't CC
me.

Re: track bandwith used

[Antony Stone]

On Wednesday 30 June 2004 3:07 pm, Peter Marshall wrote:

> ya, that was great.  I guess there was one thing that you said that worried
> me ... you said almost all packets will match the ESTABLISHED,RELATED check
> on the forwared chain ... would that not be a bad thing ... is it dangerous
> to have RELATED as an option on the FORWARD CHAIN. ???

No, in fact it is essential for many purposes.

1. The FTP data channel will be matched as RELATED to the initial control 
channel, so RELATED in FORWARD is needed if you are going to allow FTP.

2. ICMP error responses (usually seen in reply to UDP packets which fail for 
some reason) match as RELATED, and (as is already being discussed on another 
thread on this list), it is not a good idea to stop all ICMP packets from 
getting through your firewall.

There are other examples of why RELATED packets are necessary, but these are 
the most common and obvious ones.

You will generally find that all tutorials and netfilter examples match 
ESTABLISHED and RELATED in the FORWARD chain.

What makes you think that RELATED is dangerous?

Regards,

Antony.

-- 
The words "e pluribus unum" on the Great Seal of the United States are from a 
poem by Virgil entitled "Moretum", which is about cheese and garlic salad 
dressing.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: track bandwith used

[Peter Marshall]

You could make a connection out to a remote server.  That remote server
might try to make a connection back to us that has nothing to do with the
reason we connectd to them.  But the server may see it as related and allow
it.


----- Original Message ----- 
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 1:17 PM
Subject: Re: track bandwith used


On Wednesday 30 June 2004 3:07 pm, Peter Marshall wrote:

> ya, that was great.  I guess there was one thing that you said that
worried
> me ... you said almost all packets will match the ESTABLISHED,RELATED
check
> on the forwared chain ... would that not be a bad thing ... is it
dangerous
> to have RELATED as an option on the FORWARD CHAIN. ???

No, in fact it is essential for many purposes.

1. The FTP data channel will be matched as RELATED to the initial control
channel, so RELATED in FORWARD is needed if you are going to allow FTP.

2. ICMP error responses (usually seen in reply to UDP packets which fail for
some reason) match as RELATED, and (as is already being discussed on another
thread on this list), it is not a good idea to stop all ICMP packets from
getting through your firewall.

There are other examples of why RELATED packets are necessary, but these are
the most common and obvious ones.

You will generally find that all tutorials and netfilter examples match
ESTABLISHED and RELATED in the FORWARD chain.

What makes you think that RELATED is dangerous?

Regards,

Antony.

-- 
The words "e pluribus unum" on the Great Seal of the United States are from
a
poem by Virgil entitled "Moretum", which is about cheese and garlic salad
dressing.

                                                     Please reply to the
list;
                                                           please don't CC
me.

Re: track bandwith used

[Antony Stone]

On Wednesday 30 June 2004 2:07 pm, Peter Marshall wrote:

> Hi again,
>
> I was also wondering if anyone knows a way to track bandwith being used
> through the firewall .......

Well, there are plenty of network monitoring tools which will give you this 
sort of information as an aggregate figure for an interface, or broken down 
by source/destination address, port number etc - iptraf is not a bad start to 
see what can be done.

Other than that you can use netfilter rules to count the packets & bytes, and 
then use a cron job to record the counts at whatever intervals you want 
(every minute, every hour, every day...), and then process them yourself.

Things I would mention if you're going to try the latter option:

1. Most packets do not match against rules in the nat table, so don't try 
counting those - the only packets which match these are the first of each 
connection - all the rest are processed invisibly by netfilter in the 
background, and your rules don't see them (this is also the reason why you 
should never set a default DROP policy on a nat table!)

2. If you are using a standard -m state --state ESTABLISHED,RELATED rule in 
your FORWARD chain, remember that nearly all packets will match that, no 
matter which direction they're going through the machine, and which port/s 
they're going to or from.   Again, most of the rules in your FORWARD chain 
will only match the first packet of a given connection, so you won't see much 
traffic on these rules either (although they can give you a useful indication 
of the number of connections of that type which get created).

3. The FORWARD mangle table can be a good place to put rules which will see 
all traffic going through the system.

4. For accounting purposes, you can quite readily use rules with no target 
(eg: iptables -A FORWARD -p tcp --dport 25); these will make no difference to 
whether the packets are ACCEPTed, DROPped, LOGged, REJECTed, or whatever 
(obviously you need separate rules to do that somewhere else), but the packet 
& byte counters from iptables -L -nvx will show you how many of that type of 
packet were seen.   You can make the rules as specific as you like if you 
want to count certain connections in minute detail (eg: iptables -A FORWARD 
-p tcp --dport 25 -s my.mail.ser.ver -d ISP.mail.ser.ver)

5. Don't overlook the raw packet & byte counts available from ifconfig if all 
you want to do is monitor traffic in & out of an interface.

Hope this give you some ideas.

Regards,

Antony.

-- 
"The future is already here.   It's just not evenly distributed yet."

 - William Gibson

                                                     Please reply to the list;
                                                           please don't CC me.

Re: track bandwith used

[Antony Stone]

On Wednesday 30 June 2004 5:51 pm, Peter Marshall wrote:

> You could make a connection out to a remote server.  That remote server
> might try to make a connection back to us that has nothing to do with the
> reason we connected to them.

Such a connection would not be regarded as RELATED by the netfilter code.

>  But the server may see it as related and allow it.

I think you should read about netfilter's definition of RELATED.   It doesn't 
just mean "any packet which comes back from an IP address we're already 
talking to".

For example, I said that FTP data connections were RELATED to the FTP control 
connection - but that is only if you have loaded the FTP Conntrack Helper 
module, or compiled FTP Conntrack support into your kernel.   That helper is 
what RELATEs the two parts of FTP together in netfilter.

Basically, if you don't have a helper module which understands why a 
connection should be RELATED to another one, then it won't be.

Arbitrary packets from IP addresses which happen to be part of an ESTABLISHED 
connection don't count - they will be seen as NEW incoming connections, and 
make their own way through your ruleset (until they are persumably DROPped), 
having no assiciation whatever to anything else which may be in your 
connection tracking table.

Hope this clarifies things?

Regards,

Antony.

-- 
Ramdisk is not an installation procedure.

                                                     Please reply to the list;
                                                           please don't CC me.

Re: track bandwith used

[Peter Marshall]

yes it does.  Thank you very much.  I have been looking for an explanation
like that on the net. :)

Do you have a link to where this netfilter documentation is ?

Peter

----- Original Message ----- 
From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
To: "netfilter" <netfilter@lists.netfilter.org>
Sent: Wednesday, June 30, 2004 2:07 PM
Subject: Re: track bandwith used


On Wednesday 30 June 2004 5:51 pm, Peter Marshall wrote:

> You could make a connection out to a remote server.  That remote server
> might try to make a connection back to us that has nothing to do with the
> reason we connected to them.

Such a connection would not be regarded as RELATED by the netfilter code.

>  But the server may see it as related and allow it.

I think you should read about netfilter's definition of RELATED.   It
doesn't
just mean "any packet which comes back from an IP address we're already
talking to".

For example, I said that FTP data connections were RELATED to the FTP
control
connection - but that is only if you have loaded the FTP Conntrack Helper
module, or compiled FTP Conntrack support into your kernel.   That helper is
what RELATEs the two parts of FTP together in netfilter.

Basically, if you don't have a helper module which understands why a
connection should be RELATED to another one, then it won't be.

Arbitrary packets from IP addresses which happen to be part of an
ESTABLISHED
connection don't count - they will be seen as NEW incoming connections, and
make their own way through your ruleset (until they are persumably DROPped),
having no assiciation whatever to anything else which may be in your
connection tracking table.

Hope this clarifies things?

Regards,

Antony.

-- 
Ramdisk is not an installation procedure.

                                                     Please reply to the
list;
                                                           please don't CC
me.

Re: track bandwith used

[Antony Stone]

On Wednesday 30 June 2004 7:46 pm, Peter Marshall wrote:

> yes it does.  Thank you very much.  I have been looking for an explanation
> like that on the net. :)
>
> Do you have a link to where this netfilter documentation is ?

These might help fill in a few more details:

http://iptables-tutorial.frozentux.net/iptables-tutorial.html#USERLANDSTATES
http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html

Antony.

> ----- Original Message -----
> From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
> To: "netfilter" <netfilter@lists.netfilter.org>
> Sent: Wednesday, June 30, 2004 2:07 PM
> Subject: Re: track bandwith used
>
> On Wednesday 30 June 2004 5:51 pm, Peter Marshall wrote:
> > You could make a connection out to a remote server.  That remote server
> > might try to make a connection back to us that has nothing to do with the
> > reason we connected to them.
>
> Such a connection would not be regarded as RELATED by the netfilter code.
>
> >  But the server may see it as related and allow it.
>
> I think you should read about netfilter's definition of RELATED.   It
> doesn't
> just mean "any packet which comes back from an IP address we're already
> talking to".
>
> For example, I said that FTP data connections were RELATED to the FTP
> control
> connection - but that is only if you have loaded the FTP Conntrack Helper
> module, or compiled FTP Conntrack support into your kernel.   That helper
> is what RELATEs the two parts of FTP together in netfilter.
>
> Basically, if you don't have a helper module which understands why a
> connection should be RELATED to another one, then it won't be.
>
> Arbitrary packets from IP addresses which happen to be part of an
> ESTABLISHED
> connection don't count - they will be seen as NEW incoming connections, and
> make their own way through your ruleset (until they are persumably
> DROPped), having no assiciation whatever to anything else which may be in
> your connection tracking table.
>
> Hope this clarifies things?
>
> Regards,
>
> Antony.

-- 
The truth is rarely pure, and never simple.

 - Oscar Wilde

                                                     Please reply to the list;
                                                           please don't CC me.

Re: track bandwith used

[Askar Ali Khan]

MRTG is very good for monitoring bandwidth utiliization, web interface
is very cool it shows your inbound and outbound traffic graphically.

http://people.ee.ethz.ch/~oetiker/webtools/mrtg/ 
is a good place learning about MRTG and 
http://people.ee.ethz.ch/~oetiker/webtools/mrtg/mrtg-unix-guide.html

is a very nice walk through to install and configure mrtg on unix, linux

regards



On Wed, 30 Jun 2004 23:03:05 +0100, Antony Stone
<antony@soft-solutions.co.uk> wrote:
> 
> On Wednesday 30 June 2004 7:46 pm, Peter Marshall wrote:
> 
> > yes it does.  Thank you very much.  I have been looking for an explanation
> > like that on the net. :)
> >
> > Do you have a link to where this netfilter documentation is ?
> 
> These might help fill in a few more details:
> 
> http://iptables-tutorial.frozentux.net/iptables-tutorial.html#USERLANDSTATES
> http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html
> 
> Antony.
> 
> > ----- Original Message -----
> > From: "Antony Stone" <Antony@Soft-Solutions.co.uk>
> > To: "netfilter" <netfilter@lists.netfilter.org>
> > Sent: Wednesday, June 30, 2004 2:07 PM
> > Subject: Re: track bandwith used
> >
> > On Wednesday 30 June 2004 5:51 pm, Peter Marshall wrote:
> > > You could make a connection out to a remote server.  That remote server
> > > might try to make a connection back to us that has nothing to do with the
> > > reason we connected to them.
> >
> > Such a connection would not be regarded as RELATED by the netfilter code.
> >
> > >  But the server may see it as related and allow it.
> >
> > I think you should read about netfilter's definition of RELATED.   It
> > doesn't
> > just mean "any packet which comes back from an IP address we're already
> > talking to".
> >
> > For example, I said that FTP data connections were RELATED to the FTP
> > control
> > connection - but that is only if you have loaded the FTP Conntrack Helper
> > module, or compiled FTP Conntrack support into your kernel.   That helper
> > is what RELATEs the two parts of FTP together in netfilter.
> >
> > Basically, if you don't have a helper module which understands why a
> > connection should be RELATED to another one, then it won't be.
> >
> > Arbitrary packets from IP addresses which happen to be part of an
> > ESTABLISHED
> > connection don't count - they will be seen as NEW incoming connections, and
> > make their own way through your ruleset (until they are persumably
> > DROPped), having no assiciation whatever to anything else which may be in
> > your connection tracking table.
> >
> > Hope this clarifies things?
> >
> > Regards,
> >
> > Antony.
> 
> -- 
> The truth is rarely pure, and never simple.
> 
>  - Oscar Wilde
> 
> 
> 
>                                                      Please reply to the list;
>                                                            please don't CC me.
> 
>