Re: minimizing bandwidth taken be spam delivery attempts even when identifiable by "To:" address
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
ghe@slsware.com
GPG ID: D0D7FF20
Reply to: