I (like many others) have had a considerable increase in spam in the
last few months. I've got a few questions about RBLs.

I'm currently using an evaluation version of mail-abuse.com. Is this
likely to be superior to my current list (see below)? Where can I get
hold of a price list for it, and am interested in subscribing to it.
The TrendMicro website is rather unful.

What are the favoured RBLs these days? - I haven't reviewed this for
some time now. Obviously the priority is avoidance of false positives.

I currently use the following RBLs:

combined.njabl.org
cbl.abuseat.org
sbl.spamhaus.org
list.dsbl.org

Because I run a small organisation I'd like to keep costs to a minimum.

In comp.mail.sendmail Robert S <robert.spam.me.senseless@gmail.com>:
> I (like many others) have had a considerable increase in spam in the
> last few months. I've got a few questions about RBLs.

Full ack, the crap seems to raise permanently and anything
getting you rid as cheap as possible from as much ratware as
possible is quite welcome. 1000-2000 rejects hourly on a single
MTA seems common lately. ;(

> I'm currently using an evaluation version of mail-abuse.com. Is this
> likely to be superior to my current list (see below)? Where can I get
> hold of a price list for it, and am interested in subscribing to it.
> The TrendMicro website is rather unful.

> What are the favoured RBLs these days? - I haven't reviewed this for
> some time now. Obviously the priority is avoidance of false positives.

bl.spamcop.net is IMHO one of the very good ones, though false
positive are not impossible, they tend to be quite seldom.

> I currently use the following RBLs:

> combined.njabl.org
> cbl.abuseat.org
> sbl.spamhaus.org

SBL is nice for running from SA to score up, but might produce to
many false positive if rejecting directly based on it, YMMV.

Spamhaus xbl list on the other hand seems a quite sure bet. But
doesn't block much as much as spamcop.

> list.dsbl.org

> Because I run a small organisation I'd like to keep costs to a minimum.

AFAIK most lists are free for light usage? Though it would be
nice to donate a few bucks to those lists if you can, to support
their operations.

I'd look in addition into Greylisting to keep ratware away, the
advantage are zero false positive, any real MTA should be able to
cope with it easily and resend.

Sendmail's greeting pause in recent versions can keep stuff away
without using to much of your resources.

To keep up with all the ratware hammering legitimate MTAs 24/7
you need to combine any possibility. Even multi line HELO messages
seem to confuse some ratware but no real MTA.

Good luck

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 453: Rhythmic variations in the voltage reaching
the power supply.

Michael Heiming wrote:

> I'd look in addition into Greylisting to keep ratware away, the
> advantage are zero false positive, any real MTA should be able to
> cope with it easily and resend.

I have noticed that greylisting starts to fail, there are spammers who are
trying up to ten times to send the same spam before giving up, most greylists
I have encountered out there has a threshold of around 3 times, before accepting.


//Aho

In comp.mail.sendmail J.O. Aho <user@example.net>:
> Michael Heiming wrote:

>> I'd look in addition into Greylisting to keep ratware away, the
>> advantage are zero false positive, any real MTA should be able to
>> cope with it easily and resend.

> I have noticed that greylisting starts to fail, there are spammers who are
> trying up to ten times to send the same spam before giving up, most greylists
> I have encountered out there has a threshold of around 3 times, before accepting.

Indeed, but it looks to me like 0.1% or so right now and most try
resending immediately and not waiting long enough to come around
the configured greylisting time which could be enhanced if
ratware is trying to adopt.

Tough I have an eye on it, but it seems until now the only way to
get rid of low SA scores which would pass through without. If the
crap comes back chances are it is already known to DCC and
friends, which should be enough to score up (SA).

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 348: We're on Token Ring, and it looks like the
token got loose.

Robert S <robert.spam.me.senseless@gmail.com> wrote:
> I (like many others) have had a considerable increase in spam in the
> last few months. I've got a few questions about RBLs.
>
> I'm currently using an evaluation version of mail-abuse.com. Is this
> likely to be superior to my current list (see below)? Where can I get
> hold of a price list for it, and am interested in subscribing to it.
> The TrendMicro website is rather unful.
>
> What are the favoured RBLs these days? - I haven't reviewed this for
> some time now. Obviously the priority is avoidance of false positives.
>
> I currently use the following RBLs:
>
> combined.njabl.org
> cbl.abuseat.org
> sbl.spamhaus.org

Looks like you could replace those three with just sbl-xbl.spamhaus.org
and have fewer lookups.

> list.dsbl.org

Yes.

Also consider dnsbl.sorbs.net.

Greylisting s a lot. greet_pause s a little. Permanently
rejecting email from bad ISPs with access.db is somewhere in between.

--
Warren Block * Rapid City, South Dakota * USA

> Also consider dnsbl.sorbs.net.

I seem to remember that this is quite aggressive and gives FPs. Is
this the case?

>
> Greylisting s a lot. greet_pause s a little. Permanently
> rejecting email from bad ISPs with access.db is somewhere in between.
>

What greet_pause interval is recommended? I've had it running on 5000
overnight and its blocked a few sites. Can this give FPs?

What is the recommended way of doing greylisting? Most (gentoo/debian
are relevant to me) distros don't seem to have greylisting packages for
sendmail as far as I can see. I'd prefer to use something that's
included in my distro so I can keep up with security fixes. There's a
useful looking page at http://spamlinks.net/filter-server-greylist.htm,
but I'd like to know which method is the most reliable.

Robert S <robert.spam.me.senseless@gmail.com> wrote:
>> Also consider dnsbl.sorbs.net.
>
> I seem to remember that this is quite aggressive and gives FPs. Is
> this the case?

The answer to that will vary depending on your situation.

>> Greylisting s a lot. greet_pause s a little. Permanently
>> rejecting email from bad ISPs with access.db is somewhere in between.
>
> What greet_pause interval is recommended? I've had it running on 5000
> overnight and its blocked a few sites. Can this give FPs?

At 5000, I have not seen false positives (heard of them, though). This
will depend on what MTAs the sending sites are using.

> What is the recommended way of doing greylisting? Most (gentoo/debian
> are relevant to me) distros don't seem to have greylisting packages for
> sendmail as far as I can see. I'd prefer to use something that's
> included in my distro so I can keep up with security fixes. There's a
> useful looking page at http://spamlinks.net/filter-server-greylist.htm,
> but I'd like to know which method is the most reliable.

Can't speak to recommended, but there are numerous ways. My PDF notes
on using milter-greylist with FreeBSD are here:

http://www.wonkity.com/~wblock/docs/greylist.pdf

My setup has been entirely reliable for a small-scale system... but then
it's when things get bigger that they start to break more.

--
Warren Block * Rapid City, South Dakota * USA

> >> Greylisting s a lot. greet_pause s a little. Permanently
> >> rejecting email from bad ISPs with access.db is somewhere in between.
> >

My initial impression is that greylisting blocks more legitimate mail
than spam. I left it on for a lot of yesterday and overnight, and
there are about three messages send from other accounts of mine
(including my work one) that haven't been sent since last night. These
ISPs seem to use different IP addresses when they resend messages. If
I've turned up this problem after less than 24 hours, I'm sure it will
affect other ISPs. I don't think whitelisting these ISPs is going to
, because I assume other ISPs use different addresses.

Think I'll go back to RBLs + spamassassin, and put up with the odd
false negative.

BTW - nobody answered my question about mail-abuse.com. It seems to be
picking up a few things that spamhaus and NJABL don't pick up. How
can I find out the cost of the service and does anybody out there use
it?

In comp.mail.sendmail Robert S <robert.spam.me.senseless@gmail.com>:
>> >> Greylisting s a lot. greet_pause s a little. Permanently
>> >> rejecting email from bad ISPs with access.db is somewhere in between.


> My initial impression is that greylisting blocks more legitimate mail
> than spam. I left it on for a lot of yesterday and overnight, and

My experience is that it locks out zero legitimate MTA, as any
will understand the RFC defined error code and resend.

> there are about three messages send from other accounts of mine
> (including my work one) that haven't been sent since last night. These
> ISPs seem to use different IP addresses when they resend messages. If

Haven't seen this at all. Even if you load balance over a couple
of outgoing MTA, the last one will get the error code and should
resend according to its configuration, this seems the only
downside about greylisting. You can't influence this time, which
might be pretty long in rare cases.

But then, the fewer people use it, the more likely it is to drive
ratware away from systems using it. ;-)

