Server Bindings - ORF Forums

Server Bindings RSS Back to forum

1

We have a FE/BE exchange enviroment with two servers. We recently had a disaster recovery event, and a lot of the configuration was lost including ORF. Long story short, emails were coming in through the front end with ORF but outgoing were directly going from the back end exchange server. To fix this I went into the virtual stmp server of the back end exchange server and added the front end as a smart host. This fixed the issue that all email is now going out through the front end server.

This issue is that ORF on the front end server is treating the back end server email as inbound. For example if I turn on directory harvesting, it will block my users after 3 outgoing emails that they send. Other similar events indicant that I've either setup the forwarding incorrectly, or something is not correct with the ORF binding. Any help is appreicated.

Thanks

Aaron

by Aaron W. 9 years ago
2

@Aaron W.: Indeed, ORF does not really have concept of "inbound" and "outbound" emails - technically, all emails that arrive on SMTP are inbound.

There are multiple ways to fix this issue, but the easiest is to set up another SMTP Virtual Server on the FE server, listening on e.g. port 2525, accepting connections only from the BE server, then reconfigure the BE server to forward to port 2525 on the FE. Then, start the ORF Administration Tool and configure it to filter emails on your inbound SMTP Virtual Server and check for outgoing emails (for the Auto Sender Whitelist) on the outbound SMTP Virtual Server.

Another alternative is to add the BE server IP to the IP Whitelist of ORF, but that is a change easier to forget about.

by Peter Karsai (ORF Team) 9 years ago
(in reply to this post)

3

Thanks Peter, I'll look at that when I get into work. As a follow up question, is this something that is naturally inherent in FE/BE environments, meaning do most people with FE/BE environments need to do this?

I am curious to know if my FE/BE environment is somehow setup incorrectly, and if I should addresses that first. I don't remember ever needing to do this in my previous environment which was also FE/BE, but that was setup over the course of years.

Thanks

Aaron

by Aaron W. 9 years ago
4

@Aaron W.: It is inherent in FE/BE environments, but there are multiple factors in play, so not everyone may have to setup specifically for this. In some cases,

- ...it is the BE that acts as outbound server,

- ...the FE in the DMZ "sees" the intranet IP of the BE server and all emails originate from the intranet (as far as ORF is concerned), so ORF's All-Intermediate-Host whitelist rule kicks in. This rule says "if all delivery hops in the email delivery history are on the Intermediate Host List of ORF, the email is coming from a trusted source and hence it is whitelisted". As all Class A, B and C intranet addresses are considered part of the Intermediate Host List, this rule is usually enough whitelist all outbound relaying,

- Under Exchange 2007/2010, the Edge Transport/Hub Transport communication is whitelisted by the connector authentication.

Peter

by Peter Karsai (ORF Team) 9 years ago
(in reply to this post)

5

Peter I went with the option to add the BE to the intermediate hosts. In fact I added our entire subnet to the list. Is this correct? The wording is confusing to me, it says "Add the hosts (or networks) to this list which may receive your incoming emails first and then relay them to your servers. These hosts are typically secondary mail exchanges or front-end servers." It could very well be the lack of sleep that is causing me not to understand, but to me the wording appears to be front end immediate hosts like ISA servers or other mail filtering devise.

Also, I'm still seeing our internal domain email accounts being added to the auto sender whitelist. I've gone into the auto sender settings and added our domain to the sender exceptions, but it is unclear to me why this occurring.

Thanks

Aaron

by Aaron W. 9 years ago
6

@Aaron W.: I see my mistake. I didn't add my internal network to the IP Whitelist. Now that I've added it, things are working much better.

by Aaron W. 9 years ago
(in reply to this post)

7

@Aaron W.: Actually, I would rather recommend adding the BE IP to the IP Whitelist of ORF. We are talking about two different mechanisms here:

1) IP Whitelist / List: Will whitelist emails that are coming from IPs listed on the IP Whitelist. Given you do not intend to filter emails from this host, the IP Whitelist is just perfect for this.

2) IP Whitelist / "All-Intermediate" subrule (as outlined in my previous post): Will whitelist the email if all delivery hops in the delivery history are designated as intermediate hosts. Note that the primary role of the Intermediate Host List is to allow ORF to "look behind" your front-ends and secondary MXs in the delivery history to find the actual source IP (hence the wording). It is a sort of design side effect that it also provides information about whether the email is originated from a trusted intermediate host, which allows us to use this convenient subrule. However, we need to whitelist outbound emails here and the definition of "outbound email" and "internally originated email" is not always the same - just think of Blackberry users who may very well send from an external IP address, but via your network. This case will not be covered by the this subrule, that is why the IP Whitelist is a better fit, because it allows you to declare "whatever email comes from my BE server should be excluded from filtering, because the network behind the BE server is secured and trusted.". The second SMTP Virtual Server approach I outlined earlier works equally great, but it also prevents ORF from seeing the outbounding relaying, so you will have lesser noise in the ORF logs and I think it's a more self-documenting setup than an IP Whitelist entry.

As for internal emails being added to the Auto Sender Whitelist, that is a whole different issue. Under pre-Exchange 2007 versions, ORF monitors the outgoing SMTP connections to collect the sender/recipient information. When you relay emails back to from the FE to the BE server, your server makes outgoing SMTP connections, so ORF will happily collect ASWL data of these connections. What you need to do is to add the BE server IP to the IP Collection Exceptions of the Auto Sender Whitelist. By default, this list includes intranet IPs, but your BE server obviously communicated with the FE by a public IP, so you need to explicitly tell ORF your BE address. A full cleanup of the Auto Sender Whitelist database is strongly recommended (there is an alternative to that, see http://www.vamsoft.com/howto-blacklist-self-spam.asp#whitelist-issues).

by Peter Karsai (ORF Team) 9 years ago
(in reply to this post)

New comment

Fill in the form below to add a new comment. All fields are required. If you are a registered user on our site, please sign in first.

It will not be published.
hnp1 | hnp2