On Fri, 2011-11-18 at 19:36 +0100, Karsten Bräckelmann wrote:
> On Fri, 2011-11-18 at 08:16 +, Tom wrote:
> > (apologies if the html doesn't end up translating well!)
Damn, sorry. My attempt at pruning the large tables seriously fucked up
the formatting. :/
> > output from top, after running
On Fri, 2011-11-18 at 08:16 +, Tom wrote:
> Here's the stats from my cluster at the moment (8am) (these figures wll
> ramp up considerably!) (apologies if the html doesn't end up
> translating well!)
>
> Server
> Load Avg
> Processed/Min
> Busy Child Proc
> Proc Time
> 10.44.219.192
> 0.34
> 4
On Thu, 2011-11-17 at 15:55 +, Tom wrote:
> SPAMDOPTIONS="-d -L -i 10.44.219.208 -A 10.44.217.0/20 -m 40 -q -x -u
> spamd --min-children=40"
Do you really run a single spamd server, serving a /20 of potential SMTP
servers?
Also, you configured spamd to try hard and always keep exactly 40
chi
have you turned off RBLs and other network tests you dont need and disabled
any non-standard rules and plugins?
if you are using RBLS's have a a caching nameserver on the SA machine
itself (even if your 'local' DNS server is only a couple of milliseconds
away a caching namesserver on the box itsel
* Walter Hurry :
> On Fri, 29 Jul 2011 22:44:14 +0200, Patrick Ben Koetter wrote:
>
> > * Walter Hurry :
> >> On Fri, 29 Jul 2011 21:56:03 +0200, Patrick Ben Koetter wrote:
> >>
> >> > Using an asynchronous approach using different databases is
> >> > interesting, but as I understand the solution
* David F. Skoll :
> On Fri, 29 Jul 2011 22:41:18 +0200
> Patrick Ben Koetter wrote:
> > That's ~230 msg/sec. Ever took it to 500 msg/sec?
>
> No, we lack the hardware to do that. The 230 msgs/sec rate was
> reached by a customer with a lot more money for hardware than we have. :)
Isn't that th
On Fri, 29 Jul 2011 22:44:14 +0200, Patrick Ben Koetter wrote:
> * Walter Hurry :
>> On Fri, 29 Jul 2011 21:56:03 +0200, Patrick Ben Koetter wrote:
>>
>> > Using an asynchronous approach using different databases is
>> > interesting, but as I understand the solution discussed addresses
>> > read
On Fri, 29 Jul 2011 22:41:18 +0200
Patrick Ben Koetter wrote:
> That's where your product an SA differ, right? SA writes more to
> PostgreSQL e.g. it also stores Bayes tokens in PostgreSQL.
Right.
> That's ~230 msg/sec. Ever took it to 500 msg/sec?
No, we lack the hardware to do that. The 230
* Walter Hurry :
> On Fri, 29 Jul 2011 21:56:03 +0200, Patrick Ben Koetter wrote:
>
> > Using an asynchronous approach using different databases is interesting,
> > but as I understand the solution discussed addresses read performace. I
> > am interested in write performance. How far could you tak
* David F. Skoll :
> On Fri, 29 Jul 2011 21:56:03 +0200
> Patrick Ben Koetter wrote:
>
> > I am interested in write performance. How far could
> > you take it before PSQL topped out? Any special hardware in use?
>
> We're not writing very much to PostgreSQL. For each message, we
> write a small
On Fri, 29 Jul 2011 21:56:03 +0200
Patrick Ben Koetter wrote:
> I am interested in write performance. How far could
> you take it before PSQL topped out? Any special hardware in use?
We're not writing very much to PostgreSQL. For each message, we
write a small row containing the internal incide
On Fri, 29 Jul 2011 21:56:03 +0200, Patrick Ben Koetter wrote:
> Using an asynchronous approach using different databases is interesting,
> but as I understand the solution discussed addresses read performace. I
> am interested in write performance. How far could you take it before
> PSQL topped o
* David F. Skoll :
> > Claiming SA "ignores large sites" because it doesn't have a complex
> > CDB backend is ridiculous.
>
> I'm not at all claiming SA ignores large sites. I'm claiming that people
> with *your* attitude ("Other 99.9% of user don't really care...") are
> ignoring large sites.
c
On Fri, 29 Jul 2011 22:35:01 +0300
Henrik K wrote:
[...]
> Feel free to donate your code for SA and stop the pointless bashing.
Um? I'm not "bashing" SA. I think it's a fine piece of work. All I asked
is if anyone has made a CDB back-end for SA and I explained why I thought
it might be a goo
On Fri, Jul 29, 2011 at 03:12:40PM -0400, David F. Skoll wrote:
> On Fri, 29 Jul 2011 22:02:10 +0300
> Henrik K wrote:
>
> > Let's be serious. Only people that really need it are the ones with a
> > custom high volume distributed spam appliance thing. Other 99.9% of
> > users don't really care if
On Fri, 29 Jul 2011 22:02:10 +0300
Henrik K wrote:
> Let's be serious. Only people that really need it are the ones with a
> custom high volume distributed spam appliance thing. Other 99.9% of
> users don't really care if Bayes lookups take 100ms or whatever. It's
> peanuts compared to other proc
On Fri, Jul 29, 2011 at 01:00:52PM -0400, David F. Skoll wrote:
>
> That's why I was wondering if anyone had looked at using CDB with SA's
> Bayes module.
Let's be serious. Only people that really need it are the ones with a custom
high volume distributed spam appliance thing. Other 99.9% of user
On Fri, 29 Jul 2011 12:45:53 -0400
Michael Scheidell wrote:
> you need custom code to sync bayes? do expires? or just interesting
> entries in local.cf?
Ah, I should have mentioned we don't use SpamAssassin's Bayes module. We
use our own Bayes implementation.
That's why I was wondering if an
On 7/29/11 12:41 PM, David F. Skoll wrote:
On Fri, 29 Jul 2011 12:31:01 -0400
Michael Scheidell wrote:
ok, but are you using cdb or postgresql for bayes?
cdb for the Bayes data; PostgreSQL for the journal table.
Regards,
David.
you need custom code to sync bayes? do expires? or just intere
On Fri, 29 Jul 2011 12:31:01 -0400
Michael Scheidell wrote:
> ok, but are you using cdb or postgresql for bayes?
cdb for the Bayes data; PostgreSQL for the journal table.
Regards,
David.
On 7/29/11 12:20 PM, David F. Skoll wrote:
This INSERT-only
operation cannot block under PostgreSQL MVCC.
ok, but are you using cdb or postgresql for bayes?
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
>*| *SECNAP Network Security Corporation
* Best Mobile Solutions Product
On Fri, 29 Jul 2011 11:59:14 -0400
Michael Scheidell wrote:
> in mysql, we don't journal. what does that journaling time do to SA
> processing times? Id hate to think we go from 1 s/email processing
> time to 60 seconds or something while journal is locked.
Journalling *improves* training spee
On 7/29/11 11:47 AM, David F. Skoll wrote:
CDB is*very* fast. If you journal your Bayes training and run the
journal every 5-10 minutes, CDB can easily keep up even with a 2GB
Bayes database.
in mysql, we don't journal. what does that journaling time do to SA
processing times? Id hate to thin
On Fri, 29 Jul 2011 11:36:52 -0400
Michael Scheidell wrote:
> On 7/29/11 11:33 AM, David F. Skoll wrote:
> > Has anyone investigated writing a CDB backend for SpamAssassin's
> > Bayes implementation? I'm guessing the need to rewrite the DB each
> > time makes it a bit complex.
> esp for people
On 7/29/11 11:33 AM, David F. Skoll wrote:
Has anyone investigated writing a CDB backend for SpamAssassin's Bayes
implementation? I'm guessing the need to rewrite the DB each time makes
it a bit complex.
esp for people with 2gb db's?
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
On Fri, 18 Mar 2011 04:22:40 +0100, Karsten Bräckelmann
wrote:
>On Thu, 2011-03-17 at 12:58 +, Nigel Frankcom wrote:
>> Unrelated but reminded me I hadn't posted a thanks to all those that
>> responded about the sa-update rules. That's partly because I'm
>> awaiting permission from clients to
On Thu, 2011-03-17 at 12:58 +, Nigel Frankcom wrote:
> Unrelated but reminded me I hadn't posted a thanks to all those that
> responded about the sa-update rules. That's partly because I'm
> awaiting permission from clients to add their mails to the corpus.
Unrelated indeed. ;) That short ran
Unrelated but reminded me I hadn't posted a thanks to all those that
responded about the sa-update rules. That's partly because I'm
awaiting permission from clients to add their mails to the corpus.
So, thanks all. Apologies for forgetting my manners.
Have no clue about Spear Phishing other than
On 3/16/11 11:50 PM, Warren Togami Jr. wrote:
Karsten, thanks for pointing out that this is the same guy. I had
missed that.
Warren
Ditto. I was about to tell him how to stop spear phishing.
thanks.
--
Michael Scheidell, CTO
o: 561-999-5000
d: 561-948-2259
ISN: 1259*1300
>*| *SECNAP N
On Wed, 2011-03-16 at 17:50 -1000, Warren Togami Jr. wrote:
> Karsten, thanks for pointing out that this is the same guy. I had
> missed that.
Heh, you're welcome -- though that would be referring to my other reply
to this (sub-) thread. ;)
Sometimes it helps to identify patterns. Sometimes it
On 3/16/2011 5:45 PM, Karsten Bräckelmann wrote:
On Wed, 2011-03-16 at 20:30 -0700, John Hardin wrote:
On Thu, 17 Mar 2011, Hamad Ali wrote:
Probably I need to participate on nightly checks to improve phish and
lower false positives.
More masscheck participants are always welcome!
No.
Th
On Wed, 2011-03-16 at 20:30 -0700, John Hardin wrote:
> On Thu, 17 Mar 2011, Hamad Ali wrote:
> > Probably I need to participate on nightly checks to improve phish and
> > lower false positives.
>
> More masscheck participants are always welcome!
No.
There is this thing called trust. Credibili
So this actually is a reply to the last post to your previous thread
"how to disable network tests". Merely changing the subject and pruning
the quote from the body -- surprise -- does NOT make it a new thread. On
the up-side, it appears you at least did read (I mean "keep" here) the
thread. Encour
On 3/16/2011 4:08 PM, Hamad Ali wrote:
Hi folks -- wondering if anyone has monitored SA's performance against
phishing mails. SA is able to detect 86% of phishing emails my clients
get, with 0.5% false positives on all the ham. It seems non-phish-SPAM
is easier to be detected than phish (~99% for
On Thu, 17 Mar 2011, Hamad Ali wrote:
Hi folks -- wondering if anyone has monitored SA's performance against
phishing mails. SA is able to detect 86% of phishing emails my clients
get, with 0.5% false positives on all the ham. It seems non-phish-SPAM
is easier to be detected than phish (~99% f
Helmut Schneider wrote:
> with certain mails on FreeBSD 8.0 and SA 3.3.1 I have a performance
> problem:
I might have been able to "catch" a non-confident example mail[1] (bad
example because of the size, but an example).
While SA 3.2.5 needs ~45 seconds, with SA 3.3.1:
Jun 4 03:36:41.029 [564
On 6/3/2010 7:52 AM, Helmut Schneider wrote:
Helmut Schneider wrote:
with certain mails on FreeBSD 8.0 and SA 3.3.1 I have a performance
problem:
[...]
Any idea where to start?
Appendix: I set up a fresh and clean FreeBSD 8.0 with only SA 3.3.1 and
Perl 5.10.1_1 and the problem still pers
On 6/3/2010 12:02 PM, Charles Gregory wrote:
> On Thu, 3 Jun 2010, Helmut Schneider wrote:
>> I then started from scratch and tried with SA 3.2.5. The particular
>> body_tests take only 5 seconds (instead of 30).
>
> As I mentioned before, I noticed this difference myself, and presumed
> it was jus
On Thu, 3 Jun 2010, Mark Martinec wrote:
Here is one common problem of 'certain mail messages'
taking a long time to process - unresolvable for now:
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5590
Sorry, but that bug has been around since 3.2.3 - it would not explain a
sudden sixf
On Thursday 03 June 2010 18:02:23 Charles Gregory wrote:
> As I mentioned before, I noticed this difference myself, and presumed it
> was just a characteristic of the 'improved' logic for deep-scanning the
> body of emails, and perhaps just a larger number of rules than before
> Though I am sti
On Thu, 3 Jun 2010, Helmut Schneider wrote:
I then started from scratch and tried with SA 3.2.5. The particular
body_tests take only 5 seconds (instead of 30).
As I mentioned before, I noticed this difference myself, and presumed it
was just a characteristic of the 'improved' logic for deep-sc
Helmut Schneider wrote:
> with certain mails on FreeBSD 8.0 and SA 3.3.1 I have a performance
> problem:
[...]
> Any idea where to start?
Appendix: I set up a fresh and clean FreeBSD 8.0 with only SA 3.3.1 and
Perl 5.10.1_1 and the problem still persists. I then removed all
packages, compiled per
On Wed 02 Jun 2010 09:52:51 PM CEST, Helmut Schneider wrote
Hi,
with certain mails on FreeBSD 8.0 and SA 3.3.1 I have a performance
problem:
[/var/amavis/tmp]# spamassassin -D -lint <
doh :)
- != --
/var/amavis/tmp/amavis-20100602T192227-44802/email.txt
Jun 2 21:37:08.809 [50826] warn: T
David Michaels wrote:
> Quoting "Helmut Schneider" :
>
> > Hi,
> >
> > with certain mails on FreeBSD 8.0 and SA 3.3.1 I have a performance
> > problem:
[...]
> > timing: total 36840 ms - init: 3827 (10.4%), parse: 43 (0.1%),
> > extract_message_metadata: 822 (2.2%), get_uri_detail_list: 178
> >
Quoting "Helmut Schneider" :
Hi,
with certain mails on FreeBSD 8.0 and SA 3.3.1 I have a performance
problem:
[/var/amavis/tmp]# spamassassin -D -lint <
/var/amavis/tmp/amavis-20100602T192227-44802/email.txt
Jun 2 21:37:08.809 [50826] warn: The -l option has been deprecated and
is no longer s
Niels Przybilla <[EMAIL PROTECTED]> wrote:
> is there some kind of tool, that can monitor spamassassin and tell,
> how many mails are processed and how much is marked as spam ...
Depending on how SA integrates into your mail flow, and how/where it
logs, grep(1) along with wc(1) should suffice. Y
Daryl C. W. O'Shea wrote on Fri, 10 Aug 2007 02:20:23 -0400:
> 3.2.2 adds no new plugins that weren't in 3.2.1 or 3.2.0 for that
> matter. 3.2.0 is the last version to have plugins added to the release.
looking at the documentation I wonder if it was a good idea at all to add
this plugin to th
I'm posting a correction to my earlier post:
When I installed SA 3.2.2 from the package from spamassassin.org, it did
not add any plugins or uncomment any plugins.
On this one MX box I used the tarball from the mailscanner.info site
that had clamav and spamassassin 3.2.2 - I'm wondering if that p
[EMAIL PROTECTED] wrote:
I had posted before, but we couldn't figure out what was adding 3+
seconds processing time after I upgraded from SA 3.2.1 to 3.2.2.
It's the following plugin. I have tested loading and commenting out the
plugin - it's the culprit. SA 3.2.2 automatically adds several
sting) and fast
disks.
[EMAIL PROTECTED]
>
> Tom.
>
>
>
>
>
> Martin Hepworth <[EMAIL PROTECTED]>
> 27/09/2006 11:33
>
> To: [EMAIL PROTECTED]
> cc: users@spamassassin.apache.org
> Subject:Re: performance questi
* [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Hi,
>
> As we have seen the amount of incoming mail increase by 25% in the last
> few months, our customer is willing to invest in an extra mail relay.
> I was thinking about a system with Sun's T1 chipset, (like the sunfire
> T1000), I'm thinking the t
Subject: Re: performance question
[EMAIL PROTECTED] wrote:
> Hi,
>
> I would like your opinion if our mailrelay is properly tuned:
>
> I have a mailrelay (sendmail / mimedefang / spamassassin with fuzzyocr,
> razor and dcc) running on a Sun V20Z with 6 GB Ram and 2
* [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Hi,
>
> I would like your opinion if our mailrelay is properly tuned:
>
> I have a mailrelay (sendmail / mimedefang / spamassassin with fuzzyocr,
> razor and dcc) running on a Sun V20Z with 6 GB Ram and 2 AMD 1.8Ghz cpu's
> on Solaris 10.
> it curren
[EMAIL PROTECTED] wrote:
Hi,
I would like your opinion if our mailrelay is properly tuned:
I have a mailrelay (sendmail / mimedefang / spamassassin with fuzzyocr,
razor and dcc) running on a Sun V20Z with 6 GB Ram and 2 AMD 1.8Ghz cpu's
on Solaris 10.
it currently handles 95000 mails per da
On 16 May 2006 at 16:25, Justin Mason wrote:
>
> check to ensure your SA-Exim checks are conditional on a message size
> check; at least in 2005, it didn't use the recommended size limits by
> default for some reason, which meant it allowed spamd to balloon out
> of control. Maybe that is still t
check to ensure your SA-Exim checks are conditional on a message size
check; at least in 2005, it didn't use the recommended size limits by
default for some reason, which meant it allowed spamd to balloon out of
control. Maybe that is still the case. see this thread:
http://www.exim.org/mail-arch
On 16 May 2006 at 10:07, Matt Kettler wrote:
> Dermot Paikkos wrote:
> > Hi
> >
> > Spamassassin 3.02 running from SA-Exim (exim 4.5).
> >
> > OPTIONS="--nouser-config --max-children 6 --helper-home-
> > dir=/var/spool/spamassassin/ -s /var/log/spamd.log
> > --username=nobody"
> >
> > I recently
Dermot Paikkos wrote:
> Hi
>
> Spamassassin 3.02 running from SA-Exim (exim 4.5).
>
> OPTIONS="--nouser-config --max-children 6 --helper-home-
> dir=/var/spool/spamassassin/ -s /var/log/spamd.log --username=nobody"
>
> I recently went live with the above system and am noticing some very
> heavy m
Dermot Paikkos wrote:
Hi
Spamassassin 3.02 running from SA-Exim (exim 4.5).
OPTIONS="--nouser-config --max-children 6 --helper-home-
dir=/var/spool/spamassassin/ -s /var/log/spamd.log --username=nobody"
I recently went live with the above system and am noticing some very
heavy memory usage
Mike Jackson wrote:
> On my personal server, I'm running SA 3.0.4 with the user prefs,
> Bayes, and AWL in a MySQL database (mostly because it would be
> "cooler" that way). On my employer's server, I'm running the same SA
> version, but with file-based DBs and user prefs. We're going to be
> roll
Justin Mason wrote:
> Is there any diff between Amavisd and spamd's use of SQL for bayes?
> I wouldn't have thought so...
No, just the fact that it doesn't generally support (someone feel free
to correct me if I'm wrong) individualized configs (ie everything runs
as a single user). Anyone who a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Parker writes:
> Cami wrote:
>
> > Well.. As for setup, we're using amavisd-new which provides more
> > functionality than spamc/spamd (thus producing more sql queries).
> > As for average scantime per msg, no idea since i dont log that.
> >
Cami wrote:
> Well.. As for setup, we're using amavisd-new which provides more
> functionality than spamc/spamd (thus producing more sql queries).
> As for average scantime per msg, no idea since i dont log that.
> Hardware wise: Dell PowerEdge 2650, Dual 3.06GHz, 6gigs of ram,
> 5x32K RPM disks i
Michael Parker wrote:
Cami wrote:
SQL simply doesnt scale very well for bayes. We have a serverfarm of
12 spamassassin servers and storing bayes in SQL. We see on average
about 4000 queries per second. The MySQL server has been optimized
to hell and back and is running on high-end hardware,
Cami wrote:
> SQL simply doesnt scale very well for bayes. We have a serverfarm of
> 12 spamassassin servers and storing bayes in SQL. We see on average
> about 4000 queries per second. The MySQL server has been optimized
> to hell and back and is running on high-end hardware,but just simply
>
Mike Jackson wrote:
On my personal server, I'm running SA 3.0.4 with the user prefs, Bayes,
and AWL in a MySQL database (mostly because it would be "cooler" that
way). On my employer's server, I'm running the same SA version, but with
file-based DBs and user prefs. We're going to be rolling out
cally configured machines.
Thank you,
Tom
-Original Message-
From: Martin Hepworth [mailto:[EMAIL PROTECTED]
Sent: Friday, January 21, 2005 3:17 AM
To: J Thomas Hancock
Cc: users@spamassassin.apache.org
Subject: Re: Performance Problems
Tom
Known issue with spamdspawning too many children
Possibly you have a large auto-whitelist?
Loren
Tom
Known issue with spamdspawning too many children on SA 3.0.x.
You can
1)reduce the number of children with the -m parameter. Alot of people
have this to soemthing like 10 by default. If you reduce it to 5 or even
2 it should sort the problem
2) patch the source
http://bugzilla.spamassass
On Mon, 2004-11-08 at 10:58, Scot L. Harris wrote:
> > From: Henri van Riel [mailto:[EMAIL PROTECTED]
> > >
> > > spamd[3164]: identified spam (22.0/5.0) for p3scan:150 in
> > > 135.4 seconds, 3920 bytes.
> > >
> > > That's 2 minutes and 15+ seconds for an email little over 3k in
> > > size...
>
> From: Henri van Riel [mailto:[EMAIL PROTECTED]
> >
> > spamd[3164]: identified spam (22.0/5.0) for p3scan:150 in
> > 135.4 seconds, 3920 bytes.
> >
> > That's 2 minutes and 15+ seconds for an email little over 3k in
> > size...
> >
> > I run a small personal mailserver but 90% of my incoming
From: Henri van Riel [mailto:[EMAIL PROTECTED]
>
> spamd[3164]: identified spam (22.0/5.0) for p3scan:150 in
> 135.4 seconds, 3920 bytes.
>
> That's 2 minutes and 15+ seconds for an email little over 3k in
> size...
>
> I run a small personal mailserver but 90% of my incoming mail is spam
> and
On Mon, 8 Nov 2004, Ronan wrote:
> [sort of OT]
> mike what type of log file are you running spamstats on??
> whenever i run it it never outputs the number of spams fields ie the
> first two in the columns.
>
> also it doesnt output anything when i run it on exim_mainlog but it
> outputs all bu
Mike Burger wrote:
On Sun, 7 Nov 2004, Henri van Riel wrote:
Hello,
Ok, I admit, mine is not the fastest mail server on the planet but is
this the best performance I'm going to get:
spamd[3164]: identified spam (22.0/5.0) for p3scan:150 in 135.4 seconds, 3920
bytes.
That's 2 minutes and 15+ seco
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] says...
> Ok, I admit, mine is not the fastest mail server on the planet but is
> this the best performance I'm going to get:
>
> spamd[3164]: identified spam (22.0/5.0) for p3scan:150 in 135.4
> seconds, 3920 bytes.
>
> That's 2 minutes and 15+
From: "Loren Wilton" <[EMAIL PROTECTED]>
> > Mine (I thought it was a "toy" server, Celeron at that) is probably
doing
> so
> > well because I'm on a fairly idle T1 so all the DNS traffic is pretty
> fast.
> > But my "toy" is a lot more than 166 Mhz. A 2Ghz Cheapo
> CPU/Motherboard/0.5G
> > ram is
> Mine (I thought it was a "toy" server, Celeron at that) is probably doing
so
> well because I'm on a fairly idle T1 so all the DNS traffic is pretty
fast.
> But my "toy" is a lot more than 166 Mhz. A 2Ghz Cheapo
CPU/Motherboard/0.5G
> ram is probably $300 or less. Check TigerDirect or somewhere a
s. Check TigerDirect or somewhere and UPGRADE
THAT PUPPY!
Dan
-Original Message-
From: Mike Burger [mailto:[EMAIL PROTECTED]
Sent: Sunday, November 07, 2004 1:59 PM
To: Henri van Riel
Cc: users@spamassassin.apache.org
Subject: Re: Performance.
On Sun, 7 Nov 2004, Henri van Riel wrote:
>
On Sun, 7 Nov 2004, Henri van Riel wrote:
> Hello,
>
> Ok, I admit, mine is not the fastest mail server on the planet but is
> this the best performance I'm going to get:
>
> spamd[3164]: identified spam (22.0/5.0) for p3scan:150 in 135.4 seconds, 3920
> bytes.
>
> That's 2 minutes and 15+ sec
79 matches
Mail list logo
