https://bz.apache.org/SpamAssassin/show_bug.cgi?id=3549
Henrik Krohns changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-21 17:03 ---
(In reply to comment #38)
> We're certainly interested in this topic, but if a domain is used at 3, 4 and
> 5
> levels, would that mean we'd need to list wi
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-21 07:52 ---
We're certainly interested in this topic, but if a domain is used at 3, 4 and 5
levels, would that mean we'd need to list wildcards at all three levels?
Curr
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-21 02:19 ---
'Two, send out a query
for each level of hierarchy from the second down to the fifth or so.'
yeah, I suggested this on the surbl discuss list as well. it'll
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-21 00:33 ---
I believe making registrar boundaries be user configurable is a serious mistake.
The user does not know what the registrar boundaries are. Neither does the
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-18 00:13 ---
Yeah, I'm in agreement with you Jeff. My main point was really meant to be
about making registrar boundaries user-configurable so that it'd be feasible for
y
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-17 15:22 ---
(In reply to comment #33)
> Yeah, no kidding. It's just as impractical as listing each
> "massivegibberish.tripod.com." host.
>
> I don't suggest attempting
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-17 06:17 ---
Yeah, no kidding. It's just as impractical as listing each
"massivegibberish.tripod.com." host.
I don't suggest attempting either, just pointing out that us
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-17 05:31 ---
(In reply to comment #30)
> Incorrect. To whitelist thathost.tripod.com you would use a CNAME record for
> thathost.tripod.com. (pointing at say 127.0.0.0) i
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-17 04:33 ---
'(pointing at say 127.0.0.0)'
Just to clarify that... it'd, of course, point to something that resolved to
127.0.0.0 or might point to something that doesn't
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-17 04:26 ---
> At first glance a wildcard may seem to solve that, e.g., *.spammer.biz means
> all their subdomains/hostnames are blacklisted (all your subdomains are belon
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-17 04:11 ---
(In reply to comment #26)
> (In reply to comment #25)
> > another good reason not to do this, is to reduce the risk of transmitting
> > identifying info to th
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
-
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-16 21:38 ---
in reply to comment #26, justin's idea is not off base at all.
depending on the backend systems at at DNS blacklist providers, and the methods
they use to
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-16 21:18 ---
hmm, yes, good point. my mistake.
(FWIW, it's still possible, but much, much harder, and not really realistic that
a spammer would go to the bother of doing
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-16 20:43 ---
(In reply to comment #25)
> another good reason not to do this, is to reduce the risk of transmitting
> identifying info to the spammer. e.g.
> "http://6a6d4
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-11-16 20:34 ---
returning to this bug and noticing something that wasn't mentioned. re:
'I don't think I've ever understood why SURBL and URIBL don't use wildcard
entries i
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-05-27 09:38 ---
> I don't think I've ever understood why SURBL and URIBL don't use wildcard
> entries in their zones. Doing so would eliminate the need for SpamAssassin to
> dete
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-05-27 01:38 ---
Subject: Re: Inconsistent coverage of private registries in
RegistrarBoundaries.pm
> Can you clarify:
>
> If spammer.domain.com is a bad guy and hammer.domain.c
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-05-27 01:00 ---
We didn't find that the random subdomains or (keyed) "tracking" hostnames were
too useful in deciding whether or not a domain should be listed or tagged.
Therefo
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-05-26 23:23 ---
Subject: Re: Inconsistent coverage of private registries in
RegistrarBoundaries.pm
> Can you clarify:
>
> If spammer.domain.com is a bad guy and hammer.domai
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-05-26 23:05 ---
(In reply to comment #19)
> > If subdomain.domain.com is appearing in spams and domain.com
> > is legitimate than they should fix the problems with their
> > abusi
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-05-26 22:49 ---
Subject: Re: Inconsistent coverage of private registries in
RegistrarBoundaries.pm
> Basically it was a design decision to just list domains as
> registered by
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Yo
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2005-05-26 22:28 ---
(In reply to comment #17)
> I posted this to discuss-uribl the other day, with no response. I must be
> missing something as to why this isn't the best (and certa
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Addi
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Yo
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
[EMAIL PROTECTED] changed:
What|Removed |Added
CC||[EMAIL PROTECTED]
--- Addi
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
[EMAIL PROTECTED] changed:
What|Removed |Added
Target Milestone|Undefined |Future
--- Additional Comm
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2004-10-14 18:33 ---
FWIW, I believe that all the private registries that I've mentioned in this bug
run a proper port 63 whois service.
I think that's a fairly good criterion. Certa
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2004-10-14 17:57 ---
We can add things like "HK.ST - CN.ST - TW.ST - SG.ST" private registry reserved
SLDs to the SURBL list of two-level-domains in order to treat them like ccTLD
rese
http://bugzilla.spamassassin.org/show_bug.cgi?id=3549
--- Additional Comments From [EMAIL PROTECTED] 2004-10-14 17:42 ---
ok, here's an example of a spammer abusing "private" (non-official) registries,
forwarded from the SURBL list...
'From: "Joe Wein"
Date: Fri, 15 Oct 2004 09:19:4
32 matches
Mail list logo
