On Thursday 16 February 2006 12:22, Daniel B. wrote: > My idea (which I don't is practical) was to query RBLs in real time > after receiving a TCP connection (SYN?) packet and before sending an > acceptance (or rejection) packet. Relative to your suggestion, that > would save the bandwidth of receiving the first spam message from the > spam host, although it would add the bandwidth cost of querying the > RBLs and would depend on the spammer's having already been identified.
Well, you can't block them until you have some indication they're about to spew spam. The first line of defense is the firewall -- if they're in one of the spam blocking chains, that IP has been declared a spam source, so the SYN packet never gets to the MTA. If they do make it through, my MTA (Postfix) checks with Spamhaus as soon as the SMTP HELO statement is received. If Spamhaus doesn't like them, they get rejected and logged. And soon thereafter, the Perl script sees the MTA's reject in the mail log and puts the IP in the firewall. This doesn't receive the whole email, just up to the first SMTP transaction statement. If Spamhaus doesn't know about them, they make it through the MTA; the entire email is received; and it's passed to bogofilter by procmail. Bogofilter does a pretty good job of recognizing spam, but goes ahead and accepts the email and shuttles it to the spam box (where I can check for false positive) -- and the Perl script adds the sending IP to the firewall. My inbox sees 4 or 5 spams a day; the spam box sees 15 or 20; and the firewall sees several hundred. None of the firewall hits are received -- they're blocked on IP at the SYN packet, like you want. (They're dropped, not rejected to reduce traffic a tiny bit.) If you query the RBL before the SYN packet hits the firewall and is verified to be a new TCP connection going to port 25, you'll be examining far too many packets. That would put a huge load on your mail server, and maybe generate lots of DNS network traffic, depending on where your DNS server is (mine's on the same machine, so most of the time the query is answered almost immediately, and with no network traffic, from bind's cache). Also, since the spammer chain in the firewall is much smaller than the asia chain and consists of known BadGuys, check the spammer chain first. -- Glenn English [EMAIL PROTECTED] GPG ID: D0D7FF20 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
