Russia, China World's Biggest Spammers

An anonymous reader writes "According to this ZDNet article, The Spamhaus Project has warned that organised cirminal gangs in Russia are supplying U.S.-based spammers with details of compromised PCs that can be manipulated to send junk mail. According to Spamhaus director Steve Linford, the Russian gangs aren't constrained by any anti-spam or cybercrime laws in their home country and have no respect for legislation implemented in other countries. Also, apparently 70 percent of spam is sent from China by American spam outfits who in turn have hosting arrangements with Chinese ISPs."

Comments

Steve Linford's corrections

[alanw]

in this posting to news.admin.net-abuse.email, Steve makes a couple of corrections to the article:

> Linford also told the conference that some 70 percent of spam is sent
> from China by American spam outfits who are hosting their servers with
> Chinese ISPs.

That should say: "70% of spam advertises URLs hosted in China" (not "is
sent from").

...

> Unless things change drastically, we predict that 80 percent of
> email will be spam by December this year, and it's very likely to go
> to 90 percent by this summer," Linford warned.

That should of course say "next summer".

Spamassassin 3.0 and URIBL_SBL

[alanw]

The soon-to-be-released Spamassassin 3.0 will have the URIBL_SBL test. This will test the IP address of domains referenced in the body of the spam against lists of known spammer hosts. This will reliably trap all of the 70% of spam that advertises web sites hosted in China.

http://www.spamhaus.org/sbl/howtouse.html
http://www.spamassassin.org/full/3.0.x/dist/rules/ 25_uribl.cf

spam stats

[humankind]

Some analysis of my rejected mail logs over the last 24 hours revealed this:

Total rejected spam: 16235 (and 8178 accepted messages)
Confirmed Chinese spams: 1229
Confirmed Korean spam: 1414
Confirmed Canadian spam: 264
Confirmed Polish spam: 342
Confirmed US/comcast spam: 1363
Confirmed French spam: 181
Confirmed Southwest Bell spam: 382
Confirmed Italian spam: 114
Confirmed Spanish spam: 167 (TDE must have finally gotten their act together)
Confirmed German spam: 967
Confirmed Netherlands spam: 452
Confirmed Brazillian spam: 864

This is by no means a scientific analysis - it's based on hard-coded IP-based blacklists that are caught before standard blacklists are checked.

Spamcop RBL rejects: 5460
Spamhaus RBL rejects: 1509
Njabl RBL rejects: 1807
Homebrew RBL rejects: 6382

The big three spam sources have traditionally been Korea, China and Brazil. Comcast has been the big US spammer. France (wanadoo) has also been a major contributor though it doesn't seem to be reflected in this days' logs.

Re:What is the best way to stop this?

[RT Alec]

1. ISPs (and any other business that gives a workstation a "real" IP address) need to block egress port 25. Comcast is going to be doing this soon, others should soon follow suit. This plugs the zombies.
2. IP addresses that continue to send spam will be blacklisted. With the zombies effectively out of the loop this will become easier (albeit never quite perfect).
3. SPF and other authentication schemes need to be adopted to prevent "spoofing" and so called "Joe jobs".
4. E-mail providers (including small companies) need to deploy mature e-mail systems for their users. In 1995 it was fine to accept e-mail from anyone on port 25, with no authentication and no encryption. In 2004, remote clients need to have an SSL connection available (both for sending mail and accessing inboxes), and must require authentication before accepting initial mail submission (SMTP+TLS+AUTH). Not only is this more secure, but it also addresses the issues always raised by blocking egress port 25 and deploying SPF.

Once these techniques and practices be come commonplace, it won't matter if spam originates from lawless areas of the world. Existing laws against fraud (and other illegal business practices) will cover the extreme efforts that will be necessary to continue spamming.

Appendix:
SMTP+TLS+AUTH is not that tough, no whining. All modern mail clients support it, on all platforms. There is a little bit of work to do on the server end, but that's what you pay your ISP (or IT department) for:

• postfix
• sendmail
• exchange
• qmail

Re:My new spam fighting techniques.

[Zocalo]

I'm not too sure what the original poster is doing from the description, but I reject some connections based on HELO/EHLO too, so I can tell you how what I do works. But firstly, since you say that you don't know the details of SMTP, let's clarify what HELO/EHLO do:

When host connects to an SMTP server in order to send it an email, it will receive a banner back which may include the string "ESMTP". If it does then the remote SMTP server supports an enhanced version of SMTP with additional features, "ESMTP". If the host also understands ESMTP, then it should respond with an "EHLO" command. If the host does not understand ESMTP, or the string is not present in the banner, then the host will respond with the "HELO" command defined in the original SMTP RFC to use the simpler set of SMTP commands.

In either case, "HELO" or "EHLO", the host should also tell the server its host name, viz:

EHLO host.company.com

Ideally, "host.company.com" will also have a valid reverse DNS record which will match the IP connecting to the SMTP server. However, the SMTP RFCs do not actually *require* that this is the case, nor for that matter that the hostname is provided at all. Frequently the hostname will be given, but will not be a valid fully qualified domain name on the Internet. So, depending on how draconian you want to be, there are a number of options for rejecting the connection before any data is sent:

• No hostname after HELO/EHLO
• Hostname given is just a host, not an FQDN
• Host domain name given does not appear to exist in DNS
• FQDN given does not have RDNS record
• FQDN given has RDNS record, but it does not match the IP connected

Using any or all of those will certainly reduce your spam intake, but may also cause legitimate email to be rejected, as usual YMMV as to how much. One thing to watch for if considering this though is that a *lot* of legitimate Windows boxes, including some operated by ISPs, seem to have been configured so that they provide their NetBIOS name when they HELO/EHLO, all but the first check listed above would refuse the conection from such a server.