Discouraging Spammers

[couttsj]

Most forum users are probably more concerned about reducing spam to their real customer accounts than they are about reducing spam attempts to a non-existent MTA, but I will pass this information on anyway. My problems all started with a very high volume of DNS requests for MX records for a particular domain that no longer supported a mail server. When that record was non-existent, those requests were followed by requests for A records and many subsequent attempts to connect to the A address on port 25. So I introduced an MX record with a non-routable IP address. That was all fine and dandy until Microsoft started bombarding our DNS with thousands upon thousands of requests for MX/A records. I complained and they actually did resolve the issue, but only for 3 months. After it started up again with a vengeance, I loaded a valid MX record and a Pseudo SMTP server that rejected all email requests with a 550 error on the RCPT command. Much to my surprise, the excess DNS traffic suddenly stopped. I can only assume that Microsoft kept searching until it found a real live MTA. Why, I haven’t a clue.

Then Yahoo started bombarding our DNS server with type 99 requests, to which I could get no resolution. It just suddenly quit on Nov. 2. The Yahoo DNS traffic was no doubt due to spammers using our domain name for spam attempts to Yahoo customers. So I set about trying to figure out how to discourage spammers from using our domain name. Using the 550 error response following the RCPT command did not do that. From a typical day:

2011/10/21 - 3,586 Connections/3,487 MAIL FROM:s/3,476 RCPT TO:s

Basically we see a 1/1/1 relationship.

So I modified the Pseudo server to return a 554 error instead of the normal greeting. According to RFC5321, a 554 greeting response is supposed to indicate the server does not receive email, but all it did was make the connection attempts skyrocket.

So then I modified the server to return a 553 error on the MAIL command, and this produced some positive results:

2011/10/31 - 976 Connections/7,246 MAIL FROM:s

Connections were reduced by a factor of 3, but some spam engines just sent multiple RSET’s followed by different MAIL FROM:’s. Reducing the connection timeout from 90 seconds to 30 seconds cut down on the multiple MAIL FROM:’s.

2011/11/18 - 623 Connections/1,132 MAIL FROM:s

The number of connection attempts continues to decline on a daily basis, so the 553 error (probably any 500 level error) does appear to be achieving the objective. However, it is difficult to say what the impact is on DNS volumes at this point in time.

J.A. Coutts

[petzl]

The number of connection attempts continues to decline on a daily basis, so the 553 error (probably any 500 level error) does appear to be achieving the objective. However, it is difficult to say what the impact is on DNS volumes at this point in time.

J.A. Coutts

I find once spammers have an email address they keep plugging it no matter what. I would say a genuine email server may have someone (even Yahoo) respond to error messages and do something about the spammer using their system. In which case the spammer moves somewhere else with same email list. There are a few spammers that want to avoid being blocklisted and therefore try to only send email to legitimate addresses and some who send to those that don't report them.

I have found the best way to reduce spam is to report them, most competent operators do, do something (seems to be a majority).

Some providers like Hotmail, Gmail, Yahoo, etc do not send anything back (in many cases) but just bit-bin email without it even ending up in junk folder. I know this because I have a number of "free throwaway email accounts" with these providers and they are all effective (Gmail presently the best) at dumping email. Never get rubbish from Brazil ever for instance not that I want it, but I know from SpamCop they are the worst spamming nation around (and they don't care) yet none of it appears even in junk folders. I even have a Brazil spammers 3 meg email list which has over a 1000 gmail addresses in it (none would be bounced or even get to "spam folder).

So my message is it is good business to ensure one's email server dosn't spam (blocking port 25 is first step). Geylisting is the best spam receiving action (needs a whitelist override/bypass)

A word of warning about Gmail (maybe the rest) is they (IMO) electronically read all emails (they call data mining). My problem is one does not know "what is next". They have gotten my birth-date from reading my emails. Gmail I use for "junk email" from Cruise Ships (which send happy birthday notices and Gmail picked up on it) Supermarkets, electronics, software etc. Gmail I have never given real name or Birthday. Now when I watch Youtube I notice their adverts target my age group (dating services). Google/Gmail even electronically read this group

[couttsj]

Update:

The connection attempts seems to have settled at 600-700 per day. With the reduced volumes, it is much easier to pick up trends.

1. From what I have read, I was under the impression that many spam engines do not wait for an SMTP response before spewing their garbage. The server still responds to a RCPT command after issuing the 553 error on the MAIL command, but I see less than 1 RCPT TO: in 10,000 connections.

2. Address mining attempts seemed to have dropped off to virtually none, because most engines observe the 500 level error message and terminate the connection themselves.

3. There are a few connection attempts that originate from legitimate mail servers, but by far the majority are from spam networks.

4. There are some definite trends that can be identified in just the HELO/EHLO and MAIL FROM responses. In some cases the HELO/EHLO are identical, and in other cases the user name or domain name is identical in the MAIL FROM:. If I had the desire I could identify the individual bot net IP addresses.

J.A. Coutts

[Farelf]

...If I had the desire I could identify the individual bot net IP addresses. ...

I wonder then if any of the public real-time blocklists are using similar methods to populate their lists - which would in turn raise the question of the duration of botnet addresses on such lists versus their (presumably fairly short) lifetimes within the botnets.

Just an idle thought (and no way to test against private in-house filtering - hotmail, yahoo, etc.?) but if you have the opportunity it could be interesting to run some candidate addresses through something like http://multirbl.valli.org/lookup/ to see if any patterns emerge.

Of course the majority of dynamically-allocated IP addresses will routinely appear on some of those lists and many others list only after actual spam receipts but the possibility remains that some filtering might be supported by botnet identification in public lists along the lines you describe - and the published policies of the listing agencies might even confirm that, though I have never heard of anything like it (but neither have I researched it).

The public RBL world has been evolving fairly quickly - "alive (313) dead (382)" according to valli.org currently. "The number of the dead long exceedeth all that shall live," as Sir Thomas Browne would have it. We can only guess at what is to come but we (or you) can have a bit of a poke at what there is now.

[couttsj]

As an example, this morning I have been receiving connections from a bot net that is using the same HELO (mail.mud.yahoo.com) and domain name ([at]yahoo.com) from these addresses:

109.108.58.31

109.188.238.194

109.200.118.182

112.79.40.3

113.162.134.78

113.166.162.1

116.193.136.26

124.106.1.44

183.82.46.146

186.18.146.184

187.59.220.48

188.115.236.187

189.153.180.183

190.62.77.164

194.213.23.21

195.161.9.2

2.179.4.245

200.90.150.144

201.249.226.253

217.114.234.176

41.140.89.202

41.190.228.122

41.254.1.211

77.122.146.182

77.40.108.106

77.42.191.1

83.139.185.102

85.26.186.176

85.26.231.12

91.192.99.208

94.112.73.36

94.141.45.139

95.110.66.220

95.76.237.202

Obviously the domain name could be real and Yahoo has hundreds of mail servers, but when combined with the geographic diversity of the IP addresses, it is obviously a spam network.

J.A. Coutts

[petzl]

As an example, this morning I have been receiving connections from a bot net that is using the same HELO (mail.mud.yahoo.com) and domain name ([at]yahoo.com) from these addresses:

Obviously the domain name could be real and Yahoo has hundreds of mail servers, but when combined with the geographic diversity of the IP addresses, it is obviously a spam network.

J.A. Coutts

You are allowed to put 20 IP addresses here

http://www.ip2location.com/free.asp

none look like Yahoo (first 2 are Russian, 3rd India then around the world none English speaking)

[Farelf]

(Excuse excess detail - others may be interested).

I noted from the multi-RBL check that CBL appears to be one blacklist which consistently picks up those you list - didn't look at many of those IP addresses with the multi check but another commonality is they often appear on 15-20 lists (out of 234) whereas a clean address will only show up on maybe 6-8. So there may be other individual BLs with a high hit rate.

I then checked a reasonable sample (~ 10-12% I guess) of the addresses you give on CBL - http://cbl.abuseat.org/lookup.cgi - and they were all listed there "appears to be infected with a spam sending trojan or proxy ... In other words, it's participating in a botnet ..." Sometimes the specific trojan is noted.

What is the CBL?

- see http://cbl.abuseat.org/ for description of methodology. It is copyrighted material, I could probably extract the relevant snippets here under "fair use" provisions but better to go to the source and get the whole story I think.

Anyway, it seems to me that part of their detection methodology might be the same as yours or similar to it. So that's the list accessed through cbl.abuseat.org which is also picked up under xbl.spamhaus.org.

DNS record lookup on reversed quad dot address like (testing for 109.108.58.31):

• 31.58.108.109.cbl.abuseat.org returns an A record of 127.0.0.2 if listed,
  
• 31.58.108.109.xbl.spamhaus.org returns 127.0.0.4 if listed.
  

Checking for Windows:

Microsoft Windows XP [Version 5.1.2600]

© Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\...>nslookup 31.58.108.109.cbl.abuseat.org

...

Non-authoritative answer:

Name: 31.58.108.109.cbl.abuseat.org

Address: 127.0.0.2

C:\Documents and Settings\...>nslookup 31.58.108.109.xbl.spamhaus.org

...

Non-authoritative answer:

Name: 31.58.108.109.xbl.spamhaus.org

Address: 127.0.0.4

C:\Documents and Settings\...>

So, either of those public BLs could be used as a basis to reject (at least some) server contacts from botnets I guess - but the detail is way above my pay grade <G>

[couttsj]

As I stated earlier, I managed to bring the connection attempts down to about 600-700 per day. But I was not satisfied. I wanted to bring it down further. Spammers rely on SMTP servers behaving as per the RFC's. The RFC's say that responses should be limited to 512 bytes. So what I tried was to respond with repetitive strings (with no Carriage Returns) to the MAIL FROM: command. I had no idea how the spam engines would respond, but in theory a legitimate SMTP client should terminate the connection. And indeed some of them do, but a great number of them just accept the traffic until the connection times out. But one group of servers responded in a very unique manner, which enabled me to identify them as a single entity (at the very least they were using the same engine):

23.19.190.160

23.19.190.161

23.19.190.162

23.19.190.163

23.19.190.164

23.19.190.165

23.19.190.167

23.19.190.168

23.19.190.169

23.19.190.210

23.19.190.212

23.19.190.213

23.19.190.214

23.19.190.215

23.19.190.216

23.19.190.217

23.19.190.218

23.19.190.219

This group of Addresses is assigned to Wallmer Promotion Corp

network:IP-Network-Block:23.19.190.128 - 23.19.190.255

network:Org-Name:Wallmer Promotion Corp

Wallmer is a Hungarian based company which operates a number of online gambling sites, and has contracted FCOOS to perform it's bulk mailing services.

31.214.133.131

31.214.133.132

31.214.133.133

31.214.133.134

This IP range is assigned to superpowerclicks.com operated by WINXPVPS.COM out of Germany.

113.168.103.183

121.17.47.73

163.24.155.111

180.243.73.77

184.154.166.172

187.40.82.66

189.3.47.107

190.7.61.253

194.25,134.80

195.232.199.126

2.176.130.38

200.47.199.9

209.157.66.247

210.241.98.241

211.10.17.50

213.130.27.36

61.136.63.10

68.230.241.139

68.230.241.149

72.249.144.22

75.148.235.51

80.172.236.38

84.235.53.11

85.10.200.142

85.53.235.211

92.81.179.69

These remaining IP addresses appear to be part of a BOT-NET.

I will let you know if any of this reduces spam attempt traffic.

[Farelf]

Some of those suspected botnet ones have a terrible record of spamming, others (or most, in the handfull I looked at) are virtually "clean" as far as the public blocklists are concerned. If you can identify botnet IP addresses before they become notorious you will certainly have achieved something worthwhile.

[couttsj]

Some of those suspected botnet ones have a terrible record of spamming, others (or most, in the handfull I looked at) are virtually "clean" as far as the public blocklists are concerned. If you can identify botnet IP addresses before they become notorious you will certainly have achieved something worthwhile.

My apologies. I cannot say for certain that those miscellaneous IP addresses are part of a BOT-NET. Upon closer examination of the log file, it appears that certain problem engines are not waiting for a response of any kind, and continue to attempt HELO/EHLO and MAIL FROM commands. Because my Pseudo Server is in a loop sending warning messages, it does not receive any incoming messages on that socket, and eventually times out and disconnects. After disconnection, there is still incoming data in queue. When another server connects to the same socket, the incoming data from the new connection gets mixed in with the old queue data, making it appear as if they are one of the same. I now have a full day of data, but analyzing it is taking much longer.

J.A. Coutts

[couttsj]

Well, it did not achieve the desired results. It was anticipated that volumes would escalate at first, and then drop off as spammers got tired of the back feed. Unfortunately, it just increased daily:

12/01/24 Total Connections = 4,264

12/01/25 Total Connections = 5,029

12/01/26 Total Connections = 6,406

12/01/27 Total Connections = 8,163 (prorated)

So I changed the program back to sending a 553 error on the MAIL FROM: command, and just ignored any further traffic on that particular socket (plus a nasty message back to sender).

J.A Coutts

[Farelf]

Oh well, worth trying. You now know, at least, there are differing results with various 5.5.x error codes and that (maybe) botnets are pretty hard to discourage. Maybe other admins have some suggestions? No doubt you've searched but I guess anything effective is not likely to be widely discussed.

[couttsj]

Oh well, worth trying. You now know, at least, there are differing results with various 5.5.x error codes and that (maybe) botnets are pretty hard to discourage. Maybe other admins have some suggestions? No doubt you've searched but I guess anything effective is not likely to be widely discussed.

It is not a total loss. A 500 level error in response to a MAIL FROM: command should produce 1 of 2 results from the sending server; either a QUIT command followed by a disconnection, or simply a disconnection. Even though the RFC's permit an RSET followed by more commands, logically there should never be a need to do this. If one MAIL FROM: is not acceptable, then why should there be another one more acceptable. The modified program found 67 spammers in less than 5 hours that followed this unusual procedure. 9 of those 67 were not listed on any DNSBL, and 8 were listed only on 1 or 2.

J.A. Coutts