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.