Karsten Bräckelmann wrote:
> Works for me.
> Also verified the 3.3.2 (and 3.3.0 for that matter) svn tag version, in
> addition to my local 3.3 branch above. Same result, works for me.
I stand corrected (and confirmed locally).
-kgd
On Tue, 2014-08-26 at 11:22 -0400, Kris Deugau wrote:
> Is there a way to prevent a URI from being looked up in DNSBLs, without
> *also* preventing that URI from matching on uri regex rules?
>
> I would like to add quite a few popular URL shorteners to
> uridnsbl_skip_domain, but then I can't matc
Is there a way to prevent a URI from being looked up in DNSBLs, without
*also* preventing that URI from matching on uri regex rules?
I would like to add quite a few popular URL shorteners to
uridnsbl_skip_domain, but then I can't match those domains in uri regex
rules for feeding "x and URL shorte
Ah yes, its a stupid fault
Thanks a lot
Le 14/03/14, Wolfgang Zeikat a écrit :
> In an older episode, on 2014-03-14 23:10, Leveau Stanislas wrote:
>
> >I have tested this rule but it does not work, it's starnge
> >
> >
> >
> >uri __SPAMS_URI_7 /\.webs\.com\//
> >describe __SPAMS_URI_7 url vers
On 03/14/2014 11:17 PM, Wolfgang Zeikat wrote:
In an older episode, on 2014-03-14 23:10, Leveau Stanislas wrote:
I have tested this rule but it does not work, it's starnge
uri __SPAMS_URI_7 /\.webs\.com\//
describe __SPAMS_URI_7 url vers formulaire
score __SPAMS_URI_7 15.0
rules with names
In an older episode, on 2014-03-14 23:10, Leveau Stanislas wrote:
I have tested this rule but it does not work, it's starnge
uri __SPAMS_URI_7 /\.webs\.com\//
describe __SPAMS_URI_7 url vers formulaire
score __SPAMS_URI_7 15.0
rules with names starting with __ do _not_ get scored
Try
meta
Hi,
I have tested this rule but it does not work, it's starnge
uri __SPAMS_URI_7 /\.webs\.com\//
describe __SPAMS_URI_7 url vers formulaire
score __SPAMS_URI_7 15.0
Le 14/03/14, Axb a écrit :
> On 03/14/2014 01:54 PM, Stanislas LEVEAU wrote:
> >Thanks for your answer, yes it's really si
On 03/14/2014 01:54 PM, Stanislas LEVEAU wrote:
Thanks for your answer, yes it's really simple but I use spamassassin
3.3 :(
uri RULENAME/\.webs\.com\//
should do the trick
Thanks for your answer, yes it's really simple but I use spamassassin 3.3 :(
Le 14/03/2014 12:52, Axb a écrit :
if you're using SA 3.4 it's really simple
blacklist_uri_host webs.com
On 03/14/2014 12:44 PM, Stanislas LEVEAU wrote:
I wrote 2 spamassassin rules but that does not work obviously.
if you're using SA 3.4 it's really simple
blacklist_uri_host webs.com
On 03/14/2014 12:44 PM, Stanislas LEVEAU wrote:
I wrote 2 spamassassin rules but that does not work obviously. Where is
the mistake?
Thanks in advance
uri_detail __SPAMS_URI_6 raw =~ /%2Ewebs/ domain =~ /^webs\.com$/
Hi
I have lots of email like this one :
An example :
Vous avez un message, cliquez sur le lien pour lire
http://my-domain234567.webs.com/
You have a message click on the linkhttp://my-domain234567.webs.com/ to read
and I would like to block this url --> webs.com
I wrote 2 spamassassin ru
Randy Ramsdell wrote:
How so? How does spamassassin URI check determine Kuxun.cn in a URI
as opposed to someone who forgot to add a "space" after a sentence end?
Well, CN is a rather strange word to start a sentence with, but it
doesn't know the difference between an intentional domain and a
Randy Ramsdell wrote:
Matt Kettler wrote:
Joseph Brennan wrote:
I was surprised that this rule...
uri CU_CN_LINK /http:..\w+\.cn\b/
matches not only this...
http://foobar.cn";>
but also this...
http://www.columbia.edu/foo.html";>KooXoo Buys Kuxun.cn
Domain
First, I did not rea
Joseph Brennan wrote:
Thanks, Mouss and Matt.
So a uri regexp will match a "http://"; that is not there. OK, well...
SA tries to check based on what MUAs do. if you write
"please visit www.example.com"
then so-called "modern" MUAs will highlight www.example.com and if you
bring your mou
Matt Kettler wrote:
Joseph Brennan wrote:
I was surprised that this rule...
uri CU_CN_LINK /http:..\w+\.cn\b/
matches not only this...
http://foobar.cn";>
but also this...
http://www.columbia.edu/foo.html";>KooXoo Buys Kuxun.cn
Domain
First, I did not realize that SpamAssassin'
Thanks, Mouss and Matt.
So a uri regexp will match a "http://"; that is not there. OK, well...
Joe Brennan
Joseph Brennan wrote:
I was surprised that this rule...
uri CU_CN_LINK /http:..\w+\.cn\b/
matches not only this...
http://foobar.cn";>
but also this...
http://www.columbia.edu/foo.html";>KooXoo Buys Kuxun.cn
Domain
First, I did not realize that SpamAssassin's idea of "uri" inclu
Joseph Brennan wrote:
I was surprised that this rule...
uri CU_CN_LINK /http:..\w+\.cn\b/
matches not only this...
http://foobar.cn";>
but also this...
http://www.columbia.edu/foo.html";>KooXoo Buys Kuxun.cn
Domain
First, I did not realize that SpamAssassin's idea of "uri" inclu
I was surprised that this rule...
uri CU_CN_LINK /http:..\w+\.cn\b/
matches not only this...
http://foobar.cn";>
but also this...
http://www.columbia.edu/foo.html";>KooXoo Buys Kuxun.cn Domain
First, I did not realize that SpamAssassin's idea of "uri" includes not
only the uri, but
On Fri, Aug 12, 2005 at 10:51:23PM -0700, Jeff Chan wrote:
> IIRC 3.1 may do that, right?
According to the debug output and the svn log on the plugin, 3.1 will,
yes. Came in from r160273 via bug 4013.
--
Randomly Generated Tagline:
I like work; it fascinates me; I can sit and look at it funny..
On Friday, August 12, 2005, 1:54:05 AM, dirk dirk wrote:
> Just that nobody forgets:
> What about false positives? 158.194.144.219 apparently belogs to Palacky
> University in Olomouc,Czechia. This IP is now wrongfully listed in SURBL!
> I'll post that problem to the SURBL-List as well, I think. J
On Thursday, August 11, 2005, 9:36:47 AM, Theo Dinter wrote:
> On Thu, Aug 11, 2005 at 03:31:57AM -0700, Jeff Chan wrote:
>> > the IP
>> > 219 dot 144 dot 194 dot 158
>> > is shown as listed by http://www.rulesemporium.com/cgi-bin/uribl.cgi - a
>> > phishing mail with
>> > http://219dot144dot194do
>
> To make things more complicated, the URIBL ( NOT! SURBL) lookup says.
> (parts cut off)
> > 219.144.194.158 NOT Listed on URIBL: NOT Listed on SURBL
> > 158.194.144.219Listed on URIBL black Listed on SURBL details
> Lookup: 158.194.144.219.multi.surbl.org Result: Blocked,
> 158.19
Please read the whole thread before flaming someone.
This one started with 'wolfgang' asking why he's unable to lookup
219.144.194.158 in multib.surbl.org.
219.144.194.158 is listed in ph und ws, according to the lookup tool on
rulesemporium.com.
dig 219.144.194.158.multi.surbl.org => no result
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 12, 2005 4:54 AM
> To: users@spamassassin.apache.org
> Subject: Re: Phishing IP listed in URIBL and SURBL, but not triggering
> URI rules
>
>
> Just that nobody
Hi!
What about false positives? 158.194.144.219 apparently belogs to Palacky
University in Olomouc,Czechia. This IP is now wrongfully listed in SURBL!
I'll post that problem to the SURBL-List as well, I think. Jeff C.
certainly doesn't want to harm innocent bystanders...
So they might have a
rg
>> > Subject: Re: Phishing IP listed in URIBL and SURBL, but not
>> > triggering URI rules
>> >
>> > In an older episode (Friday, 12. August 2005 01:18), Dallas
>> > L. Engelken wrote:
>> >
>> > > Looks like we agree with surb
listed in URIBL and SURBL, but not
> > triggering URI rules
> >
> > In an older episode (Friday, 12. August 2005 01:18), Dallas
> > L. Engelken wrote:
> >
> > > Looks like we agree with surbl..
> > >
> > > # host -tTXT 158.194.144
> >
> > Is other software (besides the surbl cgi :) using them?
> >
>
> Surbl.org lists several tools on their main page that use SURBL data,
> some which do not rely on spamassassin uri parser. I know uricat
> (http://ry.ca/geturi/) gets it right, as does SA 3.1.x of
> which has been
> getting
> -Original Message-
> From: wolfgang [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 11, 2005 6:36 PM
> To: users@spamassassin.apache.org
> Subject: Re: Phishing IP listed in URIBL and SURBL, but not
> triggering URI rules
>
> In an older episode (Frida
In an older episode (Friday, 12. August 2005 01:18), Dallas L. Engelken wrote:
> Looks like we agree with surbl..
>
> # host -tTXT 158.194.144.219.multi.uribl.com
> 158.194.144.219.multi.uribl.com descriptive text "Listed on [black] -
> See http://lookup.uribl.com/?domain=158.194.144.219";
Yes,
> -Original Message-
> From: Dirk Bonengel [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 11, 2005 5:01 PM
> To: Dallas L. Engelken
> Cc: users@spamassassin.apache.org
> Subject: Re: Phishing IP listed in URIBL and SURBL, but not
> triggering URI rules
>
&g
Dallas (and all the rest),
what you're saying is:
- We're talking of forward lookups, not of reverse lookup.
What I'm seeing, however, is that the zone files contain IPs in reverse
notation.So SA does a forward lookup on a reversed IP.
I think that's about it. Wolfgang complained about not bein
Greg Allen wrote:
This is a very, very dangerous road to go down. You would see a lot of
collateral damage by doing a URIBL by IP. A lot of domain hosts these days
use shared IPs. I could host any number of legit websites on one virtual
IP…and I do. I share IPs with any number of other websites a
Greg,
given you speak of name-based virtual hosts, your concerns do not apply.
You'd not be affected if the IP of one of your web servers would be
listed in an URIB list..The plugin does not resolve the IP of an URL.
The only thing that matters is the actual domain. The case in question
here is
m: Greg Allen [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, August 11, 2005 4:59 PM
> > To: 'users@spamassassin.apache.org'
> > Subject: RE: Phishing IP listed in URIBL and SURBL, but not
> triggering
> > URI rules
> >
> >
> > This is a very, v
Nee,
but the subrl/uribl backoffice does, and, yes, thinking of it they're
overdoing it:
The phish IP you mentioned was 219.144.194.158
In the zone files it's in reverse notation
extract of multi.surbl.org.rbldnsd (Zonefile for the rbldnsd I host:)
158.194.144.219 :127.0.0.12:Blocked, 158.194.
In an older episode (Thursday, 11. August 2005 22:58), Greg Allen wrote:
> This is a very, very dangerous road to go down. You would see a lot of
> collateral damage by doing a URIBL by IP. A lot of domain hosts these days
> use shared IPs. I could host any number of legit websites on one virtual
>
ng what is listed in the URL.
--Chris
> -Original Message-
> From: Greg Allen [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 11, 2005 4:59 PM
> To: 'users@spamassassin.apache.org'
> Subject: RE: Phishing IP listed in URIBL and SURBL, but not triggering
>
In an older episode (Thursday, 11. August 2005 22:46), Dirk Bonengel wrote:
> Well, the IP is listed OK, but one needs to do reverse queries:
>
> dig 158.194.144.219.multi.surbl.org
> gives
> 158.194.144.219.multi.surbl.org. 1850 IN A 127.0.0.12
> which sounds good to me.
But the uribl plugi
This is a very, very dangerous road to go down. You would see a lot of
collateral damage by doing a URIBL by IP. A lot of domain hosts these days
use shared IPs. I could host any number of legit websites on one virtual
IP
and I do. I share IPs with any number of other websites at the web
hosting co
: Thursday, August 11, 2005 2:56 PM
To: users@spamassassin.apache.org
Subject: Re: Phishing IP listed in URIBL and SURBL, but not triggering
URI rules
In an older episode (Thursday, 11. August 2005 12:31), Jeff
Chan wrote:
On Tuesday, August 9, 2005, 11:52:47 PM, wolfgang wolfgang wrote
> -Original Message-
> From: wolfgang [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 11, 2005 2:56 PM
> To: users@spamassassin.apache.org
> Subject: Re: Phishing IP listed in URIBL and SURBL, but not triggering
> URI rules
>
>
> In an older episode (Thur
In an older episode (Thursday, 11. August 2005 12:31), Jeff Chan wrote:
> On Tuesday, August 9, 2005, 11:52:47 PM, wolfgang wolfgang wrote:
> > the IP
> > 219 dot 144 dot 194 dot 158
> > is shown as listed by http://www.rulesemporium.com/cgi-bin/uribl.cgi - a
> > phishing mail with
> >
http://219
On Thu, Aug 11, 2005 at 03:31:57AM -0700, Jeff Chan wrote:
> > the IP
> > 219 dot 144 dot 194 dot 158
> > is shown as listed by http://www.rulesemporium.com/cgi-bin/uribl.cgi - a
> > phishing mail with
> > http://219dot144dot194dot158:8081/secure.dresdner-privat.de/fb/privat/login/login.htm
> > in
On Tuesday, August 9, 2005, 11:52:47 PM, wolfgang wolfgang wrote:
> the IP
> 219 dot 144 dot 194 dot 158
> is shown as listed by http://www.rulesemporium.com/cgi-bin/uribl.cgi - a
> phishing mail with
> http://219dot144dot194dot158:8081/secure.dresdner-privat.de/fb/privat/login/login.htm
> in it's
Hi,
the IP
219 dot 144 dot 194 dot 158
is shown as listed by http://www.rulesemporium.com/cgi-bin/uribl.cgi - a
phishing mail with
http://219dot144dot194dot158:8081/secure.dresdner-privat.de/fb/privat/login/login.htm
in it's body does not trigger any uribl rules tho. Why is that so?
cheers,
wol
Menschel wrote:
>> SARE has been playing around with URI rules lately, and when we need
>> to test for something in the host/domain area, we use something like:
>>
>>>uri rule_name m'(?:https?://)?[^/]*testgoeshere'
KI> I think you want a ^ at the start o
Robert Menschel wrote:
SARE has been playing around with URI rules lately, and when we need
to test for something in the host/domain area, we use something like:
uri rule_name m'(?:https?://)?[^/]*testgoeshere'
I think you want a ^ at the start of your regex. As it is, that w
M>Hello martin,
M>
M>
M>SARE has been playing around with URI rules lately, and when
M>we need to test for something in the host/domain area, we use
M>something like:
M>> uri rule_name m'(?:https?://)?[^/]*testgoeshere'
M>In other words, the test must
ad changed, since its
ms> not a url rule that is.
SARE has been playing around with URI rules lately, and when we need
to test for something in the host/domain area, we use something like:
> uri rule_name m'(?:https?://)?[^/]*testgoeshere'
In other words, the test must precede any
M>Not that I'm aware of. To my knowledge the URI rule always
M>matches the full URL. There are several SA and/or SARe rules
M>which depend upon this.
M>
M>Or do you mean something different by URI and URL than I do.
M>I generally use the definitions found at
M>http://www.adp-gmbh.ch/web/uri_
Hello martin,
Sunday, June 12, 2005, 4:58:35 AM, you wrote:
ms> Has the behaviour of the uri rule been changed at some point to match the
ms> whole of the URL? I have just noticed I am getting some FP when one of my
ms> uri rules matches against the URL rather than URI.
Not that I
> Has the behaviour of the uri rule been changed at some point
> to match the
> whole of the URL? I have just noticed I am getting some FP
> when one of my
> uri rules matches against the URL rather than URI.
> To prevent FP would be very difficult, I think to match the
> wh
Has the behaviour of the uri rule been changed at some point to match the
whole of the URL? I have just noticed I am getting some FP when one of my
uri rules matches against the URL rather than URI.
To prevent FP would be very difficult, I think to match the whole of the URL
with uri rules is not
55 matches
Mail list logo