Outgoing Accept Query?

Unanswered Question
Mar 11th, 2009
User Badges:

We are near the end of a e-mail system consolidation project. About 25 independant e-mail systems into one Exchange 2007 environment. I am in the process of cleaning up our SMTP traffic from all those systems and domains. With all of the e-mail address changes to the new single domain we do have a high amount of bounces due to bad addresses. I recently implimented LDAP acceptance queries on inbound e-mail for our new domain. My question is, is there a good way to do something like LDAP acceptance queries for outbound e-mail? All of our legacy e-mail systems use our IronPort infrastructure as their smarthost. So, a lot of e-mail that is still being generated by our old systems (hard to kill those things gracefully) is being accepted into IronPort on a private listener but is actually sent to a bad address so it just needs to be bounced back. Rather than accept that mail on IronPort I would like to do sometype of LDAP acceptance query but see that on Private Listeners Accept Queries are not available. Any suggestions?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Deadun_ironport Fri, 03/13/2009 - 13:35
User Badges:

Would it make sense to put in a higher rated incoming content filter that deals with all email to the domain addresses you no longer want to receive for?

Conditions (if any match)
Recpient address contains = old domain1
Recipent address conatins = old domain2

Then set the action to bounce?

These will be bounced leaving the inbound ldap accept (at a lower filter number) to mop up the non-existent addresses?

Or reverse this, if I'm reading it incorrectly (probably am, not enough coffee yet today!). Have a bounce actioned Outbound content filter checking the Sender address contains field?

Just a thought :)

Jason Meyer Fri, 03/13/2009 - 21:31
User Badges:

What I am trying to block is e-mails directed to non-valid addressess on our new domain. One of the IronPort gurus advised me to use a content filter and the active directory group "Domain Users" to test for valid addresses. I'm in the process of building that right now....

Thanks for the input and long live the Iron Nation!

Donald Nash Thu, 03/19/2009 - 17:48
User Badges:

The problem with using a content filter is that you generate bounces rather than rejecting the message at SMTP time. If that's OK, then go with it. If not, then read on...

I've been thinking about a rather unorthodox idea that might work to give you LDAP acceptance queries in this context. I assume that you're using a private listener to implement your smarthost address. Private listeners lack the Recipient Access Table and all that associated recipient control baggage. You may be able to use a public listener instead. You'd need to replace the Host Access Table completely, since public and private listeners have very different HATs. But you'd then be able to do recipient verification. You'd also need to be careful with the RAT, since the default is to reject recipients not in the RAT (you can change that).

I haven't thought this all through, so I don't know if it will work. I know there will be some pitfalls. For example, this traffic will show up as "inbound" rather than "outbound" because it will be matching an ACCEPT rule rather than a RELAY rule in the HAT. That means, among other things, that your inbound content filters will apply rather than your outbound ones. And you won't be able to do Domain Key signing. But still, it may be worth investigating if you want to avoid generating bounces.

kyerramr Thu, 03/19/2009 - 18:39
User Badges:

If you plan to do outbound LDAP validation then this can be done by using a public listener, however you would need to create a new server profile with an accept query set with variable {f} instead of {a}. This will check for mail from address validation.

However, you would need to modify the HAT of your new public listener to get this going, delete all the sender groups in the public listener HAT and create a new sender group for relaylist set all to reject.

This should work fine with sender verification and the messages will still be treated as outgoing since they match RELAY policy and outbound policies.

Donald Nash Thu, 03/19/2009 - 19:01
User Badges:


This should work fine with sender verification and the messages will still be treated as outgoing since they match RELAY policy and outbound policies.

A RELAY policy bypasses the RAT. Does it also bypass recipient validation? Your statement implies that it does, but that would surprise me.
kyerramr Fri, 03/20/2009 - 17:25
User Badges:

True, RELAY policy bypasses RAT. This is an ideal setup with one listener doing both incoming and outgoing. However in this posting we need to use a new listener which would be a public listener (delete all SG's except RELAYLIST in the HAT) and apply the new LDAP accept query to this listener.

Since this new LDAP accept query would do sender validation, recipient validation would not occur.

Donald Nash Fri, 03/20/2009 - 17:48
User Badges:

So LDAP acceptance queries happen even on RELAY policies? Wow, that surprises me. I figured that since the whole point of RELAY policies is to avoid any sort of recipient checking, that this wouldn't be the case. Very interesting.

staylor_ironport Thu, 03/26/2009 - 22:16
User Badges:

[quote="dlnash"]So LDAP acceptance queries happen even on RELAY policies? Wow, that surprises me. I figured that since the whole point of RELAY policies is to avoid any sort of recipient checking, that this wouldn't be the case. Very interesting.

DLNASH is actually correct, if you use a RELAY action within a MFP on a public listener recipient verification is skipped, so using this as part as a sender verification setup would totally defeat the point.
You do need to use a MFP with an ACCEPT query and alter the RAT accordingly (Basically allow all) this will then still enforce the LDAP sender verification and do exactly what you are looking for.

Regards

Actions

This Discussion