Martin Gregorie wrote:
On Tue, 2009-10-06 at 23:16 +0200, Per Jessen wrote:
Martin, generally speaking, the parent can only report the signal and
that the child has gone away. The child would have to report on why.
OK, rephrase that to a pity the child doesn't say why its generating a
On 07/10/2009 05:19, Rob McEwen wrote:
Also, this loses the ability to *score* on multiple lists... unless you
use a bitmasked scoring system whereby one list gets assigned .2,
another .4, another .8, on to .128. But that leaves a maximum of
only 7 lists. Sure, you can add more than 7 by
Martin Gregorie wrote:
Yeah - maybe there is some indication in the log? I think there is a
switch that determines how many emails a child will process before
needing restart. (just looked it up: --max-conn-per-child)
I just checked my logs, during the last 9 hours I have 6016 of these:
Yeah - maybe there is some indication in the log? I think there is a
switch that determines how many emails a child will process before
needing restart. (just looked it up: --max-conn-per-child)
I just checked my logs, during the last 9 hours I have 6016 of these:
spamd[11362]: spamd:
Per Jessen wrote:
Martin Gregorie wrote:
Yeah - maybe there is some indication in the log? I think there is
a switch that determines how many emails a child will process before
needing restart. (just looked it up: --max-conn-per-child)
I just checked my logs, during the last 9 hours I have
Mike Cardwell wrote:
I don't understand the logic of that. Ie, why you'd need to use
bitmasking? zen.spamhaus.org is a combination of various different
lists and returns multiple values like this:SNIP
If every list is an outright block list, then you are correct. My
point applies to situations
On Wed, 2009-10-07 at 14:31 +0200, Per Jessen wrote:
Okay, I ran a check on my logs since midnight - yes, I also see a lot of
child processes running for less than 10secs, in fact slightly more
than 50%. Interesting issue.
Here's the results of a scan across all my mail logs:
Processing
/T_CN_EIGHT/detail
Last month, I noticed that a very sizeable percentage of the .cn spam
were fresh and random \w{8}.cn domain names.
http://ruleqa.spamassassin.org/20091007-r822624-n/T_CN_SEVEN/detail
I don't know if it was due to our discussion here, but for whatever
reason I began seeing new
On 10/7/2009 5:00 PM, Warren Togami wrote:
It seems then the only way to feed a URIBL fresh .cn domains would be a
spam trap. This proposed URIBL would be extremely easy to build on the
infrastructure of existing trap-based DNSBL's like PSBL, HOSTKARMA or
SEM. My own volume of spam is too
Hi Warren!
It seems then the only way to feed a URIBL fresh .cn domains would be a
spam trap. This proposed URIBL would be extremely easy to build on the
infrastructure of existing trap-based DNSBL's like PSBL, HOSTKARMA or SEM.
My own volume of spam is too small to do this.
you haven't
On 10/07/2009 11:27 AM, Raymond Dijkxhoorn wrote:
We are working on getting .CN zone access. Thats the only way to speed
things up. The only challenging part is to get a copy of the CN zone
just like we get copy's of other ccTLD/gTLD's.
OK, I was under the impression that it was impossible to
Warren Togami wrote:
Opinions of this proposal?
I would love to have a listing of recently registered .cn domains but
until the TLD operator starts working with us that just isn't going to
happen.
Trying to perform a whois lookup on every domain is painfully slow.
Once you get a high enough
Blaine Fleming wrote:
I know my users never see .cn domains in their inbox
and if I didn't run a blacklist I wouldn't either.
Which brings up an interesting idea. I wonder how many legit non-spam
.cn domains exist? Surely it is a fraction of a percent of the # of .cn
domains used for spam
Blaine Fleming wrote:
Warren Togami wrote:
Opinions of this proposal?
I would love to have a listing of recently registered .cn domains but
until the TLD operator starts working with us that just isn't going to
happen.
Trying to perform a whois lookup on every domain is painfully
On Wed, 7 Oct 2009, Terry Carmen wrote:
Instead of blacklisting new domains (which is apparently difficult to
do), why not blacklist all .cn domains (or simply all domains) newer
than xxx days?
If they're older than xxx days and not yet on another blacklist for
sending actual spam, return
Spam from .cn domains can be mitigated with the right rules and querying
multiple lists. I know my users never see .cn domains in their inbox
and if I didn't run a blacklist I wouldn't either.
Indeed, spam with .cn URIs really doesn't appear to be a problem at all.
They are well covered by
On Wed, 2009-10-07 at 14:01 -0400, Rob McEwen wrote:
I might be interested in maintaining such a freely available
list--accessible via rsync at no charge--if someone else would come up
with the SA rule or plugin.
I'd be interested in giving this a shot, as a proof-of-concept. Any
details and
John Hardin wrote:
On Wed, 7 Oct 2009, Terry Carmen wrote:
Instead of blacklisting new domains (which is apparently difficult to
do), why not blacklist all .cn domains (or simply all domains) newer
than xxx days?
If they're older than xxx days and not yet on another blacklist for
sending
Terry Carmen wrote:
Instead of blacklisting new domains (which is apparently difficult to
do), why not blacklist all .cn domains (or simply all domains) newer
than xxx days?
If they're older than xxx days and not yet on another blacklist for
sending actual spam, return a neutral response.
On Wed, 7 Oct 2009, Terry Carmen wrote:
John Hardin wrote:
On Wed, 7 Oct 2009, Terry Carmen wrote:
Instead of blacklisting new domains (which is apparently difficult to
do), why not blacklist all .cn domains (or simply all domains) newer
than xxx days?
If they're older than xxx
John Hardin wrote:
The other part of the problem is determining the age of a domain. The
only way to do that absent a registrar feed is to do a whois query,
which may or may not return the data you need, and which is considered
abusive when automated and done often.
It would be nice if
On 10/07/2009 03:29 PM, Jason Bertoch wrote:
John Hardin wrote:
The other part of the problem is determining the age of a domain. The
only way to do that absent a registrar feed is to do a whois query,
which may or may not return the data you need, and which is considered
abusive when
On 10/7/2009 8:01 PM, Rob McEwen wrote:
Blaine Fleming wrote:
I know my users never see .cn domains in their inbox
and if I didn't run a blacklist I wouldn't either.
Which brings up an interesting idea. I wonder how many legit non-spam
..cn domains exist? Surely it is a fraction of a percent
-- Original Message --
From: Warren Togami wtog...@redhat.com
Date: Sun, 04 Oct 2009 19:42:06 -0400
http://spameatingmonkey.com
Anyone have any experience using these DNSBL and URIBL's?
I plugged these into my main.cf just just before permit, and
On Tue, 2009-10-06 at 13:50 -0700, an anonymous Nabble user wrote:
Other than the sought rules, all the rules are manually generated?
Actually, as has been said, I believe all stock rules are manually
written. There are some third-party rule-sets out there that are auto
generated -- not limited
Hi!
The other part of the problem is determining the age of a domain. The
only way to do that absent a registrar feed is to do a whois query,
which may or may not return the data you need, and which is considered
abusive when automated and done often.
It would be nice if Google could help
Hi!
How does that simplify the problem? The difficulty is in getting data about
when a domain was created.
I thought the problem was in getting data for recently created domains, not
all domains.
If it's a problem with all domains, this won't help at all.
If you rely on whois data, and
27 matches
Mail list logo
