Loading ...
Sorry, an error occurred while loading the content.

283363Re: Outbound RBL

Expand Messages
  • Gábor Lénárt
    Feb 1, 2012
      On 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:
      > > 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].

      Yes, however in our practice, there is good reasons to "block" the IP too
      (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
      for that):

      * 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_reject
      > > 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.

      Of course I only wrote about a "local RBL" which is maintained by ourselves
      for this purpose, not a general-purpose public BL.
    • Show all 8 messages in this topic