incoming relays question

Unanswered Question
Mar 25th, 2008
User Badges:

Guys , we deploy singe Ironport at customer location . Ironport is a primary mx , where local isp is a secondary mx , and we are getting lot of spam via secondary mx . I defined secondary mx in the incoming relays and able to see bad sbrs scores on the log , but now how should I block it ? in the content filters or the policy ?
thank's for answer

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Eduardo Almeida Wed, 03/26/2008 - 14:58
User Badges:


Do you send the messages from ISP to IronPort? If yes you can create a message filter dropping all messages with low SBRS scores.

Eduardo Almeida

Donald Nash Wed, 03/26/2008 - 15:07
User Badges:

I'll let someone else address your question directly, I'm going to offer a different take on the matter. Get rid of the secondary MX entirely. They're more trouble than they're worth, and they don't really gain you that much extra reliability. They're a back door for spam to leak in through, and as such they are purposely attacked by spammers. And even if you successfully filter out the spam, you'll be doing so the hard way because you'll be throwing away messages that you've already accepted rather than refusing them entirely based on bad SBRS scores.

We've been running without backup MX servers for years with no problem. Then again, our infrastructure is a little more built out. We have a server farm of IronPort units with a high-availability pair of load balancers in front of it. That makes us pretty much immune to single-server failures, although a power failure or network outage could still take us down. Still, how bad is that really? If we have a failure that bad, we're going to have more important things to worry about than just our e-mail (such an outage would take down lots of other stuff), and our incoming mail will simply sit on the sending servers until we come back up. If we're down long enough for those servers to give up and bounce the mail then we really do have more important things to worry about.

denisp_ironport Wed, 03/26/2008 - 22:34
User Badges:

Guys , thank's for answers , can you still help us to write filter for incoming relays to be detected by sender group ....

staylor_ironport Wed, 03/26/2008 - 22:43
User Badges:

Firstly create a Sendergroup at the top of your HAT called "IncomingRelay" and add the IP address of your secondary MX in there.
then you can create a message filter that would pick up on the connection being entered into the sendergroup and the senderbase score being below -2.1 for example.

Message Filter would be something like:

if ((sendergroup == 'IncomingRelay') and (reputation <= -2.1))

you might want to alter the name of the Sendergroup and possibly the senderbase score, but the above filter will do the trick, basically anything that has been dropped by your default HAT settings will not get this far anyway, and anything classed with the Incoming Relays will be dropped by the above filter.

Also with Incoming Relays you lose the ability to Throttle connections and messages

staylor_ironport Wed, 03/26/2008 - 23:02
User Badges:

The Sendergroup that should only have the IP address of your secondary MX and not using SBRS, should have a Mail Flow Policy of accept, this is because we don't know if the mails are going to be good or bad.
So we accept the mail for now (You can apply some throttling if required, but bare in mind if the secondary gets a backup of mail and then suddenly delivers to you!!!! could cause probs)
Then the message filter will look at the reputation score because your incoming relay has looked back and found the originating IP address and retrieved the senderbase score for the message.
So all you can do is drop mail with scores lower than -2.1 and allow everything else through.

Hope this helps


This Discussion