Frequently Asked Questions

General

  • What are DNS blacklist (DNSBL/RBL) databases?
    The DNSBL (DNS BLacklist) databases collect IP addresses of spammer servers, open relay mail servers, open proxies, spam-supporting ISPs, dial-up lines, etc. that are known or possible spam sources. As their name implies, DNS blacklist databases can be queried using DNS lookups. Often they are also referred as RBL's (Realtime BLackhole) or ip4r databases.
  • What is multistage open relay?
    An open relay is not necessarily a single server, it can be a collection of servers as well. The open relay which consists of multiple servers is called a multistage open relay.

    In a two-stage example, the open relay consists of two servers. Call the first server "A" and the second "B". The first server ("A") accepts mails for relaying from everyone and relays them to server "B", who "trusts" server "A". In this case, it is server "B" which relays the mail to the final recipient. Server "A" is called the input relay and "B" is called the output relay.

    Be careful when filtering for output relays, because output relays can include innocent ISPs (even large ones).
  • Does ORF support Exchange 2007?
    Yes, ORF 4.1 and later versions support Microsoft® Exchange 2007. ORF may be installed for the Hub Transport Server and the Edge Transport Server role.

    Note that the Active Directory-based Recipient Validation feature is not available on Edge Transport servers.
  • Is ORF compatible with Windows Server 2008?
    Full tests with the final Windows Server 2008 release has not been completed yet, but the preliminary results show the following:
    • ORF 4.1 + IIS SMTP on Windows Server 2008 Standard 32-bit: NOT compatible. (IIS ADSI provider problems)
    • ORF 4.1 + IIS SMTP on Windows Server 2008 Standard 64-bit: NOT compatible. (32-bit Event.Manager library is not available)
    • ORF 4.1 + Exchange 2007 on Windows Server 2008 Standard 64-bit: Appears to be compatible.
    • ORF 4.1 + Exchange 2007 on Windows Server 2008 Standard 32-bit: Not supported platform and will not be tested. (32-bit Exchange 2007 is for testing purposes only and not meant to be run in production environments).
    This FAQ article will be updated when the detailed tests are completed.

