How to include intranet servers to spam tests - ORF Forums

How to include intranet servers to spam tests RSS Back to forum


I want to include some intranet servers to spam tests. Now ORF whitelist all mail from intranet with log: "email whitelisted (email from a trusted intermediate host or intranet)".
My servers ip is, and emails coming from server, but it is not in my ip excetions.
I want to test incoming mail with dns reverse test - how i can do it?
ORF ver 4.4 (enterprise)

by A7exius 6 years ago

@A7exius: ORF treats the localhost address ( class A, B and C intranet address ranges as Intermediate Hosts by default (even though these hosts are not indicated on the Intermediate Host List itself: Class A intranet: -, Class B intranet: - and Class C intranet: -, therefore emails originating directly from these addresses are always whitelisted. This behavior aims to exclude internal and outgoing emails from filtering to avoid false positives, and cannot be overridden by any manual rule. For more information about the Intermediate Host List, see the related help topic at

For testing I recommend sending emails from an external host, or creating a loopback network interface with an APIPA IP address, and sending emails through that (e.g., by telnetting to port 25). For instructions, please see my related blog posts at

by Krisztián Fekete (Vamsoft) 6 years ago
(in reply to this post)


It is sad...
May be LAN ranges will move in the next version OFR into IP white list tab?
It is add flexibility to ORF.

by A7exius 6 years ago

@A7exius: That is unlikely to happen, sorry. ORF is designed to filter incoming emails only, and even if we add some functionality in the future to filter internal/outgoing emails (, the related settings will be separated entirely (i.e., it is unlikely that you would want to apply the same rules to incoming, outgoing and internal emails).

For incoming emails, hosts with internal IPs may act only as relaying hosts in between the original sender and your Exchange server with ORF installed, hence they are treated as Intermediate Hosts.

by Krisztián Fekete (Vamsoft) 6 years ago
(in reply to this post)


This is sad indeed and Vamsoft specialist is wrong! He's either not aware of Exchange connectors interconnection or forgot that.
WE NEED to be able to include private ranges to testing!
My primary MX - everything perfect.
Secondary MX (mail relay only) in other country connected to primary MX with site-to-site VPN so it's network only inside.
On secondary MX, when frontend connector gets the mail, it checks "before arrival" events and then immediately send it, due to internal Exchange mail flow routing, to the primary server's HUB connector, there, on the primary server, ORF looksup that mail is coming from network and immediately passes it through, skipping all "on-arrival" checks.
Thus is we have distributed network and multiple MXs and if we're using private ranges (which can't be changed obviously throughout organization) then ORF will be working only in one location. Which is very much sad, for example SpamTitan (the other one we were testing) doesn't have such artificial limitation! Please advise, as i really love ORF.

by marvinfs 1 year ago

@marvinfs: Hello MarvinFS,

I believe you are commenting on an issue that is different from what Krisztian was addressing in his posts. His posts are about how ORF handles emails that 'originate' from intranet servers (i.e. internal messages) - as brought up by A7exius.

If you check the ORF logs of your primary MX, I am quite sure that you will find a different whitelist message as well recorded for the emails coming via your secondary MX: "Whitelisted authenticated session, type: organization.", instead of "email whitelisted (email from a trusted intermediate host or intranet)".

ORF logs “Whitelisted authenticated session, type: organization” if Exchange detects that the email is coming from a trusted Exchange receive connector, from someone inside the organization (not necessarily the local server, but someone belonging to the wider organization). In your case, the problem seems to be that your primary MX's Receive connector, that accepts emails from the secondary MX, has authentication enabled. Thus, all emails that are received from the secondary MX are considered trusted and excluded from filtering. This can be confirmed by checking the Exchange connector logs if needed. The fix in this setup is to configure the primary MX's Receive connector not to trust the emails coming from the secondary MX -- similarly to internet emails.

Please let me know if this has helped.

by Daniel Novak (Vamsoft) 1 year 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