01-19-2006 06:51 PM
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
01-23-2006 04:09 PM
We throttle between 0 - (-2) and block all below -2
01-24-2006 04:59 PM
We throttle between 0 and -4.9 and block -5 to -10.
01-24-2006 10:40 PM
Bet you wouldn't be doing that if you had to put up a phone number do they could call you to find out why they are blocked.
The company I work for :
TCP Refuses for -7 to -10
Puts in the banner to send a message to postmaster for -2 to -7 (used to have a phone number but it recently got removed due to the abuse)
Really throttles 0 to -2
And throttles all other traffic to a reasonable number
01-25-2006 09:17 PM
Whats the different between Reject and TCPREFRUSE?
Why would I choose one over the other?
-Matt
01-26-2006 12:38 AM
A TCPREFUSE simply rejects the connection- no SMTP banner, no error message, etc. To the naked eye, it will appear as if the remote mail server is completely down.
The "Reject" behavior actually allows a connection to be established before sending an error message via SMTP (4xx, 5xx) and disconnecting. Since a rejected sender can use the error message to gain some insight into why they've been blocked, this method is usually preferred.
-Jason
01-26-2006 07:40 PM
We block everything below -2 and throttle between 0 and -2.
Mike
01-27-2006 07:32 PM
Speaking of TCPREFUSE vs REJECT, I'd like to see a third option: BLACKHOLE. This one would throw the incoming SYN on the floor, making it look to the attempted sender like the entire server is dead. If the idea is to provide the least amount of information possible to a would-be attacker, not even letting him know that you're alive would be best. It also means he has to wait for the connection attempt to time out, which costs him time. I'm sure that spammers use short timeouts to foil this sort of passive attack, but every little hindrance helps.
02-02-2006 07:57 AM
Speaking of TCPREFUSE vs REJECT, I'd like to see a third option: BLACKHOLE. .
02-02-2006 02:21 PM
How do you implement this? there's no blackhole option on the mail flow policy.
02-07-2006 07:39 AM
I'll play devil's advocate.. are there any other ways that a BLACKHOLE would be better/different from a TCPREFUSE? I understand the part about the SYN being dropped on the floor - but the end result is still the same (no TCP connection; do not pass go, do not collect $200).
Since spammers generally obtain IPs from a domain's MX record at least once (in other words, you're advertising the fact that you run a mail server on $x IP address), what's the advantage of "playing dead" when you can make it known (at layer 4) that you don't want their traffic? Seems like playing dead would cause them to retry, where an outright TCP refusal might not.
I do like the added advantage of forcing them to wait for a timeout - depending on the number of domains a spammer is sending to, those could add up.
02-07-2006 01:20 PM
You have to be careful, if your doing network load-balancing to multiple IronPorts the "BlackHole" effect can really mess with some load-balancers. And he has a point, your MX record is out there, you can only hide so much. :?
Don you got my vote for best MX record names!!! You got love those names :lol:
its.utexas.edu. MX ironfist.mail.utexas.edu. [Preference = 10] its.utexas.edu. MX ironmaiden.mail.utexas.edu. [Preference = 10] its.utexas.edu. MX ironman.mail.utexas.edu. [Preference = 10]
02-07-2006 04:03 PM
Since spammers generally obtain IPs from a domain's MX record at least once (in other words, you're advertising the fact that you run a mail server on $x IP address), what's the advantage of "playing dead" when you can make it known (at layer 4) that you don't want their traffic?
You have to be careful, if your doing network load-balancing to multiple IronPorts the "BlackHole" effect can really mess with some load-balancers.
Don you got my vote for best MX record names!!!
02-07-2006 05:07 PM
How many of us have seen spammers repeatedly banging their heads against the wall of TCPREFUSE or SBRS rate limiting?
02-07-2006 07:22 PM
Interesting - so you're getting hit by spammers who keep retrying after being TCPREFUSE'd? Could the connections be coming from a poorly configured (legitimate) MTA, or are you sure they're from spammers?
Count IP Address Host
------ -------------- -------------------------------------------------
122517 221.189.115.48 p16048-ipbffx02marunouchi.tokyo.ocn.ne.jp
122287 65.222.147.130 system130.VOBAutoSalesBMW.com
96216 201.152.87.217 dsl-201-152-87-217.prod-infinitum.com.mx
94282 68.163.223.223 pool-68-163-223-223.bos.east.verizon.net
76931 66.74.166.80 cpe-66-74-166-80.socal.res.rr.com
57106 220.119.138.107 No PTR record; address belongs to Korea Telecom
56831 69.155.94.109 adsl-69-155-94-109.dsl.rcsntx.swbell.net
56383 201.24.228.73 201-24-228-73.ctame704.dsl.brasiltelecom.net.br
55590 68.234.70.9 londonderry-cuda1-68-234-70-9.lndnnh.adelphia.net
54846 141.154.209.79 pool-141-154-209-79.bos.east.verizon.net
In the past, I haven't noticed behavior like that coming from actual spammers.. I figured they wouldn't want to take a chance on drawing attention to themselves.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: