283363Re: Outbound RBL
- Feb 1, 2012On Tue, Jan 31, 2012 at 09:44:22PM -0600, /dev/rob0 wrote:
> On Tue, Jan 31, 2012 at 08:54:33PM -0600, Noel Jones wrote:Yes, however in our practice, there is good reasons to "block" the IP too
> > On 1/31/2012 8:30 PM, list@... wrote:
> > > What we were thinking was using RBLs to dynamically block known
> > > malicious IPs before allowing SMTP Auth to occur, hopefully
> > > seeing a decrease in spam. Not sure if this would have
> > > unintended consequences, which is why I am consulting the list.
> > That would probably cause a huge number of false positives; a
> > support desk nightmare.
> > Many "consumer" IPs are listed on the popular RBLs. As a
> > consequence, legit users may be unable to send mail because their
> > dynamic IP was used by a spambot at some point in the past.
> > I don't know of any RBLs that would be useful on incoming
> > authenticated mail.
> Even a locally-maintained private DNSBL is the wrong approach. When
> spam is detected from an authenticated account, revoke the
> credentials. You have no other good choice. Even after the user's
> system is purged of the ratware, you cannot be sure that these
> credentials were not forwarded to the botnet's control node[s].
(if it's not our IP, then of course we have the chance to solve the
situation better with contacting the current user of the IP - anyway,
"not our IP pool" is quite a good sign that smtp username/passwd is
used illegally from there; for sure not always, but there is a good chance
* it's fairly common that the IP tries to abuse another smtp user of ours
then in the future
* it helps decrease the load of the submit server: even if revoke user's
crendentials, it has the cost (which is maybe more than using a locally
stored mail submission IP blacklist like stuff) that user must be
checked, etc. The "evil" IP still tries to send mail for hours (or even
days - in our practice again) even after revokation of user's
credentials, which can consume resources of the submit server.
[that was the reason I thought about using postscreen for mail submission
but only for BL features and using a "local" BL, so postfix smtpd
processes, smtp auth stuffs etc are not under load because of these
We usually revoke submit user's credentials (of course), we inform the user
about the problem, and we block (with a locally stored list) of the IP which
abused the mail account, _if_ the IP does not seems to be part of our IP
pool, and either not the IP of "neighbour ISPs" in our country (which is
quite common that users use different local ISPs using the same ISP's mail
submission service though) and also seems to be a dynamic IP pool somewhere
or no PTR record, etc etc.
For sure, it's quite a "manual" work, and not always done just in extreme
cases when the IP does "really evil things".
> > You can test this yourself by inserting "warn_if_rejectOf course I only wrote about a "local RBL" which is maintained by ourselves
> > reject_rbl_client zen.spamhaus.org" just before
> > permit_sasl_authenticated. Then watch your logs for
> > reject_warning: from legit connections. (this is a
> > logging-only function; the client is not rejected and
> > sees no additional messages.)
> Perhaps a slightly less insane ;) test would be to check
> xbl.spamhaus.org at that point. But hotels and public hotspots are
> often listed there. You might catch a few bad users, but you will
> *not* have reasonable protection for clean users.
for this purpose, not a general-purpose public BL.
- << Previous post in topic Next post in topic >>