Validating internal recipients on internal listener

[T Mac]

For some strange reason, the ESAs specifically do not allow recipient validation on an INTERNAL listener. Can anyone suggest a way in which we can do this?

We have an Exchange server environment as well as a number of non-Exchange hosts sending mail via the ESAs to internal and external recipients. The ESAs accept mail to "example.com" and all subdomains, and all "example.com" recipients are Exchange recipients, at this stage. We do LDAP validation of the recipients for the external listener.

Problem:

Quite frequently, an internal non-Exchange host will send a message (such as a system alert) to a former Exchange recipient. The message naturally makes its way to an Exchange server, where it gets bounced.

This is annoying enough (that we can't do the same recipient validation that we do on the external listener in the first place). But we also have a number of "noreply@system.example.com" senders, which can't accept these bounces (i.e. the sending host is not an MTA and does not receive messages).

The sender never gets an error about their out-of-date recipient, because we've accepted the message and bounced it later (and the bounce can't be delivered). We would prefer giving them a nice "5xx" error that would appear in their maillog.

Solutions?

To stop this messy situation, I presume we need to create a new outgoing mail policy to target mail for "@example.com" recipients. How can we:

• Bounce messages to invalid recipients based on our LDAP lookup?
• Ensure we can cater for recipients in our LDAP lookup AND for named hosts? We may end up with some non-Exchange systems accepting mail as "mta-host.example.com", and we'd expect that to handle bounces for "invalid.recipient@mta-host.example.com" (or maybe we'd want to so something like an SMTP call-ahead).

Another solution would be to create another "External" listener, perhaps? And direct our non-Exchange senders to use that one. I must say that creating an "External" listener for internal senders would be a bit frustrating. Configuring it so that the behaviour to deliver to actual external recipients is the same as it is now (not to mention advising hundreds of system owners of this change) would be a bit onerous at this stage.

Suggestions of how to handle this as neatly as possible are welcome!

[Libin Varghese]

The "RELAYLIST/RELAYED sendergroup/policy" by default doesn't get validated by LDAP because it is meant to handle outgoing mails to the internet which doesn't require any validations at all.

If you are looking to validate recipients for emails being generated from a particular server, that server IP should not be part of a RELAYED sendergroup/policy.

Since you have a multiple listener setup, I would recommend configuring the exchange server generating the email to inject emails to the public listener for internal domain destination and to the private listener for the external domains.

Originating server to internal domain example.com -> Public listener -> IP matches non-relay sendergroup -> RAT validating by LDAP
Originating server to external domain gmail.com -> Private listener -> IP matched relay sendergroup -> No RAT validation

I would not recommend using filters, because it’s not necessarily cleaner to do in a filter. The limitation for LDAP matching message filter rules that that they apply to the entire message if one recipient matches.

Below is a snippet from the Online Help, located in the Help and Support menu in the upper-right hand corner of the WebUI, regarding how this works.

Envelope Recipient in Group Rule
…
Note The rcpt-to-group rule is message-based. If a message has multiple recipients, only one recipient has to match the rule for the specified action to affect the message to all recipients.

The closest thing in a message filter would be to use –

if not (rcpt-to-group == 'GroupWithAllUsers') {}

Please be sure to read through the User Guide section “Using Message Filters to Enforce Email Policies” to make the necessary adjustments so this fits with the rest of your configuration.

http://www.cisco.com/c/en/us/support/security/email-security-appliance/products-user-guide-list.html

- Libin V

[T Mac]

It's interesting how different products define the function of a "listener", because my understanding of it is that it defines where the message is originating FROM, not necessarily its destination.

For me an internal listener is for messages originating from internal hosts that are permitted to RELAY (to any or specified destinations). It doesn't say it's an "internal listener for outbound traffic only", although I suppose that's implied by the ESA's lack of capabilities.

For other products I'm familiar with, if the recipient is also internal, mail that arrives via an internal listener is still injected into the inbound queue and handled according to policies defined there.

Ignoring all the stuff about Exchange, how would the ESA handle a scenario where it's acting as a mail hub for multiple internal recipient hosts?

For example, will mail will be delivered to Server1 if it's "recipient@server1" and Server 2 if it's "recipient@server2"?

What happens if "recipient1@example.com" has their mailbox hosted on Server1 and "recipient2@example.com" has a mailbox on Server2? Their destination servers would be defined by a lookup table.

While that's not exactly the same as our scenario, we have internal hosts that are sending to BOTH internal recipients and external recipients and they are connecting to the internal listener to relay their mail. How would a pretend "external" listener help us for these systems that are sending mail to internal AND external recipients?

While I agree that creating a filter rule is completely undesirable, I don't see what capabilities the ESA offers us otherwise.

[Hrvoje (Harry) Dogan]

Just to clarify the terms used, a "listener" on the ESA is simply "an instance of the SMTP server listening on a TCP port". Nothing more, nothing less :) *Direction* of a message is defined by which Mail Flow Policy behaviour the incoming connection hits (if it's "Relay", it will be treated as an Outgoing Message, "Accept" will be Incoming; furthermore, if SMTPAUTH is running on an "Accept" Mail Flow Policy, as soon as the remote peer authenticates, messages they submit will be treated as *outgoing*).

One solution I can think of is the following:

- Add an *internal only* listener where you will allow connections only from trusted hosts, to replace your RELAYLIST sender group

- For that listener, modify the RAT to use "ALL: Accept" (essentially creating an open relay for any successful connections, so be careful whom you open it to) and to bypass LDAP accept and SMTP call-ahead

- All connections to the new listener will now allow relaying, but will be treated as Incoming messages as well. You can add your internal domains in the RAT and *not* bypass LDAP accept and SMTP call-ahead.

The issue here is that it will mess up your reporting (i.e. not showing anything as outgoing, your incoming mail stats will be a sum of incoming + outgoing).

[Hrvoje (Harry) Dogan]

Oh, and to address the mail routing question - this is exactly what LDAP routing was designed for :)