TCP Refuse or Reject ???

[chuntmd_ironport]

Which is better for your "always block" group? I want to prevent spam coming in the 3rd MX and the sender seeing that it is being blocked so they resend to the 2nd MX and on to the 1st MX.

CH

[Erich_ironport]

A TCP Refuse does not allow you to give a SMTP error response, it is just not accepting the connection period. So the sender may assume your system is down, or a network error occurred. Like not answering the phone, they don't know they shouldn't call back. But TCP Refuse is less overhead on your end than answering and saying "no I don't want to talk to you".

If you do a SMTP Reject you can give a 5.x.x response stating due to a negative senderbase reputation score SMTP connections are not being accepted from their IP address, etc. The successful SMTP connection and 5.x.x reject should cause the message to be hard bounced and not be retried. Spammers don't follow the rules, so no promises here.

I find the SMTP Reject is helpful on your end, if you have to troubleshoot a vendor/partner/customer delivery problem. Because you can add useful information as <$variables> to the SMTP reject message, like IP address. So when the end user "customer" sees the bounce/reject message they have info like which IP address it was that attempted to send to your IronPort, etc.

Because of the ability to give custom rejection responses, in the range that we throttle (both for questionably negative SBRS and for mis-configured DNS) we use two separate SenderGroups for these so we can give different responses for the different reasons we throttle. If the problem is a DNS issues that is what the error says, if the problem is a negative SBRS that is what the error says. We throttle on SBRS first in priority.

Erich

[shannon.hagan]

Just be careful though - if you put your phone number in the banner, you can get some very interesting phone calls. Putting in something like:

The ip address ($RemoteIP) is currently blocked. Please contact your isp. If you are the isp, you may send a message to postmaster@yourdomain with the following subject: "Blocked IP: $RemoteIP" to find out why you are being blocked.


Now - reading is a fine art and some will put other subjects; however, you can do the ones that are putting in the correct subject first.

[Donald Nash]

I want to prevent spam coming in the 3rd MX and the sender seeing that it is being blocked so they resend to the 2nd MX and on to the 1st MX.

We approached this from a totally different angle. We've abandoned the whole idea of multiple MX records of different weights, since it's just more places for the spammers to attack. Instead, we now use a NetScaler load balancer as a front end for our farm of MGAs. And although we aren't using it here, NetScalers have a feature called "Global Server Load Balancing" that lets you have both NetScalers and server farms in geographically separate locations, providing the kind of physical reliability that multiple MX servers in separate locations provide.

I'm not shilling for NetScaler (actually Citrix now), and I expect that other load balancers have a similar feature. NetScalers just happen to be what we use.

[tminchin_ironport]

yeah - we gave up backup MXs too.

We just have two MXs which are in different network locations - we let DNS and SMTP figure out how to get there in case of difficulties. Both MXs have access to our address list so we can engage DHAP.

[Corey_ironport]

In our experience, Bouncing everything below -2 is the best way to go. For a while, there, we were TCP Refusing everything below -7. We noticed, though, that the same IP addresses were constantly hitting us over and over after we TCP Refused them. It seems that when you cause their server to create an NDR, they don't retry. Otherwise, they retry...and they retry a lot.
On our reject banner, we simply have our postmaster address. No phone numbers or anything like that. If it's a legit company being blocked, their mail admin logs into his Yahoo or gmail account and sends us a message. We have that happen once or twice a month.

[Donald Nash]

In our experience, Bouncing everything below -2 is the best way to go. For a while, there, we were TCP Refusing everything below -7. We noticed, though, that the same IP addresses were constantly hitting us over and over after we TCP Refused them. It seems that when you cause their server to create an NDR, they don't retry. Otherwise, they retry...and they retry a lot.

I don't mind them beating their sorry heads against our brick wall. The more time they waste throwing useless connections at us, the less time they spend spamming others. TCP refusals are cheap, and so is our log space.

[lucas.castro_ironport]

In our experience, Bouncing everything below -2 is the best way to go. For a while, there, we were TCP Refusing everything below -7. We noticed, though, that the same IP addresses were constantly hitting us over and over after we TCP Refused them. It seems that when you cause their server to create an NDR, they don't retry. Otherwise, they retry...and they retry a lot.
I don't mind them beating their sorry heads against our brick wall. The more time they waste throwing useless connections at us, the less time they spend spamming others. TCP refusals are cheap, and so is our log space.

agree with dlnash. Bouncing can become very expensive, or not. But this is just not the case. Doesn't matter, cause tcp refusing is so damn cheap to us...

[Donald Nash]

Bouncing can become very expensive, or not.

In Corey's defense, he meant conversational bouncing, i.e. returning a 5xx error in the SMTP transaction. This causes the sending SMTP to generate a bounce message. Most of the effort is therefore on the sender's side. Of course spambots don't generate bounces, but according to Corey they still get the message and give up on that address.

Doing conversational bounces is not very expensive since nothing gets into your mail queue, but it is quite a bit more expensive than a TCP refusal. But it might be arguable that a single conversational bounce is worth the number of TCP refusals that it would avoid. Who knows?

I've suggested this before, but now seems like as good a time as any to repeat myself. I want a new HAT action: BLACKHOLE. You'd use it in the same context as TCPREFUSE, except that it would ignore the incoming SYN segment instead of sending back a RST. As far as the bad guy is concerned, you wouldn't exist at all.

[Corey_ironport]

Thanks Don. That's exactly what I was getting at, and to be honest, we've actually witnessed a performance gain since we made the change. Maybe it was coincidence, but we've done about 100k (600k-700k total) more emails in the past few weeks than we were doing before, and our appliances aren't working as hard. Granted, we've also upgraded to 4.7 in that time. So again, call it coincidence or a product of the 4.7 upgrade if you want. Historically, most AsyncOS upgrades (thanks mostly to Brightmail), have caused performance to degrade, not improve.
The other benefit is personal preference. I personally like cleaner logs (It's my OCD :lol: ).