Use RBLs in MTA or Maia?

Adam:

If your queues are filling then you need to do something
more to reject
mail early in the process.  Do you run any gateway servers
in front of
your MM box where you can do some sanity checks and reject
any unlisted
users?  If so, then you might consider using a weighted
scoring system
such as policyd-weight which allows you to require a source
to be in
multiple DNSBLs of your choosing.  We have used
policyd-weight at times
in the past to good effect and it does make the process of
mail
rejection at that level less of a one swing and your out
approach.   We
need to accept mail from some, how to say, challenged mail
servers so
straight DNSBL checks often lead us to FPs which
policyd-weight can
eliminate to some degree.   Also, if your not using it
perhaps you could
implement selective greylisting on some of the more
spam-abused ISPs
sending into your system.

Best,



Adam Ellsworth wrote:
> Hello,
>
> I'm revisiting/tweaking my Maia setup (going on a
couple years I
> believe!) and I'm still divided on proper
implementation of RBLs. I've
> simply read too many threads and gotten conflicting
opinions, both of
> which I agree with... looking for advice:
>
> + On the one hand, using RBLs (and SURBL?) at the MTA
level is much
> less processor-intensive and rejects the mail at the
SMTP conversation
> level. However, it's black and white, not real
configurable and
> perhaps more prone to false-positives.
>
> + On the other hand, letting Spamassassin do all the
checking seems to
> be very reliable from a false-positive standpoint,
though perhaps more
> resource-intensive. It works very well for me -
however, my Maia
> queues get unmanageably large quickly; many users
easily get 100s of
> spams per day, and they're just not paying attention to
the daily
> digests or logging into the queue interface unless they
already feel
> they're missing a message. I know this impacts bayes
training as well,
> but "forcing" users to log into Maia is not
an option for me... (of
> course some are happily using it already.)
>
> I posed a similar question a year or so ago and was
told to look into
> blocking more at the MTA level... but other threads
here contradicted
> that advice. I recall reading at some point about
implementing a
> cut-off score where mail is unquestionably considered
spam and not
> quarantined. Is that considered a best-compromise
solution now, or no?
>
> I hope not to be off-topic or create a war against two
> reasonable methodologies... I just really need some
feedback!
>
> Thank you,
> Adam Ellsworth
>
------------------------------------------------------------
------------
>
> _______________________________________________
> Maia-users mailing list
> Maia-usersrenaissoft.com
> http://www.renaissoft.com/mailman/listinfo/maia-users
>   
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

On Mon, 2007-11-05 at 13:38 -0600, Adam Ellsworth wrote:

> + On the one hand, using RBLs (and SURBL?) at the MTA
level is much
> less processor-intensive and rejects the mail at the
SMTP conversation
> level. However, it's black and white, not real
configurable and
> perhaps more prone to false-positives.

All I can do is provide a data point. Our stats show that
rejections
using DNS block lists at the MTA level are rejecting 10
times as many
messages as are being caught by spamassassin. We have yet to
have a
single complaint about a false positive that was traced to a
DNS block
list. We're using the Spamhaus XBL for everybody, and the
SBL only for
users who have asked us to be more aggressive in filtering.

--Greg


_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

Adam Ellsworth wrote:
>
> I hope not to be off-topic or create a war against two
> reasonable methodologies... I just really need some
feedback!
First of all, be sure you are accepting mail for only valid
users.

My approach has been to add greylisting with sqlgrey, which
brings the
load down to manageable levels.
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

On Nov 5, 2007 7:53 PM, David Morton <mortondadgrmm.net> wrote:
> Adam Ellsworth wrote:
> >
> > I hope not to be off-topic or create a war against
two
> > reasonable methodologies... I just really need
some feedback!
> First of all, be sure you are accepting mail for only
valid users.
>
> My approach has been to add greylisting with sqlgrey,
which brings the
> load down to manageable levels.

Greylisting will also improve your RBL's success rate as it
slows new
spam sources, giving the RBLs a chance to keep up.  I've
seen very
dramatic improvements on one RBL I use (and I know it is
spam trap
based, so makes sense). SQLgrey is working quite well here
too.

On a side note, it seems like sqlgrey would be fairly simple
to
integrate with the Maia project.. they both do sql lookups
on a domain
and user basis.. anyone thought of working on it?
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

