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, l...@airstreamcomm.net 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 abusers/spammers] 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.
