Best of the ISP-Lists

General

Mail From Brazil Isn't Welcome Here

Members of the ISP-Tech list contemplate the alternatives as one ISP considers shutting off Brazil because of spammers with total access to the ILEC's network.

[October 18, 2002]

On the ISP-Tech list in September, JN queried,

"I'm having problems blocking a spammer's network from cramming our mail server. I can easily enter IP routes for his class Cs and send them to null0, but this guy has access to 200.128/9, and I can't enter enough class Cs to keep him off our network for more than a couple of minutes before he finds a workable IP and brings our mail server to a crawl again. I'm tempted to just direct all 200.x.x.x to null0: in fact, I even tried that, to no effect. Am I doing something wrong?"

Some respondents considered blocking the source country as a whole:

[SS asked] "That's a huge number of addresses: where's he coming from?"

[JN explained] "It's Telefonica, the Brazilian ILEC. They've hit us on IPs ranging from 200.161 to 200.207. At this point, I'm willing to lose all of Brazil, if I have to."

[BL offered] "Check out Blackholes.us. They have blackhole listings for many spammer-friendly countries. Simply add them to your sendmail.mc as follows:

FEATURE('dnsbl', 'brazil.blackholes.us','brazil.blackholes.us refused - Mail from Brazil isn't welcome here')dnl

Then regenerate the cf files and restart sendmail. Blackhole sites that I personally use include the following:

FEATURE('dnsbl', 'blackhole.compu.net')dnl
FEATURE('dnsbl', 'pacbelldsl.compu.net','Pacbell DSL refused - Dialup address address use your local mail server')dnl
FEATURE('dnsbl', 'list.dsbl.org')dnl
FEATURE('dnsbl', 'opm.blitzed.org')dnl
FEATURE('dnsbl', 'dun.dnsrbl.net','dnsrbl refused - Dialup address use your local mailserver')dnl
FEATURE('dnsbl', 'spam.dnsrbl.net')dnl
FEATURE('dnsbl', 'Dialups.relays.OsiruSoft.com','osirusoft refused - Dialup address use your local mailserver')dnl
FEATURE('dnsbl', 'bl.spamcop.net')dnl
FEATURE('dnsbl', 'inputs.relays.osirusoft.com')dnl
FEATURE('dnsbl', 'relays.ordb.org')dnl
FEATURE('dnsbl', 'Spamsites.relays.OsiruSoft.com')dnl
FEATURE('dnsbl', 'Spamhaus.relays.OsiruSoft.com')dnl
FEATURE('dnsbl', 'Spews.relays.OsiruSoft.com')dnl
FEATURE('dnsbl', 'flowgoaway.com')dnl
FEATURE('dnsbl', 'blackholes.intersil.net')dnl

The above blackholes catch 99.9 percent of the spam sent to users of my service. I receive about one complaint about mail getting blocked every six months or so. I just inform the user and ISP what happened, and how to get themselves removed from the lists. This seems to settle most people's issues with the use of the blackhole list."

[JN noted] "Fortunately, we have very good blocking in place on our mail server: I was instantly able to deny the sending of spam by Brazilian IPs. But that doesn't change the fact the server still accepts the mail, and must generate the bounce back, creating both CPU load and wasted bandwidth. I would prefer to just snip the connection from his network to mine at will."

Others pointed out that it's crucial to block the right part of the traffic:

[DS observed] "If you blackhole his route advertisements, the traffic back to him is all that's stopped. You will, in effect, make him SYN flood your mail servers. Think about it: the frying pan you are in now may be more agreeable than the fire."

[JN countered] "How would he SYN flood my mail server, if his IP traffic never reaches it because the router throws it away?"

[ED explained] "You null route his netblock, meaning the traffic you send never reaches them. You still receive incoming SYN attempts, but your SYNACK never reach their destination. They keep retrying the SYN, and you suddenly are the proud recipient of a SYN flood."

[PH added] "The blackhole route throws away traffic from your server back to his. The connection will never be made, but your server will be trying to complete it, and his spamware will probably try a few SYNs per connect attempt, and a few connect attempts per victim."

Still others suggested that an access control list (ACL) may be the best solution:

[ED advised] "Don't null route. Use an ACL to block based on source."

[PH agreed] "When using an access list, you prevent the SYN from ever reaching the server (he'll still try to send them, but at least you are not as much affected by it). Put the access list on the interface of the LAN the mail server is on."

[JN contended] "ACLs are not preferable due to processor intensiveness, but if it is the only way to stop it, then so be it."

[DS explained] "While ACLs do increase your CPU load on non-hardware forwarding platforms, the effects can be marginal. The importance is to look at your average CPU load prior, pick the best switching path to give you the most CPU headroom, and if you have a really long ACL, make sure you are enabling TurboACLs (also known as compressed-ACLs)."

[PH added] "At least by putting ACLs on the output interface, if things get slowed down due to big traffic flows, there's better buffering that way. If it's a big LAN with lots of other servers, another option is to use a second interface, route just the mail server address(es) out to it, and put the ACL there. Or better yet, investigate how to ACL in the mail server's OS."

—End