Adam Ellsworth wrote:
> Hello,
> 
> I'm revisiting/tweaking my Maia setup (going on a
couple years I
> believe!) and I'm still divided on proper
implementation of RBLs. I've
> simply read too many threads and gotten conflicting
opinions, both of
> which I agree with... looking for advice:
> 
> + On the one hand, using RBLs (and SURBL?) at the MTA
level is much less
> processor-intensive and rejects the mail at the SMTP
conversation level.
> However, it's black and white, not real configurable
and perhaps more
> prone to false-positives.
> 
> + On the other hand, letting Spamassassin do all the
checking seems to
> be very reliable from a false-positive standpoint,
though perhaps more
> resource-intensive. It works very well for me -
however, my Maia queues
> get unmanageably large quickly; many users easily get
100s of spams per
> day, and they're just not paying attention to the daily
digests or
> logging into the queue interface unless they already
feel they're
> missing a message. I know this impacts bayes training
as well, but
> "forcing" users to log into Maia is not an
option for me... (of
> course some are happily using it already.)
> 
> I posed a similar question a year or so ago and was
told to look into
> blocking more at the MTA level... but other threads
here contradicted
> that advice. I recall reading at some point about
implementing a cut-off
> score where mail is unquestionably considered spam and
not quarantined.
> Is that considered a best-compromise solution now, or
no?

For the sake of the maia servers, we've had to move *all*
sanity checking
upstream. Our postfix MX boxes impose sanity checks and
limits and do
greylisting - this eliminates over 50% of the incoming mail
right off the bat.
What survives passes through to the mailguard boxes, which
filter out at least
half of what they receive. If the mailguard boxes had to
bear the full
onslaught of incoming mail, they'd have melted down long
ago.

Joel
_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

>
>
> Hello,
>
> I'm revisiting/tweaking my Maia setup (going on a
couple
> years I believe!) and I'm still divided on proper
implementation of RBLs.
> I've simply read too many threads and gotten
conflicting opinions, both of
> which I agree with... looking for advice:
>
> + On the one
> hand, using RBLs (and SURBL?) at the MTA level is much
less
> processor-intensive and rejects the mail at the SMTP
conversation level.
> However, it's black and white, not real configurableÂ
and perhaps more
> prone to false-positives.
>
Adam,

I'm from the camp of putting RBLs at the MTA.  I think
ultimately the
single most deciding factor is the quality of the RBL you
are using.  In
my case, I use all the freebie ones, but I rely mostly on
Trend Micro's
Enhanced Reputation Services which is not free (use to be
MAPS).  In two
years I've had few to no false positives, and really the
only ones I get
are when the sender is coming from gmail, yahoo, etc. which
frequently end
up on the dynamic block list because they are a constant
source of spam.

Ryan

> + On the other hand, letting
> Spamassassin do all the checking seems to be very
reliable from a
> false-positive standpoint, though perhaps more
resource-intensive. It
> works very well for me - however, my Maia queues get
unmanageably large
> quickly; many users easily get 100s of spams per day,Â
and they're
> just not paying attention to the daily digests or
logging into the
> queue interface unless they already feel they're
missing a message. I know
> this impacts bayes training as well, but
"forcing" users to log
> into Maia is not an option for me... (of course some
are
> happily using it already.)
>
> I posed a
> similar question a year or so ago and was told to
look into
> blocking more at the MTA level... but other threads
here contradicted that
> advice. I recall reading at some point about
implementing a cut-off score
> where mail is unquestionably considered spam and not
quarantined. Is that
> considered a best-compromise solution now, or no?
>
> I hope not to
> be off-topic or create a war against two reasonableÂ
methodologies...
> I just really need some feedback!

_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users

On Mon, 2007-11-05 at 14:53 -0600, Administrator wrote:

> I thought that SBL contained confirmed spamming sources
and XBL
> contained an augmented CBL list.  

The X in XBL stands for eXploit. It means that only hosts
that are KNOWN
to be compromised are listed. The SBL lists hosts that are
spam-friendly
but may not actually be sending spam right now. We have
never had a
false positive that we have traced to the XBL.

>  I always see more hits by far on XBL than SBL.

So do we, but we check XBL first, and for more users. Our
default is to
use only the XBL and greylisting in front of Maia, but users
who have
chosen to be more aggressive will get the SBL, Korea
Services, and
several other lists of spam friendly ISP's, dialup hosts
that aren't
supposed to be sending mail directly, etc. Those *can*
produce false
positives which is why we don't enable those by default. In
particular,
the Korea Services list blacklists a good part of the
country of South
Korea, because most of the large ISP's over there are spam
friendly and
use their regular customers as human shields to protect the
spammers
(can't block their spammers without blocking their
legitimate users
too). Since we do have some scientists that work with South
Korean
scientists, there are some people here who cannot turn on
the more
aggressive RBL list without encountering false positives.
BUu we've not
had any problem with false positives on the XBL.

--Greg


_______________________________________________
Maia-users mailing list
Maia-usersrenaissoft.com
http://www.renaissoft.com/mailman/listinfo/maia-users