Configuration

  • Which filtering point shall I choose?
    If you are not sure, we recommend choosing the On Arrival filtering point. It is suitable for most of the ORF users.

    Basically, tests assigned to the Before Arrival filtering point are executed before the email would actually arrive. This time the email contents are not known. ORF versions prior 1.5 performed the filtering before arrival. This filtering point has some limitations, e.g. the only way ORF can identify the sender server is to use the incoming SMTP connection remote peer IP address. Usually this is correct, but if the email arrives via a secondary MX or an email filter proxy (such as an anti-virus gateway), the connection is received from the secondary MX or proxy, so the actual sender server remains unknown and the spam emails may not be recognized by IP-based tests. Also, the only blacklist action ORF could perform this filtering point is to reject the email recipient. Thus, the Before Arrival filtering point is recommended for ORF users who run ORF on the primary MX and have no front-ends or secondary MX'es.

    In contrast, the On Arrival filtering point provides more features, like header analysis, customizable blacklist actions (such as email tagging or redirection) and content filtering. On email arrival, the email contents are known ORF can analyze the delivery path and recognize that the email was arriving via an intermediate host.

    You can assign the tests to both filtering points, in this case the tests are performed twice. Read more about the recommended test assigments in the ORF Help, in section ORF Enterprise Edition / ORF Administration Tool / Configuration / Tests / Tests. This help topic also provides recommended test setups for the various network configurations.
  • Which DNSBL's shall I use?
    It really depends on your intentions. Some DNS blacklists are more effective than the others, but may have a higher false positive rate. To help your selection, we publish DNS blacklist usage and effectiveness statistics on our website which includes user comments. You can also ask for other users's opinion on the ORF newsgroups.
  • Which SURBL's shall I use?
    The best to start with is the SURBL: Combined SURBL list. This SURBL includes all other SURBL lists. If you feel that one of the lists contained by the combined list generates too many false positive hits, you can select the SURBL's separately, excluding the SURBL that you do not want.
  • How do I convert my the evaluation version to the registered version?
    See the Conversion Guide (55Kb PDF).
  • Does ORF work with Exchange 2003/Small Business Server 2003?
    Yes, it does, Exchange 2003 and Windows® 2003 Server are both supported platforms for ORF.
  • Does ORF work with Windows 2003 SP1?
    ORF Enterprise Edition 2.0 and newer versions are fully compatible with Windows 2003 Server Service Pack 1. SP1 installation breaks ORF 1.x versions, however. For more information about this, please visit the Windows 2003 SP1 Issue page of our website.
  • Are there any issues with using (…) anti-virus software and ORF together?
    This depends on the anti-virus software.

    Many anti-virus gateway software (such as McAfee WebShield) works as an SMTP proxy, receiving emails on port TCP/25 and forwarding them to the Exchange server. This may cause issues with the Before Arrival filtering. Anti-virus software also often integrate with Exhange using VSAPI, which does not affect ORF’s filtering.

    The issue you may experience is that emails are not blocked and all emails seem to come from the IP address of the anti-virus gateway. For explanation, see Q: Before Arrival filtering does not seem to work, any ideas?

    On Arrival filtering is not affected by this, so if you experience the issue above, you can choose to use On Arrival filtering only or to install ORF to a front-end server.
  • Can ORF work behind a firewall?
    Yes, ORF can work behind firewalls, but the Before Arrival filtering may be unusable in this scenario.

    Some firewalls behave like a proxy, first they receive the SMTP data and forward that to the server where ORF is running. Before email arrival, the email header is not available, so ORF identifies the sender server as the incoming SMTP connection remote peer.

    When ORF is running on the primary MX and receives emails directly from the Internet (or via a transparent firewall), this address above is the IP address of the sender server. When a proxy or proxy-like firewall forwards the SMTP data, the connection is coming from the proxy and so the address is the proxy'ss address. As many ORF tests use the sender IP address, these tests may not work and ORF's performance may be lower.

    See Q: Before Arrival filtering does not seem to work, any ideas? regarding this.
  • Can I use ORF with Exchange 5.5 servers?
    Exchange 5.5 is not supported directly, but ORF and Exchange 5.5 can work together on Windows 2000/2003 platform.

    ORF integrates with the Microsoft IIS SMTP Service (part of IIS 5/6, also used by Microsoft Exchange 2000/2003) to perform filtering. You can install the IIS SMTP to Windows 2000 running Exchange 5.5, change the listening port of Exchange 5.5 to e.g. TCP/2525, set up IIS SMTP on port TCP/25 and forward emails to Exchange 5.5 on port TCP/2525.

    The Microsoft Knowledge Base Article Q173903 XFOR: Changing the TCP Port Used for SMTP Mail describes how to change Exchange 5.5 listening port.

    Install the IIS SMTP Service and start the Default SMTP Virtual Server on port 25. Set the outgoing TCP port to the port where Exchange 5.5 listens (IIS Admin / SMTP service properties / General tab / Connection / Outgoing TCP port), and configure Exchange 5.5 server as smart host (Delivery tab / Advanced / Smart host). The smart host is the IP address (or 127.0.0.1, if Exchange 5.5 listens on localhost) of the computer. Add your domains as "remote domains" to the IIS SMTP with the same smart host settings. You can install ORF on this computer now.

    To avoid 8BITMIME conflicts between and IIS SMTP and Exchange 5.5, disable 8BITMIME advertising of the IIS SMTP Service. The process of disabling the 8BITMIME advertising is described in Microsoft Knowledge Base article Q262168 How to Disable 8BITMIME in Windows 2000 SMTP Service.
  • Can ORF work in an Exchange cluster?
    Yes, ORF can work in Exchange clusters, but as it is not cluster-aware, you have to install it to both cluster servers and synchronize the configuration manually. Alternatively, you can install ORF to a front-end server.
  • Does ORF support LDAP sources other than the Active Directory?
    There is no support for other LDAP sources currently. ORF is compatible with Microsoft's Active Directory only and also requires the AD schema extensions installed by Microsoft Exchange 2000.
  • Emails from my business partner are blocked. What should I do?
    Add your business partner's email address, domain or outbound email server IP address to the sender or the IP whitelist of ORF.

    We recommend using the sender whitelist which is easier to configure. If your business partner's email address looks like john@company.com, you can add john@company.com to the sender whitelist or whitelist the whole company domain using the mail mask *@company.com.
  • What header check depth I should configure?
    If you are not sure what you are doing, set the header check depth to 1. This is the recommended and default value for the header check depth. This value also could be right for your if you have a secondary MX (which is added to the Intermediate Host List).

    By setting the header check depth higher than 1, you can increase in the spam blocking effectiveness, but most likely the number of false positives will also increase.
  • How do I delete a Greylisting/Auto Sender Whitelist item?
    This depends on the ORF version and database type.

    In version 4.0 and later, you cannot edit the contents of Private Local Databases, so the only way to remove an item is to clear the entire database. You can freely edit External Databases using the SQL Server tools (e.g. SQL Server Enterprise Manager, Query Analyzer, etc.).

    In pre-4.0 versions, the Auto Sender Whitelist can be edited using the Auto Sender Whitelist Browser, but the Greylisting database cannot be edited.
  • How do I convert my Private Local Database to an External Database?
  • What do the {EMAILFILESPEC}, etc. format fields mean for External Agents?
    ORF provides the following format fields:
    • {EMAILFILESPEC}: The email file to be scanned with full path
    • {HELODOMAIN}: The HELO/EHLO argumentdomain received during the SMTP conversation
    • {SENDER}: SMTP envelope sender email address
    • {RECIPIENTS}: SMTP envelope recipient list (comma-separated)
    • {CLIENTIP}: The IP address where the SMTP connection came directly from
    • {SOURCEIP}: The IP address of the latest delivery hop before the email was accepted for delivery by any of the hosts on the ORF Intermediate Host List. In other words, the actual source IP for the email.

Regular Expressions

  • Where can I get more information about regular expressions?
    ORF uses PCRE engine (Perl-Compatible Regular Expressions), which implements (almost) the same syntax and semantics as Perl 5 (see http://www.pcre.org and http://www.pcre.org/pcre.txt [warning! large file] for documentation). Note that it is not the same engine used by Perl, Java or the .NET Framework.
  • How do I block attachments based on the file extension?
    From version 2.0, ORF supports using simple wildcarded masks for the attachment filtering (e.g. *.exe), but you may still find the regular expression support of the attachment filtering of ORF useful.

    Assuming that you want to block ZIP attachments, the regular expression you need is .*\.zip$. This expression means "zero or more arbitrary characters (.*) followed by a dot character (\.) and the "zip" sequence". The $ character anchors the expression, so no characters are accepted after the "p" character. If you do not add the $ anchor, my.current.zip.code.txt will also be blocked.

    Start the ORF Administration Tool, select Configuration / Filtering – On Arrival / Attachment filtering. Click New and set the Filter by attachment name checkbox. Select Regular expression (Perl-compatible) and enter .*\.zip$. Select what should ORF do with the attachment (Filter Properties tab), optionally assign a comment to the filter and click Ok.

    Using regular expression you can specify more than one extensions by a single expression. If you wish to block ZIP, EXE, COM and VBS attachments, enter an expression like .*\.(zip|exe|com|vbs)$. The pipe character (|) expresses logical "or" relation.
  • My regular expression does not seem to work... Any thoughts?
    There are same common mistakes of novice regular expression users, make sure you tested your filter correctly.

    The most common mistake is to forget "escaping" the special characters or anchoring the expression, Example: The novice user wants to filter attachments with ".exe" extension and he come up something like ".*.exe". This works nice in the test box, but will also catch "monthly executive summary.doc". Why? First, the dot character is a special character which means "any arbitrary character". Thus, when you write ".*", it translates to "zero or more arbitrary characters, followed by exactly one arbitrary character ("."), followed by the character sequence "exe"". The anchor is also missing, so any characters are allowed after the "exe" character sequence, including "cutive summary.doc". The proper regular expression is ".*\.exe$", with the "escaped" dot character and with a trailing anchor.

    Another typical problem is with the keyword filter expression concepts. You should know that the regular expression is evaluated on the entire content, not on every single word separately, so a regular expression filter like "cialis" may not do anything (except if you want filter emails beginning with this word). The common mistake is to use a filter like ".*cialis.*". For this first look, it appears to be correct, but there is a significant problem with it: the expression will catch any emails containing the word "specialist", because you did not tell the regular expression engine anything about the boundaries. So, just add \b to both sides of the expression (".*\bcialis\b.*") and only those emails will be caught be the filter expression which contain the word "cialis" and a word delimiter on both side of the word.
  • Who should I contact regarding a regular expression request?
    Please do not contact us regarding regular expressions you need, instead, post your request to the orf.ee.support newsgroup on our news server (news://news.vamsoft.com). This is a peer-to-peer support newsgroup (also supported by us), where you most likely get a fast reply from another ORF user.

Filtering

  • Why does ORF whitelist emails with blank sender addresses?
    It is an RFC standard requirement that every SMTP server must accept Delivery Status Notifications. These emails are sent with blank sender address. To keep your server compatible with the Internet standards, ORF whitelists (skips test for) the incoming Delivery Status Notifications (DSN's—a subtype of DSN's is the Non-Delivery Report, also called NDR).

    There may be certain situations when it is useful to disable this auto-whitelist feature. Start ORF Administration Tool, select Configuration | Global | Miscellaneous and set the Allow filtering Delivery Status Notifications checkbox. When this checkbox is set, ORF will treat emails with blank sender as regular emails. Note that this does not result in rejecting all DSN’s, only that these emails are tested and maybe blocked just as the other emails.
  • How did this email get thru? I added "..." to the keyword blacklist!
    First check your logs for the status of the given email, it may have been whitelisted. If it was not, check your filter expression: shall it really catch the email?

    There are a few other things to consider.

    When ORF filters HTML emails, the HTML contents are decoded to simple text. As HTML is a rich visualisation media, built by complex HTML elements, the decoding may produce some unexpected results on occasion. For example, spammers often use white text on white background to confuse the filters which treat the invisible text as actual content, though you do not see it in the mail client. You may filter for the expression "No prior prescription required", which has hidden text inside, so the decoded text may look like "NoFpriorQprescription33required". Spammers also use HTML tables, images instead of text and other techniques to bypass content filtering.

    Also, ORF does not filter embedded emails (such as emails attached to Delivery Status Notifications), so these will not trigger keyword filtering.
  • Why ORF does not block foo@bar when it is on the sender blacklist?
    First, please check the ORF logs regarding this given sender, it may have been whitelisted. It is also possible that you do not find the sender in the logs and you can match the email by the recipient and the arrival time only. Why? Because ORF identifies the sender and recipient as the SMTP envelope sender and recipient.

    Emails are similar to the real life postal mails. You put your letter into an envelope and write the sender and the recipient to the envelope. The post office delivers your mail to the recipient on the envelope, they do not open your envelope and check who is the sender and recipient on the letter paper. Emails also have envelope sender and recipient (they are called SMTP envelope sender and recipient) and letter sender and recipient (called MIME sender and recipient). Your email client, like Outlook displays the MIME sender and recipient only. Actually, the envelope sender and recipient is not stored in the email anywhere. *

    The SMTP envelope and MIME envelope information matches in most cases, but spammers often use different SMTP and MIME information to confuse the recipient. It is absolutely legal to use different SMTP and MIME address information. The Bcc: addressing, mailing lists, CRM software and other systems with automatic bounce-handling also often take advantage of this.

    * We offer a free script on our website that inserts the SMTP envelope information to the mail header, see the Scripts & Tools section of our website.
  • Why does ORF talk about recipients instead of emails (Before Arrival filtering point)?
    See "Why "Reject recipient" event is logged when it was a sender rejection?"
  • Why "Reject recipient" event is logged when it was a sender rejection?
    This is specific to the Before Arrival filtering point. ORF builds into the SMTP connections (the transfer protocol of emails) and monitors specific protocol events. The Before Arrival filtering is performed when the sender server tries to specify the recipient(s). On this event, ORF performs the tests assigned to the Before Arrival filtering point and if the incoming email fails on the tests (e.g. the sender email address, the connection IP address or the recipient is blacklisted), it rejects the email recipient. So it is not actually the email rejected, it is the recipient. The On Arrival filtering point actually deals with the email, so it uses the "email" terminology.

    An email may have multiple recipients, so the rejection of a single recipient may not result in rejecting the entire email.

Troubleshooting

  • Before Arrival filtering does not seem to work, any ideas?
    There are some scenarios when the Before Arrival filtering cannot be used effectively, typical examples are:
    • incoming emails are filtered by an anti-virus/mail filtering proxy running in front of ORF
    • incoming emails are forwarded by a front-end server
    • incoming emails are received using a POP3 forwarder
    • incoming emails arrive via a secondary MX
    These scenarios can be recognized easily, check the ORF logs and if you find that all incoming emails are from the same IP address at the Before Arrival filtering point, most likely you experience the problem above.

    Before email arrival, the email delivery path is not known, so ORF identifies the sender as the incoming connection remote peer. In the scenarios above, these peers are not the actual sender servers, but the forwarders (proxy, front-end, etc.) so IP-based tests (including DNSBL tests) does not work, the emails may be whitelisted (due to the source intranet address).

    In this case, assign all tests to the On Arrival filtering point (ORF Administration Tool, Configuration | Tests | Tests).
  • My logs are full with "Could not create statistics for the client [ex]. EOleSysError/Member not found" errors. What should I do?
  • Why does not my statistics displayed?
    Most likely it is a problem with the outdated Microsoft XML component (MSXML) on your system. Please install Microsoft Internet Explorer 6 or newer. Alternatively you can install the MSXML update separately. It can be downloaded from Microsoft's web site. The minimal required version is MSXML 3 SP2 (get it here).

    You may also want to check whether you have cumulative statistics enabled (ORF Administration Tool | Global | Statistics).
  • All inbound emails are blocked by the RDNS test, what should I do?
    This is most likely an issue with the DNS servers specified for ORF. They must be able to resolve external domains recursively (i.e. to return the requested DNS record in a single step instead of redirecting the DNS client to the root DNS servers). Please make sure that all DNS servers configured for ORF satisfy these requirements. To test your DNS server's status, start the ORF Administration Tool, open the Configuration / Global / DNS and Lookups page and click button Test DNS.

    The issue is typically caused by the ISP DNS servers, so we recommend using local DNS servers. You should consider that ISP DNS servers are out of your control and their configuration may change without prior notice.
  • Why is my ORF SMTP Module "inactive"?
    This status does not indicate a problem, it only reports that the SMTP Module has not been loaded by the IIS Administration Service yet. The SMTP Module is loaded first time when an email arrives to the IIS SMTP virtual server you bound the SMTP ORF Module to.

    If there are emails flowing thru the given SMTP virtual server, but the status is still "inactive", open the command prompt, enter to the ORF directory (\Program Files\ORF Enterprise Edition by default) to fix the SMTP Module registration.
    For version 4.0 and later, run "orfsmtpinst -install". For a pre-4.0 version, run "regsvr32 orfesmtp.dll"
  • I get error "..." when I try to get ORF’s AD integration work. How can I fix this?
    If the error message is "A referral was returned from the server", make sure that you have a valid LDAP path configured for ORF. Note that LDAP, GC, DC, ORG, etc. has to be written uppercase and no spaces are allowed between the commas.

    "The authentication mechanism is unknown": make sure that you have proper authentication information defined, both the user name and password is correct. Note that your server may require the user name in format DOMAIN\username or username@DOMAIN

    "Could not bind to path "..."": Check the LDAP path. Note that LDAP, GC, DC, ORG, etc. has to be written uppercase and no spaces are allowed between the commas.

    If the above does not help, try the synchronization with and without authentication (also with authentication with blank user information). ORF AD synchronization queries AD-specific properties, so it also requires the AD schema extension by Microsoft Exchange 2000/2003. Synchronization with a regular Active Directory without these schema extensions is not supported.
  • My logs are full of "General socket error 0" messages. What should I do?
    This issue is caused by a bug in the Microsoft DNS Server.
    You can find more information about the problem in this article. If you experience this issue, please read Microsoft Knowledge Base Article 946565 regarding the fix.
  • When ORF tags the subject, the email body turns into garbled text. How can I fix this?
    When ORF tags the email subject, the encoding of the subject is changed to UTF-8, regardless the original subject encoding. ORF does this because the language of the subject tag and the subject is not guaranteed to be the same (Cyrillic subject tag and Hebrew subject), thus the new subject must be encoded with an encoding that supports mixing various languages and writing systems, like the UTF-8 encoding.

    This change made by ORF is correct by the email standards, but Microsoft Exchange Server 2003 has a bug that causes these emails to be displayed garbled in Microsoft Outlook when the message body contains non-English characters.

    Microsoft provides a patch and detailed information about this bug in Microsoft Knowledge Base Article 900087 "The body of an e-mail message is garbled when the header field and body field are set to different character sets in Exchange Server 2003". If this patch does not solve the problem, try Microsoft Knowledge Base Article 916299 "The body of an e-mail message is garbled when the message is viewed in Outlook in an Exchange Server 2003 organization".
  • All emails are whitelisted and appear to be coming from our ISA server, why is that?
    In case your ISA is configured to forward requests to Exchange with the option Requests appear to come from the ISA Server Computer (SMTP Rules), ISA will delete the Received: header lines from the email, removing the email delivery path history. This causes ORF to think the email came directly from the ISA server (see Header Analysis in the ORF Help).

    Change this ISA setting to "Requests appear to come from original clients" in order to preserve the original headers.

Licensing