09-06-2006 09:00 PM
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
09-07-2006 02:44 PM
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
09-07-2006 11:39 PM
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.
09-08-2006 05:27 PM
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.
09-11-2006 03:40 AM
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.
09-18-2006 07:13 PM
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.
09-18-2006 07:20 PM
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.
09-19-2006 01:20 PM
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.
09-19-2006 02:26 PM
Bouncing can become very expensive, or not.
09-19-2006 05:28 PM
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: ).
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide