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 yo
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 out
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
-- Original Message --
From: Warren Togami
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 therefore before
con
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 o
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 automated
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 Goog
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 x
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 resp
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 ac
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
> > 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 cover
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 a
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 slow
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 purp
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 vol
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 o
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 re
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 s
170-n/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
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:
Processin
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:
If every list is an "outright block" list, then you are correct. My
point applies to situations
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
> 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]: spa
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:
spam
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:
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
SIGCH
27 matches
Mail list logo
