You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Igor Chudov <ig...@chudov.com> on 2012/11/10 05:32:22 UTC

URIBL_BLACK unreilable?

I receive a lot of spams similar to this one:

http://igor.chudov.com/tmp/spam014.txt

It is a spam, however it has a low score and hit my mailbox. 

When I reran spamassassin -D on this message, it was flagged as spam
and I get the following:

http://igor.chudov.com/tmp/spam014.trace.txt

The difference is that it tripped BAYES50, RAZOR2_CHECK, URIBL_BLACK
and URIBL_DBL_SPAM.

I re-ran spamassassin a few times, and it does successfully flag this
as spam. 

So, why is it triggering URIBL_BLACK and URIBL_DBL_SPAM etc now, but
not when I received the original spam?

Are those rules unreliable? Or was the database updated with those
URLs after I received that particular spam?

i

Re: URIBL_BLACK unreilable?

Posted by John Hardin <jh...@impsec.org>.
On Sat, 10 Nov 2012, Igor Chudov wrote:

> On Sat, Nov 10, 2012 at 08:47:57AM +0300, Jonathan Nichols wrote:
>>>
>>> So, why is it triggering URIBL_BLACK and URIBL_DBL_SPAM etc now, but
>>> not when I received the original spam?
>>>
>>>  Or was the database updated with those
>>> URLs after I received that particular spam?
>>
>> It is quite likely that it was not in the database when you received it, but was added afterwards. I have seen that with a few URLs myself.
>
> If so, I am wondering, is there some sort of a "solution" that could
> delay certain incoming emails for, say, 30 minutes, until they are
> checked for spam. I would prefer it to be flaxible enough not to apply
> to certain "good" emails.

Ayup. Google "greylisting". A lot of us use it for this reason, plus a lot 
of spammers don't retry delivery.

-- 
  John Hardin KA7OHZ                    http://www.impsec.org/~jhardin/
  jhardin@impsec.org    FALaholic #11174     pgpk -a jhardin@impsec.org
  key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
   Any time law enforcement becomes a revenue center, the system
   becomes corrupt.
-----------------------------------------------------------------------
  Tomorrow: Veterans Day

Re: URIBL_BLACK unreilable?

Posted by Igor Chudov <ig...@chudov.com>.
On Sat, Nov 10, 2012 at 08:47:57AM +0300, Jonathan Nichols wrote:
> > 
> > So, why is it triggering URIBL_BLACK and URIBL_DBL_SPAM etc now, but
> > not when I received the original spam?
> > 
> >  Or was the database updated with those
> > URLs after I received that particular spam?
> > i
> 
> It is quite likely that it was not in the database when you received it, but was added afterwards. I have seen that with a few URLs myself. 

If so, I am wondering, is there some sort of a "solution" that could
delay certain incoming emails for, say, 30 minutes, until they are
checked for spam. I would prefer it to be flaxible enough not to apply
to certain "good" emails. 

i

Re: URIBL_BLACK unreilable?

Posted by Jonathan Nichols <jn...@pbp.net>.
> 
> So, why is it triggering URIBL_BLACK and URIBL_DBL_SPAM etc now, but
> not when I received the original spam?
> 
>  Or was the database updated with those
> URLs after I received that particular spam?
> i

It is quite likely that it was not in the database when you received it, but was added afterwards. I have seen that with a few URLs myself.