Practical Rate Limiting numbers?

[mgraci_ironport]

We got swamped by a german spammer sending over 160,000 messages in 4 hours.

Does anyone have any practical suggestions for using rate limiting beyond the defaults?

-Matt

[Corey_ironport]

I agree with Don. They might have cared before the days of zombies when processing power and bandwidth were supplied by the spammer. Even then, most spammers were just chickenboners who bought some turn-key bulk mailer and a DSL connection, turned it on before going to bed and let it do it's thing. I doubt that many half-baked spam applications have very robust tools that let the spammer know they're being dropped.

[jsikorski_ironport]

Great info - thank you for sharing. My observations weren't exactly recent (between 1 & 2 years ago), so that would explain the difference in behavior. I did see spam from zombies quite regularly during that time, but on a much smaller scale (they made the Top 50 list instead of the Top 10).

[lucas.castro_ironport]

wasn't the original question about rate limit?

I think that there is no a default and universal rate limit configuration...
It's depend of the amount of client's traffic.

what do you guys think? When rate limit is reached, ironport starts to give soft bounce "too many recipients for this hour" or something like that. So you can effectivly throttle some spammers.

[Pat_ironport]

It's spammers.  Here are my top 10 for the past 36 hours or so (that's how many logs I currently have uncompressed):
Count   IP Address       Host
------  --------------   -------------------------------------------------
122517  221.189.115.48   p16048-ipbffx02marunouchi.tokyo.ocn.ne.jp

Could you please tell us, how do you have produced this list? What kind of tool do you use?

[Donald Nash]

Could you please tell us, how do you have produced this list? What kind of tool do you use?

It was two years ago, so I don't remember for sure. I probably just used a long shell pipeline with grep, cut, sort, and uniq, then cleaned it up manually for presentation.

[jbivens_ironport]

1. dlnash, the blackhole would of kind of been nice, but one thing to keep in mind is that the system has to due the Senderbase lookups so the reality is the appliance would have to blackhole everyone until a score comes back.

2. TCP Refuse vs. Reject, you always want to do a Reject. Not only is it the right thing to do but it actually reduces network traffic and increases capacity. The difference is 4 packets for a TCP Refuse and 9 packets for a Reject, so overall the percentage packet cost is an additional 125%, sounds good. However with that said sending MTA interprets a TCP Refuse as temporary failure which basically means that they must retry to send the message at the specified retry interval. Now the reality is simplistic spam clients might not attempt to retry, but because some Anti-Spam company's tried to implement greylisting technology most spam bots are now programmed to attempt to retry. The moral of the story is that on average sending MTA will attempt to retry 39 times when presented with a TCP Refuse. So that seeming 125% packet reduction instead turns into 156 packets and a 1733% increase in overall packets. Additionally the CPU cost on the appliance for having to bring up and tear down TCP connections for all the rejected spammers and their 39 attempts over three days or whatever number they use.

3. Personallly this is what I set with regards to Senderbase scores, however I adjust the rate limit based on the size of the organization that I perform the install but below is my stand score ranges:

BLACKLIST: sbrs[-10.0:-3.0]
$SMTPREJECT
VALIDLIST: sbrs[2.9:10.0]
$ACCEPTED (Valid senders with low spam positive rates.)
HIGHLYSUSPECTLIST: sbrs[-3.0:-1.1]
$HIGHTHROTTLE
not.double.verified
nx.domain
$NODNS
SUSPECTLIST: sbrs[-1.1:-0.6]
$THROTTLE
LOWSUSPECTLIST: sbrs[-0.6:2.9]
$LOWTHROTTLE
ALL:
$NOSBRS

All the above ranges were based on several months of production mail log using spamtowho with the -all-sbrs flag to get the tenth of a point break down.

Hope this helps.

Sincerely,

Jay Bivens
IronPort Systems

[Donald Nash]

1.  dlnash, the blackhole would of kind of been nice, but one thing to keep in mind is that the system has to due the Senderbase lookups so the reality is the appliance would have to blackhole everyone until a score comes back.

I suppose you mean "has to do the Senderbase lookups..." Yes, I hadn't thought of that. Or you could turn it around and do the SBRS lookup on the first connection, then TCPREFUSE the connection if appropriate, and BLACKHOLE all further connection attempts. But that does give away the game a bit, since it lets the spammer know that you were alive long enough to accept the first connection.

The real problem here is with the BSD socket API. You must accept a connection (that is, finish the three-way handshake, even if you RST it immediately thereafter), before being able to call getpeername(). This isn't a requirement of the protocol, since the remote IP address is available in the initial SYN. It's just that the socket API doesn't let you get to it that early. (Aside: DEC modified the socket API slightly for their Ultrix implementation of DECnet, allowing accept() to return without completing the connection so that you could use getpeername() before accepting the connection. You'd then use some other socket call to complete or refuse the connection.)

The moral of the story is that on average sending MTA will attempt to retry 39 times when presented with a TCP Refuse.

I don't care about the average sending MTA, I care about spambots. You say that they are starting to retry now (that response to greylisting was inevitable). How aggressively do they retry? They're the only ones that really matter here since I only TCPREFUSE really bad actors.

[jbivens_ironport]

I don't care about the average sending MTA, I care about spambots. You say that they are starting to retry now (that response to greylisting was inevitable). How aggressively do they retry? They're the only ones that really matter here since I only TCPREFUSE really bad actors.

I personally didn't perform that research, however it was entirely based on TCP refuse action which was either done at either -2 or -4 to -10, which is where the 39 retires number came from, but keep in mind that this was the average. I'm not sure if this qualifies as the spambot ilk that you were looking for but it should be helpful.

If you wanted to do a little experimenting, change to SMTP Reject for a day and then check out your stopped by reputation filtering numbers (and the weekly graph)...they will go down into the dirt because you don't have nearly as many retries coming into the system.

There is basically this huge demand of sending MTA's that really want to talk to the IronPort, which have built up over the past three days (based on typical bounce profiles) and they're all having a performance impact on your IronPort appliance. Most of these TCP stats never register (besides stopped by reputation filtering) with regards to inbound/outbound connections because they are turning over in milliseconds.

Sincerely,

Jay Bivens
IronPort Systems

[Donald Nash]

If you wanted to do a little experimenting, change to SMTP Reject for a day and then check out your stopped by reputation filtering numbers (and the weekly graph)...they will go down into the dirt because you don't have nearly as many retries coming into the system.

I'll have to give it a try, but it does surprise me. Why should spammers respect an SMTP rejection any more than a TCP rejection?

[Donald Nash]

If you wanted to do a little experimenting, change to SMTP Reject for a day and then check out your stopped by reputation filtering numbers (and the weekly graph)...

OK, I did that and it didn't make any significant difference, either for better or for worse. I can't say that I'm surprised. I'm not going to go to the effort of changing back because it didn't hurt anything, so clearly trying to hide by pretending not to have an operational SMTP server didn't do any good. And this way, I can give a rejection notice to the servers that have been manually blacklisted.