Server Bindings - ORF Forums

@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.

@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

@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).