|Email Plug-in (Reporting):||1.1|
|Email Plug-in (Encryption):||1.2|
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
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.
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.
Speaking of TCPREFUSE vs REJECT, I'd like to see a third option: BLACKHOLE. .
How do you implement this? there's no blackhole option on the mail flow policy.
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.
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]
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!!!
How many of us have seen spammers repeatedly banging their heads against the wall of TCPREFUSE or SBRS rate limiting?
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 126.96.36.199 p16048-ipbffx02marunouchi.tokyo.ocn.ne.jp
122287 188.8.131.52 system130.VOBAutoSalesBMW.com
96216 184.108.40.206 dsl-201-152-87-217.prod-infinitum.com.mx
94282 220.127.116.11 pool-68-163-223-223.bos.east.verizon.net
76931 18.104.22.168 cpe-66-74-166-80.socal.res.rr.com
57106 22.214.171.124 No PTR record; address belongs to Korea Telecom
56831 126.96.36.199 adsl-69-155-94-109.dsl.rcsntx.swbell.net
56383 188.8.131.52 201-24-228-73.ctame704.dsl.brasiltelecom.net.br
55590 184.108.40.206 londonderry-cuda1-68-234-70-9.lndnnh.adelphia.net
54846 220.127.116.11 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.