Re: More sorbs blacklisting
Micah Anderson wrote:
> You are correct to be so literal, however, I also know that quite a
> large number of people use spamhaus (and even worse SpamCop) in their
> RBLs, so when spamhaus adds someone it results in damage, regardless of
> whose fault it is. Had spamhaus not done this, it would not have
> happened. Had the mail server admins not used spamhaus this also would
> not have happened. Mail admins wouldn't add spamhaus if they didn't
> respect it, because spamhaus has managed to convince a lot of people
> that they should be used, and a lot of people have agreed. As soon as
> you add an RBL, you are turning over the blocking work to someone else
> to handle.
Regardless of which side of the fence you're on -
The local MTA admin(s) should be aware of the risk of "outsourcing"
their blacklists to another entity. Admin(s) should also be aware of the
different ways in which they can employ RBLs, *should they choose to use
them* (e.g. outright reject at SMTP-time, vs. ratelimiting RBL-listed
hosts, vs. bumping up a SpamAssassin score etc..).
Many admins knowingly accept this risk. Presumably many admins (and/or
their end users) have had good results using RBLs; you can infer this
from their popularity (and how often RBLs are mentioned on this list!).
Of course, other admins don't/won't use these RBLs and/or employ their
own blacklist [1].
I have personally been on both ends. As an admin who is responsible for
keeping SPAM under control, I might choose to use one or more RBLs.
OTOH, I've seen outbound MXes under my control get blacklisted, and the
mess it creates when your queue (and disk) fills up, as the remote end
refuses your mail with a 5xx.
So, yes, the RBLs aren't perfect IMO. There's collateral damage,
lost/deferred legitimate mail..etc. Risk/Benefit, right tool for the job
and other cliches come to mind..
-Matt Cuttler
1) In an attempt to keep this somewhat related to Debian: rbldnsd is
available on stable, testing and unstable. This is a Good Thing.
Reply to: