Do you use separate inbound and outbound setup?

[mychrislo_ironport]

I think my question is really, do you use this setup and also see a "short-circuit" issue.

I have my ISP running C660 cluster serving for incoming mail. The incoming mail feed to "inbound" listener. aka PUBLIC listener.

I have also setup my C660 private listener as outbound. This listener ride on the IP network's default gateway NIC interface.

The incoming mail flow come from natural DNS MX lookup and reach the inbound interface. The inbound interface, after all sort of smtp validations, will forward to my core messaging server for storage. This is done by _SMTP_ROUTES_ under the C660.

My Question:
- Do you use this setup?

- Do you see short-circuit behavior in ONE very particular case, where, the outgoing outbound listener relay an email for your _VERY_ own domain. It will use the SMTP_ROUTE to immediately deliver the message to my core messaging server, without going thru the antispam, antivirus feature? Even ldap recipient verification seems bypassed.

(note: smtp_routes does not differentiate inbound / outbound listener, it is a gobal setup)

Thanks.
Chris

[Bart_ironport]

Using the same devices for both inbound and outbound mail is a very common setup. I never really had a problem with the "short-circuit" issue, in most setups the internal email is handled by the groupware servers, it never reaches the ironports, so there is no difference here.

Its not that the messages are not scanned, but they only pass through the outgoing mail policy, not the incoming. So if you want to perform spam scanning here, you need to do so in the outgoing mail policy. If you also want to use inbound content filters, this can become a bit difficult.

I can see this being an issue for providers, where "internal" mails aren't trusted. The larger ones I know do run separate clusters for inbound and outbound mail, which is the most logical setup for their use case.

[Andrew Wurster]

chris -

like bart suggested, check your mail flow policies. by default, most people give "outgoing" mail a "relay" connection behavior by way of the "relaylist" sender group in your HAT. this bypasses recipient checks in your RAT and bypasses anti-X scanning by default.

as always, start with your mail_logs. include them here and we can help point out things in detail as needed.

andrew

[mychrislo_ironport]

The difference is, where the mailflow comes from, in most case. people, in a corporate environment, use a mta _server_ to relay to the ironport for outgoing traffic.

In an ISP environment, the mailflow comes directly from end users, end user clients (i.e. outlook, thunderbird, or spambot).

RELAY policy is just very fit for them.

In my very special case, if the client is hostile, sending spam and virus back to my very domain. So I need it to be scanned.

Yes, I can do AV in the outbound and I should.

For AS; outbound, I do NOT tag or drop my any spam. It is merely a detection mechanism

For AS; inbound, I can tag or drop the spam messages depends on recipient COS.

So, I only want to do it from inbound listener. and I already have that in my inbound listener. There are a bunch of inbound policies that would NOT fit for outbound purpose. E.g. DHAP limit, max rcpt for hour, or even SBRS check.

I dont get it why I the message flow isn't going thru the inbound listener...

If there is a need for a message filter. I can try

[Donald Nash]

Chris,

I think you're seeing mail for your own domain arrive via the outbound listener because your clients are configured to dump all their mail there. Unless I'm misunderstanding you, it sounds like you're asking for something like this from your clients: "Route all your outbound mail to the Outbound server unless it is for our domain, in which case just follow the MX record." That's typically not how relay clients operate.

You can use outbound policies to correct for this, simply by checking for recipients which match your domain and then subjecting them to the same tests that you use on the Inbound side. You may not even need to use a message filter, just create a policy.

Incidentally, we use this "short-circuit" feature deliberately here. All units in our cluster are identically configured, and we have "Inbound" and "Outbound" listeners with different policies. Clients within our "protected perimeter" get to use the outbound listener. We have load balancers in front of our cluster, and they're configured to route inbound and outbound traffic to separate units. That way, if our inbound defenses get overwhelmed by a massive traffic spike, then our internal traffic is unaffected.

[mychrislo_ironport]

Hi Don,

That's an good idea. let me try.

Chris