You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ian Zimmerman <it...@primate.net> on 2017/02/15 04:04:19 UTC
Fastest listing RBL ?
Given a piece of horrible spam, on which RBL is the sending IP address
likely to appear first?
I want to rationally decide which RBL/s to consult at SMTP time. Afraid
to use all of them, not just due to false positives, but also due to
negative caching in DNS, which could affect the result when the spam is
seen by SA a bit later.
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
Re: Fastest listing RBL ?
Posted by Matus UHLAR - fantomas <uh...@fantomas.sk>.
>> On 2017-02-15 16:30, Tom Hendrikx wrote:
>>> Note that the period that you describe as 'seen by SA a bit later' is
>>> typically less than a second.
>On 16-02-17 06:22, Ian Zimmerman wrote:
>> Not in my case. I have a custom Exim configuration where I
>> intentionally wait for a period of time (currently 4 minutes) between
>> SMTP acceptance and delivery (SA runs at delivery time), precisely
>> because I want to give all the collaborative mechanisms the maximum
>> chance to kick in.
On 16.02.17 09:57, Tom Hendrikx wrote:
>Why are you keeping mail in your queue, when you could also use
>greylisting and achieve roughly the same delivery delay? Except that
>lots of spambots don't understand greylisting and will never return for
>the second delivery? And that you don't get a full queue when something
>weird happens?
this can be used in addition to spambots.
Because of blacklists and other tricks (like greylist), the very common for
spammer is to use others mailservers.
processing delay can give some little advantage so that things like DCC
(if you report at erceive time, but check at processing time) can hit
between.
--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
(R)etry, (A)bort, (C)ancer
Re: Fastest listing RBL ?
Posted by Tom Hendrikx <to...@whyscream.net>.
On 16-02-17 06:22, Ian Zimmerman wrote:
> On 2017-02-15 16:30, Tom Hendrikx wrote:
>
>> Note that the period that you describe as 'seen by SA a bit later' is
>> typically less than a second.
>
> Not in my case. I have a custom Exim configuration where I
> intentionally wait for a period of time (currently 4 minutes) between
> SMTP acceptance and delivery (SA runs at delivery time), precisely
> because I want to give all the collaborative mechanisms the maximum
> chance to kick in.
Why are you keeping mail in your queue, when you could also use
greylisting and achieve roughly the same delivery delay? Except that
lots of spambots don't understand greylisting and will never return for
the second delivery? And that you don't get a full queue when something
weird happens?
To be honest, I never heard of this kind of setup before. Is this a
typical Exim trick?:)
>
> When I wrote my OP, 4 minutes was shorter than my BIND max-ncache-ttl
> parameter. I have since set that to 180 (3 minutes), so that angle
> shouldn't matter any more. Still the balance between bouncing the most
> junk outright and the risk of false positives means it's something to
> think about.
>
>> Which RBLs to use, depends on the typical spam you receive, and the
>> policies that you wish to apply. IMHO, the trust you put in RBLs (and
>> their listing policies) should be more important in making decisions
>> than their typical response time to new (types of) spam and their
>> TTLs.
>
> Agreed.
>
Re: Fastest listing RBL ?
Posted by Ian Zimmerman <it...@primate.net>.
On 2017-02-15 16:30, Tom Hendrikx wrote:
> Note that the period that you describe as 'seen by SA a bit later' is
> typically less than a second.
Not in my case. I have a custom Exim configuration where I
intentionally wait for a period of time (currently 4 minutes) between
SMTP acceptance and delivery (SA runs at delivery time), precisely
because I want to give all the collaborative mechanisms the maximum
chance to kick in.
When I wrote my OP, 4 minutes was shorter than my BIND max-ncache-ttl
parameter. I have since set that to 180 (3 minutes), so that angle
shouldn't matter any more. Still the balance between bouncing the most
junk outright and the risk of false positives means it's something to
think about.
> Which RBLs to use, depends on the typical spam you receive, and the
> policies that you wish to apply. IMHO, the trust you put in RBLs (and
> their listing policies) should be more important in making decisions
> than their typical response time to new (types of) spam and their
> TTLs.
Agreed.
--
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign: http://cr.yp.to/smtp/8bitmime.html
Re: Fastest listing RBL ?
Posted by Tom Hendrikx <to...@whyscream.net>.
On 15-02-17 15:19, Bowie Bailey wrote:
> On 2/14/2017 11:04 PM, Ian Zimmerman wrote:
>> Given a piece of horrible spam, on which RBL is the sending IP address
>> likely to appear first?
>>
>> I want to rationally decide which RBL/s to consult at SMTP time. Afraid
>> to use all of them, not just due to false positives, but also due to
>> negative caching in DNS, which could affect the result when the spam is
>> seen by SA a bit later.
>
> I find zen.spamhaus.org to be the most reliable RBL to use for
> blacklisting.
>
> I wouldn't worry too much about negative caching. It looks like the TTL
> for negative results with Spamhaus is 10 seconds.
>
Naturally, blocklists decide based on their data (f.i. removal times for
typical listings, the way they publish updates, etc) the best ttl for
their data. You should probably just use them.
Note that the period that you describe as 'seen by SA a bit later' is
typically less than a second. In the rare case that postfix sees other
values than spamassassin for the same delivery, many people on this list
will (on first sight) assume your setup is broken when you see
differences in that timeframe, in stead of 'very smart with RBLs and TTLs'.
Which RBLs to use, depends on the typical spam you receive, and the
policies that you wish to apply. IMHO, the trust you put in RBLs (and
their listing policies) should be more important in making decisions
than their typical response time to new (types of) spam and their TTLs.
Kind regards,
Tom
Re: Fastest listing RBL ?
Posted by Bowie Bailey <Bo...@BUC.com>.
On 2/14/2017 11:04 PM, Ian Zimmerman wrote:
> Given a piece of horrible spam, on which RBL is the sending IP address
> likely to appear first?
>
> I want to rationally decide which RBL/s to consult at SMTP time. Afraid
> to use all of them, not just due to false positives, but also due to
> negative caching in DNS, which could affect the result when the spam is
> seen by SA a bit later.
I find zen.spamhaus.org to be the most reliable RBL to use for blacklisting.
I wouldn't worry too much about negative caching. It looks like the TTL
for negative results with Spamhaus is 10 seconds.
--
Bowie
Re: Fastest listing RBL ?
Posted by "Kevin A. McGrail" <KM...@PCCC.com>.
On 2/22/2017 1:52 PM, Bill Cole wrote:
> Pedantic niggle: RBL is not a generic term. It's a trademark
> originally owned by MAPS and now by Trend Micro. Generic term is DNSBL.
> (Yeah, I know, it's like band-aid and kleenex...)
Good luck on enforcing that one. Of course America Invents trumps art
priore, etc. I think that ship sailed a decade+ ago.
Re: Fastest listing RBL ?
Posted by Bill Cole <sa...@billmail.scconsult.com>.
Pedantic niggle: RBL is not a generic term. It's a trademark originally
owned by MAPS and now by Trend Micro. Generic term is DNSBL.
(Yeah, I know, it's like band-aid and kleenex...)
On 14 Feb 2017, at 23:04, Ian Zimmerman wrote:
> Given a piece of horrible spam, on which RBL is the sending IP address
> likely to appear first?
It depends on the genus of spam, and note that I am NOT recommending the
use of all of these DNSBLs as absolute ban criteria, just answering the
query as asked...
Botspam is all the CBL (a Spamhaus Zen component) does and IPs in the
major botnets usually hit there first. PSBL, SORBS Spam, and NiX Spam
(Manitu) are usually very close behind and sometimes catch IPs that
never show up on CBL/Zen
Snowshoe spam is complicated. The Spamhaus CSS (SBL and hence also Zen
component) is usually pretty swift, but often entirely misses spammers
that PSBL, SORBS Spam, SpamCop or NiX catch.
For other varieties (e.g. direct mainsleaze, sloppy ESPs, bulletproof
ISPs) speed of listing is less important because the sending IPs don't
churn much.
> I want to rationally decide which RBL/s to consult at SMTP time.
> Afraid
> to use all of them,
This is such a local decision that it may not help much to get external
advice. There are hundreds of classical sending-IP DNSBLs available and
using them all in any way would be pointless and dangerous. The spam you
get isn't goingt to look like the spam I get.
Re: Fastest listing RBL ?
Posted by David Jones <dj...@ena.com>.
>From: Ian Zimmerman <it...@primate.net>
>Sent: Tuesday, February 14, 2017 10:04 PM
>To: users@spamassassin.apache.org
>Subject: Fastest listing RBL ?
>Given a piece of horrible spam, on which RBL is the sending IP address
>likely to appear first?
>I want to rationally decide which RBL/s to consult at SMTP time. Afraid
>to use all of them, not just due to false positives, but also due to
>negative caching in DNS, which could affect the result when the spam is
>seen by SA a bit later.
What MTA are you using? Postfix is very flexible and Postscreen is
powerful. It can be setup with dozens of RBLs with weights so even
not-so-good RBLs can be used to safely. If you turn up the RBL
sensitivity with a lot of them in postscreen, it will require using
postwhite to prevent blocking legit mail from major hosting
providers. In this case SA will have to handle those messages
based on content.
Greylisting is the best help to add a delay to give time for RBLs to
list new IPs. Greylisting can be setup selectively so it doesn't
slow down email from trusted senders which is the most common
objection to using greylisting. I thought it would be impossible
to implement it without my users complaining but I was able to
do it with a little care over a few weeks.
Dave
Re: Fastest listing RBL ?
Posted by Vincent Fox <vb...@ucdavis.edu>.
I cannot state strongly enough, that blocking
entire top-level domains these days should come
before RBL. *.top, *.link, *.download, etc.
RBL depends on paid or free.
Paid: Spamhaus, the 800 lb gorilla of RBL.
Also URIBL various feeds. Direct query to a dedicated
address with fresh data FTW.
Free: I find SORBS pretty quick to list. However I dislike them for
their annoying delisting procedures when my SMTP pool gets on
their list due to a compromised account. Takes days to get off.
Honorable Mention: SpamEatingMonkeys
Re: Fastest listing RBL ?
Posted by Rob McEwen <ro...@invaluement.com>.
On 2/14/2017 11:04 PM, Ian Zimmerman wrote:
> Given a piece of horrible spam, on which RBL is the sending IP address
> likely to appear first?
>
> I want to rationally decide which RBL/s to consult at SMTP time. Afraid
> to use all of them, not just due to false positives, but also due to
> negative caching in DNS, which could affect the result when the spam is
> seen by SA a bit later.
Ian,
(if possible) Start monitoring the sending IPs of barely missed incoming
spam, in real time, as they come in. As soon as possible after the spam
comes in, check that IP on multirbl.valli.org (or mxtoolbox), and see
which RBLs are listing that IP (recognizing that SOME of those are going
to be situations where the IP wasn't blacklisted until seconds after the
spam was received - but many were listed before then)
Throw out the examples where the IP has a good reputation in places like
SenderScore or SenderBase... or where the IP is an MTA of a large/famous
hoster/ISP (but take note of which lists were listing those) - However,
SOME of those listings with decent scores at SenderScore or SenderBase
are appropriately blacklisted, such as a small sender with a massive
security hole where they are suddenly spewing out a massive amount of
spam. But if you notice an RBL hitting on MANY like this - they might be
too aggressive and even worthless - or perhaps more appropriate for low
scoring. There are a few lists which are VERY fast-reacting to new
spams, but have horrific expiration polices and/or are poorly managed -
and would produce many FPs if used in production. But there are some
other lists which are just a little too aggressive for outright
blocking, but are very useful for scoring a few points (or less).
You should then notice about only about ~5-8 lists which rise to the top
- in the checking I described, they seem to have very few FPs (you won't
know for sure until you test them in production) - and they are very
fast reacting. Still, SOME of these are just a little too aggressive for
outright blocking (or scoring at/above threshold) - but are great for
high scoring. But you may not be able to accurately measure their FP
level until you've used them in production for some weeks.
A smaller amount of these RBLs (that rose to the top)... in addition to
being fast-reacting... block much unique spam missed by the other lists
AND have few enough FPs for you to probably feel comfortable outright
blocking (or scoring at/above threshold). You might find ~3-5 such
lists, including zen.spamhaus.org in that elite group.
--
Rob McEwen