• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 813
  • Last Modified:

exchange 2003 Inbound Recipient Filtering at smtp level is not working

Hello,

I know this question has been  'answered' before, but I cannot get it to work.

We have a front-end, back-end Exchange setup. Our front-end server is named RAHU and the back-end server is KETU.

Everything is sent from our anti-spam server (JAGANNATH) to RAHU for domain delivery. I have recipient filtering setup and yes, it is enabled on RAHU's SMTP Default Virtual Server.

If I put add an address manually in the recipient filter and send a message to that address, it will return a 550 5.7.1 code - mailbox unavailable - which is correct.  If I send a message to a person not in the domain, but NOT in the manual list, I expect the same behavior. Instead, it accepts the messaage, THEN sends out an NDR. I need it to not accept any e-mail to recipients not in our active directory.

Please help!

Prasad
0
iameye
Asked:
iameye
  • 5
  • 3
2 Solutions
 
MesthaCommented:
If you have an antispam server then that should be doing the recipient filtering. Doing it after delivery is too late. How does your antispam filter deal with the message rejection? Does it try to send it back out? If so you are causing back scatter. Recipient filtering is only effective at the gateway.

If the telnet test doesn't give the right results then I would have to suspect that the change isn't being written to the IIS metabase correctly. As a test, if you enable it on the backend server, and telnet directly, does it work there?

Simon.
0
 
iameyeAuthor Commented:
The anti-spam server opens up a connection to RAHU and asks it if the recipient is good or not. If it receives a 550 5.7.1 code, it stops - if it receives the accept, it goes through its paces (anti-virus, anti-spam, delay filter, dnsbl, etc..), then actually sends the message to RAHU if it passes the tests, otherwise it just deleltes the e-mail.

I enabled it on the back-end server KETU as you said, restarted the smtp default virtual server and telnet'd like you asked. Same exact issue. rpct to gives 550 5.7.1 for the one in the list and 250.2.1.5 for ANY other address with the domain attached to the name.

Prasad
0
 
MesthaCommented:
That would tend to point to the setting not being seen from Exchange.
Deselect the option in Global Settings and then restart System Attendant on all servers. Then enable the Recipient Filtering option in Exchange again.

Simon.
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
iameyeAuthor Commented:
Will try this out tomorrow night.

Prasad
0
 
iameyeAuthor Commented:
Did not work. Checked all the settings. Everytihing is working fine except for the active directory lookup of recipients - again, if I put in an address manually to filter, it does that with no issue - so the setting is working, but just not completely. Neither Exchange server is a domain server, but has contact with the main domain server (global catalog server) on the same subnet. I have no issues using Active Directory tools from the server, so it is able to read my domain active directory. I also read that the recipient filter must be applied on the bridgehead server in the connector that I am using in order for it to work - RAHU is the bridgehead server and, as mentioned, that is where it is applied on its default smtp server. Also tried completely restarting the servers after changes.

Should I try stopping the default smtp and creating a new smtp on RAHU to see if that works?

Prasad
0
 
MesthaCommented:
Recipient filtering the list is done in a different way to filtering for unknown recipients. Therefore you will get a different response from memory.
I have never seen the feature fail, it is always just worked. It is very odd. I don't know what else to suggest.

Simon.
0
 
iameyeAuthor Commented:
Okay, I figured it out!!!! Will enter everything here tomorrow.
0
 
iameyeAuthor Commented:
Alright, realized that the Recipient Policies are tied in with this. Our default recipient policy did not have "This organization is responsible for all mail delivery to this address" checked. In fact, the checkbox was grayed out. We opted to not have dual domains so that is our inside and outside domain.

To get at the grayed out checkbox, I created a second smtp domain such as @temp.com and clicked on 'set as primary'. Now I went in to edit our actual domain and the checkbox was available, which I marked as checked ("This organization is responsible for all mail delivery to this address"). Then I set the actual domain and marked it as primary, then removed the temp.com smtp listing.

Everything worked perfectly after that, even without restarting anything!

Prasad
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: CompTIA Cloud+

The CompTIA Cloud+ Basic training course will teach you about cloud concepts and models, data storage, networking, and network infrastructure.

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now