[..]

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo zvpunry@urvzvat.qr | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 222: I'm not sure. Try calling the Internet's
head office -- it's in the book.

> Haven't seen this at all. Even if you load balance over a couple
> of outgoing MTA, the last one will get the error code and should
> resend according to its configuration, this seems the only
> downside about greylisting. You can't influence this time, which
> might be pretty long in rare cases.
>

I actually get the impression that one of the MTAs isn't resending the
messages.

Looks as if greylisting depends on the legitimate MTAs behaving
properly.

I might test this out more thoroughly when I don't have as many
important messages to wait for.

"Robert S" <robert.spam.me.senseless@gmail.com> writes in comp.mail.sendmail:

> > >> Greylisting s a lot. greet_pause s a little. Permanently
> > >> rejecting email from bad ISPs with access.db is somewhere in between.
> > >
>
> My initial impression is that greylisting blocks more legitimate mail
> than spam. I left it on for a lot of yesterday and overnight, and
> there are about three messages send from other accounts of mine
> (including my work one) that haven't been sent since last night. These
> ISPs seem to use different IP addresses when they resend messages. If
> I've turned up this problem after less than 24 hours, I'm sure it will
> affect other ISPs. I don't think whitelisting these ISPs is going to
> , because I assume other ISPs use different addresses.

I guess that it is quite natural move messages to another server when
they can not delivered immediately or during certain short intervall.

Another server have then "slow" queue, which have different parameters.

/ Kari Hurtta